AWS mysql 5.7 -> 8.0 업그레이드

발단

회사에서 업무 수행 중 m5.large type의 RDS에서 대용량 데이터 조회 수행 후 cpu 점유율을 살펴보니 50% 넘지 못했음. 

cpu 1개만 사용하고 있다 판단하고 병렬 쿼리에 대해 찾아보았으나 5.7 버전에서는 사용할 수 없었음. 

그 외에도 8.0에서의 장점이 있는 듯 하여 업그레이드 하기로 판단.

 

과정 

별 다른 고민 없이 백업 인스턴스를 만들고 AWS 콘솔에서 5.7 -> 8.0으로 업그레이드 시도.

에러 로그를 살펴보니 트리거 관련해서 에러가 지속적으로 나고 있었다.

그제서야 사전 준비가 필요하다는 것을 깨닫고 여러 방면으로 검색

사전 준비

docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.html#USER_UpgradeDBInstance.MySQL.57to80Prechecks

MySQL DB 엔진 업그레이드 - Amazon Relational Database Service

또한 mysql document에 친절하게 사전에 점검해야 할 사항에 대해 정리되어있다

dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html

MySQL :: MySQL 8.0 Reference Manual :: 2.11.5 Preparing Your Installation for Upgrade

mysqlcheck를 수행해본 결과 Trigger에 특정 속성이 없다는 warning이 있다. 자동으로 업그레이드가 되려면 Trigger에 모든 속성이 채워져 있어야 하는데 우리 쪽 트리거는 CREATED라는 속성이 없어서 나는 에러였다. 하단 부는 예시이다.

database.table

Warning  : Trigger database.table.trigger_name does not have CREATED attribute.

 

트리거를 개발했던 개발자는 이미 퇴사한지 오래. 어떤 이유에서 트리거를 사용했는지 듣지 못했다

사이드 이펙트의 우려가 있어 트리거는 복원하고 업데이트 후에 다시 넣어주는 방식으로 결정.

 

트리거만 백업하는 쿼리는 검색해보면 많이 나온다.

mysqldump --routines --no-create-info --no-data --no-create-db --skip-opt [database] > [file_name].sql

 

다만 mysql-cli 버전이 높으면 unknown table 'COLUMN_STATISTICT' in information_schema (1109) 를 내뱉는다. 

기본적으로 해당 컬럼을 사용하는 모양이다.

해당 에러를 해결하기 위해 --column-statistics=0 옵션을 추가한다.

트리거 백업 및 8.0 업그레이드 

트리거 백업을 완료 했고 문제 되는 트리거들을 지우려 했으나 1227 에러를 내뱉으며 삭제가 되지 않는다.

aws.amazon.com/ko/premiumsupport/knowledge-center/rds-mysql-functions/

Amazon RDS MySQL 함수, 절차 및 트리거 활성화

찾아보니 AWS에서 가이드를 내주고 있다. 파라미터 그룹에서 log_bin_trust_function_creators 를 찾아서 1로 바꿔주었다.

만약 공통된 파라미터 그룹을 사용하고 있는 상황에서 파라미터를 수정해도 괜찮냐는 걱정이 생길텐데 파라미터 적용을 위해선 인스턴스 재시작이 필요하다. 현재 운영중인 인스턴스를 재시작 하지 않으면 반영이 되지 않으므로 상관없다. 

 

mysql workbench에서 트리거들을 전부 지워준 뒤 AWS 에서 8.0으로 업그레이드 해주었다. 

약 20~30분 내외로 업그레이드가 완료 되었던 것 같다.

 

트리거 롤백

8.0 업그레이드 완료 후 트리거 롤백을 하려하니 에러가 발생한다. 

백업해두었던 sql 파일을 workbench에서 열어서 한줄한줄 실행해가며 에러가 나는 부분을 주석처리

대부분 환경변수 설정에서 에러가 났다. 

 

테스트 

아직 개발계에만 적용되어 실제 부하 상황에서 cpu 문제가 해결되었는지는 테스트 해보지 못했다. 다만 내부적으로 RANK 라는 이름의 컬럼을 사용하고 있었는데 8.0 부터는 RANK가 예약어로 설정되는 바람에 SQL 에서 RANK 컬럼을 전부 쿼터로 묶어주었다. 

또한 병렬 쿼리 관련 디비 파라미터가 새로 생긴 것을 확인할 수 있었다. 

운영계 db를 version up 해본 뒤 다시 테스트 해볼 예정이다.