RDS MySQL, Aurora MySQL Cluster 의 버전 업그레이드 시 확인 해야할 사항

해당 페이지에서는 RDS MySQL, Aurora MySQL Cluster 의 버전 업그레이드 시 확인 해야 할 사항들에 대해서 다룬다.

 

이 페이지는 아래의 AWS 공식 Blog 와 연관되어 있다.

 

[1] https://aws.amazon.com/ko/blogs/tech/database-amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-1/

 

[2] https://aws.amazon.com/ko/blogs/tech/database-amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-2/

 

 

RDS, Aurora Cluster 버전 업그레이드 개요

 

RDS, Aurora Cluster 를 사용하는 개발자, 운영자들은 사용시에는 항시 버전 업그레이드를 고려해야한다. 이는 AWS 측에서는 RDS, Aurora Cluster 에 대한 모든 버전을 영구적으로 지원 해 주지 않는다. 즉, 주기적으로 구버전 및 AWS 환경에서 운영이 어렵다고 판단되는 버전들은 EOL 로 지원 종료를 결정하게 되고, 이 때는 사용자들에게 PHD 등으로 버전지원 종료에 따른 업그레이드 권장을 안내하게 된다.

 

이 때, 버전 업그레이드는 minor 버전, major 버전 업그레이드로 업그레이드 종류가 나뉘는데 일반적으로 상당한 시간이 소요되는 작업은 major 버전 업그레이드다. 이 때, 업그레이드에 대한 차질이 있어서 업그레이드 일정에 문제가 있을 수 있다면 Extended Support 를 사용 해 볼 것을 권장한다.

 

 

MySQL 업그레이드시 확인 해야 할 사항들

 

특히 MySQL 은 5.7 에서 8.0 으로 버전이 전환되면서 상당히 많은 내용들이 바뀌었고, 이에 따라 업그레이드를 수행 시 확인이 필요한 사항들이 생겼고 업그레이드 도중 실패시에 조치해야 할 실패원인도 상당 수 있다.

 

최근에 AWS 측에서는 [1], [2] 와 같이 업그레이드를 할 시, MySQL engine instance 들을 업그레이드 시 확인을 해야 할 사항들을 공유 했다. 이 페이지에서는 Blog 에 기재 된 항목들에 대해서 부연 설명을 하는 것으로 확인 필요 사항들을 정리한다. (자세한 내용은 [1], [2] 를 통해 확인하면 좋다.) 또한 [1], [2] 는 Aurora MySQL 을 중심으로 다루지만 대다수의 내용은 RDS 에서도 적용 되기에 두 서비스를 같이 일괄로 묶어서 설명한다.

 

 

- 업그레이드 사전 확인

 

AWS 에서는 RDS, Aurora Cluster 업그레이드 수행 시 조치가 필요한 사항들이 확인되면  upgrade-prechecks.log 를 만들면서 어떤 부분이 조치가 필요한지를 보여준다. 사용자들은 테스트 환경에서 먼저 업그레이드를 테스트 하기에 이 때 테스트를 하면서 이를 같이 확인해서 실제 운영환경에서도 이를 조치하여 원활한 업그레이드를 수행 할 수 있다.

또한, 업그레이드가 이로 인해 실패 시에는 자동으로 rollback 이 되니 다시 조치 후 시도하면 된다. (단, 현재 업그레이드 지원 기능인 blue/green deployment 를 사용시에는 이전 instance 환경으로 application 환경을 rollback 시켜주지 않으니 주의하자.)

 

 

- 클러스터의 사용자 스키마에 일관되지 않은 데이터 딕셔너리 또는 중간 테이블이 있습니다.

- 클러스터에 분리된 FULLTEXT 인덱스가 포함된 테이블이 있습니다.

 

둘 다 DB 내 metadata 와 실제 DB 환경의 오브젝트 정보가 일치하지 않아서 발생하는 이슈다. Blog 에서는 PiTR 과 optimize 를 이용할 것을 안내 하지만 운영환경에서 PiTR 를 시도 하는 것은 어려운 작업이 될 수 있다.

그렇기에 이 사항은 가능하면 AWS Support 를 통해 긴밀하게 지원을 받는 것이 좋다.

 

유감스럽게도  AWS Support 를 받지 못하는 무료 또는 developer 로 AWS Plan 을 사용해서 운영 서비스를 구성 했다면 PiTR 또는 사용자들이 고안한 자체적인 우회방안을 수행해야 한다.

 

 

- 클러스터에 예약된 키워드가 있는 개체가 있습니다.

 

Blog 에서도 안내가 되었지만, MySQL 8.0 에서는 MySQL 5.7 에 예약어가 (reserved keywords) 추가로 도입되었다.

주로 예약어는 프로시저, 함수, 이벤트 및 트리거를 생성시에 자주 사용되는데 이 때, 업그레이드를 시도 시에는 RDS, Aurora Cluster 에서는 이에 대한 예약어 차이를 그대로 받지 않고 사용자측에서 조치를 하도록 안내를 하면서 업그레이드를 취소한다. 그렇기에 사용자가 업그레이드를 수행하려면 이에 대한 예약어 비교 및 조치를 취해야 한다.

 

 

- 클러스터에 열 정의에 잘못된 문자가 포함된 테이블이 있습니다.

 

업그레이드를 수행 시, engine 에서 테이블 내 comment 를 인식하지 못할 경우다.

이는 단순하게 comment 를 변경하면 된다.

 

 

- 클러스터에 준비된(prepared) 상태의 XA 트랜잭션이 있습니다.

- 클러스터에 undo 레코드 수가 많습니다.

- 클러스터에 진행 중인 대규모 쓰기 트랜잭션이 있습니다(많은 행에 대해 커밋되지 않은 변경 사항).

- 클러스터에 장기 실행 또는 커밋되지 않은 유휴 트랜잭션이 있습니다.

 

공통적으로 현재 업그레이드 대상 instnace 에 활발하게 작동되는 트랜잭션, 쿼리들이 있다는 점이 있다.

테스트 환경에서는 발견이 되지 않다가 운영환경에서 업그레이드를 수행 시, 해당 사항들이 발생 할 수 있다.

그래서 운영 instance 업그레이드는 문제가 생길 시, 조치를 취할 준비를 하고 수행을 할 수 있지만, 개인적으로는 아에 트랜잭션이 발생할 가능성이 낮은 야간 또는 새벽시간대에 사용중인 운영 instance 들을 업그레이드 할 것을 권장한다.

 

 

- 클러스터에 상당한 수의 테이블이 있습니다.

 

이 사항은 주로 업그레이드 실패가 아닌 업그레이드 소요 시간을 크게 증가 시키게 하는 사항이다.

이는 MySQL 이 major 버전 업그레이드를 수행 시, 각 테이블의 구성 정보를 보관하는 파일들에 대해서 scan 및 신규 버전에 맞게 자체 가공과정을 거치기 때문이다.