Last Updated on 1월 5, 2025 by Jade(정현호)
안녕하세요
이번 포스팅에서는 AWS의 Aurora MySQL 의 업그레이드 관련해서 전반적으로 내용을 확인해보려고 합니다.
해당 포스팅은 Aurora 2.0 버전에서 3.0 버전으로의 업그레이드 내용을 다루고 있습니다.
Contents
Upgrade 방법론
AWS Aurora MySQL 을 업그레이드하는 방법론은 크게 2가지로 나눌 수 있습니다.
- In-Place
- Out-of-Place
In-Place
In-Place Upgrade 란 사용 중인 소프트웨어의 경로 위치나 서버의 변동 없이 그 자체로 업그레이드를 하는 것을 뜻합니다.
DBMS는 소프트웨어 영역(엔진 파일) 과 데이터가 저장된 데이터 파일 영역으로 구분할 수 있으며, 설치형(온프레미스) 환경에서는 소프트웨어 영역(엔진 파일)에 대해서 디렉토리 위치 변경 없이 동일한 위치에서 소프트웨어 파일을 상위 버전으로 교체하는 형태의 업그레이드 방식을 의미합니다.
어느 DB 나 동일하게 변경된 소프트웨어(바이너리, 엔진 파일) 를 통해서 DB 를 시작하고 나서는 각각의 DBMS 마다 업그레이드 절차를 따라서 데이터 파일내 딕셔너리와 메타데이터 등에 대한 업그레이드(갱신)을 수행하게 됩니다.
AWS Aurora MySQL 에서의 In-Place Upgrade 는 이와 유사하게 해당 인스턴스를 바로 업그레이드를 하는 것을 의미합니다.
이 부분을 별도로 설명하는 이유로는 Aurora MySQL 2.0 버전에서 3.0 버전으로 업그레이드가 얼마전까지(포스팅 작성 시점 기준으로) Out-Of-Place 만 지원이 되었고, In-Place Upgrade 지원에 대해서는 2022년 9월 26일에 발표되었기 때문입니다.
참고로 AWS Aurora MySQL 3.0 릴리즈에 대한 발표는 2021년 11월 18일에 되었습니다.
Aurora 3.0 지원 발표가 2021년 11월 18일이고, In-Place Upgrade 지원이 2022년 9월 26일날 발표하였기 때문에 출시되고 10개월가량 정도의 짧지 않은 시간이 지나서야 In-Place Upgrade 방식이 지원되기 시작한 것입니다.
그래서 출시 직후 부터 해서 약 10개월 동안의 업그레이드는 Out-Of-Place Upgrade 방식만 가능 하였기 때문에 이 시기에 업그레이드 한 분들은 Out-Of-Place Upgrade 방식으로 진행하였다고 보시면 됩니다.
( 그중에 저도 그렇게 업그레이드를 했습니다...)
다시 정리하면, AWS Aurora MySQL 과 같은 완전 관리형 DB에서의 In-Place Upgrade 는 새로운 인스턴스를 생성하지 않고 사용하는 인스턴스에서의 업그레이드를 의미합니다.
이러한 In-Place Upgrade 의 장점은 아래와 같습니다.
- 별도의 인스턴스를 생성하지 않아도 됨
- Aurora MySQL 에서 binlog 활성화하지 않아도 됨
- Cluster 식별자, Cluster Endpoint, Instance Endpoint 정보가 변경되지 않음
그렇다면 다음으로 In-Place Upgrade 를 하게 되면 고려해야 할 부분이 어떤 것이 있을까요?
- Aurora 의 경우 Upgrade 하는 동안 Rolling Upgrade 가 불가하여 전면적 사용이 불가함
- Upgrade 에 의한 사용 불가시간(Downtime)이 Out-Of-Place 에 비해서 상대적으로 많이 소요됨
- 여러 이유로 원복(Rollback) 을 해야 할 경우에 Out-Of-Place 에 비해 원복 시간이 길어지며 원복 완료 시간까지 역시 서비스 불가 시간이 되게 됨, 또한 선택하는 원복 방법에 따라 Out-Of-Place 에 비해 절차나 방법이 복잡해질 수 있음
정리하면 완전 관리형 서비스 DB인 Aurora MySQL 에서는 별도의 인스턴스를 생성하지 않고 사용하는 인스턴스에서 업그레이드를 바로 진행하는 것을 In-Place Upgrade 라고 합니다.
Out-Of-Place
Out-Of-Place Upgrade 방식의 경우 다른 경로나 AWS Aurora 와 같은 완전 관리 서비스형 DB의 경우 다른 인스턴스를 생성하여 업그레이드를 하는 방법론이라고 할 수 있습니다.
온프레미스 환경의 설치형 MySQL 이나 다른 DBMS 를 사용하는 환경에서 소프트웨어 파일(엔진 파일)의 경로에 버전(마이너 버전을 포함할 수도 있음) 정보를 포함하여 사용하는 경우가 많이 있습니다.
예시) /usr/local/mysql/5.7.25 /oracle/product/11g/db /oracle/product/11202/db
이와 같이 경로 상에서 버전 정보를 포함하여 사용할 경우에 많이 사용하기도 하며, Oracle DB의 경우 11g 버전 부터는 Out-Of-Place Upgrade 를 권유하고 있는 편입니다.
그래서 위와 같은 온프레미스 환경의 MySQL 의 경우에는 데이터파일의 딕셔너리를 업그레이드 하기전에 사용중인 서버에서 새로운 버전의 MySQL 소프트웨어(엔진 파일) 를 새로운 경로에 설치를 하게 됩니다.
# 현재 사용중인 경로 /usr/local/mysql/5.7.25 # 신규 버전의 새로운 경로 /usr/local/mysql/8.0.25
위와 같이 현재 사용중인 서버에서 기존의 MySQL 과는 다른 경로에 엔진 파일을 설치를 완료하고, 새로운 버전에 맞는 my.cnf 파일을 다른 이름 또는 다른 경로에 준비를 하는 등의 프로세스를 진행하게 됩니다.
AWS Aurora MySQL 에서의 Out-Of-Place Upgrade 는 현재 사용하는 클러스터/인스턴스가 아닌 다른 클러스터/인스턴스를 생성하여 업그레이드 후 전환하는 방식을 의미합니다.
업데이트) Amazon Aurora 및 RDS의 완전관리형 블루/그린 배포 기능 출시 되었습니다.(2022/11/30)
Green 인스턴스 생성을 할 수 있으며, 전환(Switch over) 수행을 하게 되면 Green 인스터스의 주소가 기존에 사용한 Blue 인스턴스 주소로 변경되는 기능입니다. 자세한 사항은 아래 링크를 참조하세요
업그레이드하는 과정 전반적으로 blue-green 과 같은 CI/CD 프로세스를 사용하게 됩니다.
[version-upgrades-aurora-mysql-minimum-downtime]
아키텍처에는 아래 단계로 진행됩니다.
- 이전 Aurora 메이저 버전(블루 환경)에서 빠른 데이터베이스 복제 를 수행하고 이전 Aurora 메이저 버전(그린 환경)으로 생성합니다.
- 그린 환경에서 클러스터를 수정하여 메이저 버전 인플레이스 업그레이드를 수행합니다.
- 아키텍처에 표시된 대로 Aurora 클러스터 간에 수동 MySQL 바이너리 로그 복제 를 설정하여 블루 환경에서 그린 환경으로 데이터 변경 사항을 복제합니다.
- 그린 환경이 전환 준비가 되었다면 계획된 다운타임 기간 동안 애플리케이션 블루 환경을 중지하고 그린 환경을 새로운 블루 환경으로 사용하기 시작합니다.
Out-Of-Place Upgrade 는 보통의 경우 위와 같은 프로세스로 진행되며, AWS Aurora MySQL 의 경우 위와 같은 프로세스로 진행하면 되며, 업그레이드하는 과정에서 위에서 설명한 내용처럼 In-Place Upgrade 를 초기에는 지원하지 않아서 Snapshot 또는 백업을 통해서 그린 환경 클러스터를 구성할 때부터 같은 버전이 아닌, New Version 인 Aurora 3.0 버전으로 생성해야 했습니다.
얼마전부터 In-Place Upgrade 지원하기 때문에 아래와 같이 2가지 방법으로 진행할 수 있습니다.
- 위와 같은 프로세스와 같이 복제한 새로운 그린 환경 클러스터를 구성후에 업그레이드
- Snapshot 또는 백업을 통해 그린 환경 클러스터 구성시부터 AWS Aurora 3.0 버전으로 생성
이러한 Out-Of-Place Upgrade 를 하게 되면 장점은 아래와 같습니다.
- In-Place Upgrade 에 비해 상대적으로 새로운 버전으로 전환이 빠르며, 전체적인 업그레이드에 필요한 작업 소요 시간이 짧습니다. 이 부분은 서비스면 또는 애플리케이션에서의 다운타임이 In-Place 에 비해서 짧을 수 있다는 것도 포함입니다.
- 업그레이드 작업 중에 원복(Rollback)을 빠르고 쉽게 할 수 있습니다.
- 업그레이드 과정에서의 문제가 발생시 현재 버전(사용중인) RDS 로 애플리케이션이 다시 접속하는 형태로 쉽게 원복이 가능 합니다.
- 사전에 여러 테스트 등을 해볼 수 있습니다.
- 계속된 데이터가 복제 동기화가 되고 있는 상태이기 때문에 읽기 성 업무에 대해서는 애플리케이션 테스트를 쉽게 할 수 있으며, 테스트 방법에 따라서 데이터 입력 및 변경 등의 테스트를 수행해볼 수도 있습니다.
그렇다면 다음으로 Out-Of-Place Upgrade 를 하게 되면 고려해야 할 부분이 어떤 것이 있을까요?
- 복제 방식으로 되기 때문에 선행적으로 binlog 활성화가 필요 합니다.
- binlog 를 활성화하게 되면 비활성화 인 기본값에 비해서 상대적으로 CPU 자원 소모가 발생되게 됩니다.
- 새로운 인스턴스로 이전(Migration) 이기 때문에 Cluster 및 DB Endpoint 정보가 변경되게 됩니다.
- 사용 환경에 따라서 애플리케이션 Source 에서 접속 정보 변경을 해야 합니다.
- 그에 따라서 접속 주소를 변경을 해야하는 대상 애플리케이션이나 소스의 범위와 종류 확인해야 합니다.
- 이 과정에서 오래된 레거시 소스와 잘 사용되지 않는 소스의 파악이 현실적으로 어려움이 될 수 있습니다.
- 업그레이드가 진행되는 과정에서는 RDS 비용이 추가로 소요됩니다.
- 업그레이드 일정 및 전환 일정에 따라서 일정이 길어지는 만큼 RDS 비용은 더 늘어날 수 있습니다.
- AWS Aurora 의 스토리지 방식의 복제가 아닌 별도로 복제를 구성하는 것임으로 업그레이드 완료(전환, Migration) 전까지 복제에 대한 모니터링이 필요합니다.
- 전환 하기전에 데이터 및 DDL 및 유저에 대한 정보가 계속적으로 복제 동기화가 되고 있고, 복제가 중단이 되는 경우는 여러가지 임으로 별도의 스크립트를 통해서 모니터링하거나 Recent events 를 통해서 복제 상태를 주기적으로 확인해야 합니다.
- 복제 중단에 대해서 사전에 모니터링 되지 않아 장시간 복제가 중단되었을 경우 새로운 버전의 클러스터로 Migration 시 아직 반영되지 못한 데이터 복제에 대해서 완료될 때까지 만큼의 추가적으로 작업 소요 시간이 늘어나게 됩니다.
- 복제 중단이 장시간 되어서 binlog 보관주기 이상으로 되었을 경우, 복제 정상화하여 복제를 적용하던 중에 binlog 찾을 수 없어서 복제가 다시 중단된다면, snapshot 을 통해서 복제를 다시 구성해야 합니다.
- 그러므로 업그레이드 진행시에는 Source Aurora 의 binlog 보관주기를 가급적 길게 설정하는 것이 여러모로 안전하다고 할 수 있습니다.
이와 같이 Out-Of-Place Upgrade 는 애플리케이션의 세션(커넥션)의 전환 방식의 구현에 따라서 수초~1분내로도 새로운 버전으로 변경이 가능하며, 원복이 쉽다는 장점이 있으며, 반대로 복제 방식을 사용하여 전환하는 방법론 이기 때문에 그에 따른 고려 사항도 필요하게 됩니다.
Pre-check
업그레이드를 하기 위해서는 위에서 설명한 방법론적인 부분도 선택과 고려를 해야 하지만 또 다른 한편으로 설치형 MySQL 과 AWS Aurora MySQL 공통적으로 업그레이드시에 체크해야 할 사항이 있을 수 있습니다.
그래서 업그레이드시에 여러가지 다각도로 사전에 체크 및 미리 준비를 해야 할 필요성이 있습니다.
업그레이드를 하기전에 확인하고 준비를 할 부분에 대해서 일부 확인해보도록 하겠습니다.
(여기에서 언급된 부분은 여러 종류 중에서 일부이며, 추가적으로 체크하고 검토해야 할 부분은 많이 있습니다.)
[참고] 온프레미스 설치형 MySQL 8.0 버전 업그레이드 관련된 내용은 다음 포스팅을 참고하시면 됩니다.
파라미터
파라미터의 경우 온프레미스의 설치형 MySQL 의 경우 업그레이드 하기전에 필수로 체크를 해야 하는 부분입니다. 새로운 버전으로 업그레이드하기 위해서 지금 사용중인 파라미터 중에서 이름이 변경된 파라미터, 사라진(obsolete) 파라미터를 파악해야 하며, 이전과 파라미터의 기능이 달라진 부분도 체크해야 할 부분입니다.
그래서 새로운 버전으로 MySQL을 구동하게 되었을 때 파라미터에서 문제가 발생되면 데이터베이스가 시작이 되지 않을 수도 있습니다.
사전에 체크해봐야 하는 파라미터로는 대표적으로 아래와 같은 파라미터가 있습니다.
- show_compatibility_56
- innodb_undo_tablespaces
- expire_logs_days
- lower_case_table_names
- query_cache_size, query_cache_type 또는 query_cache 관련 파라미터
(* 일부만 나열되어있으므로 그외 체크 해야할 파라미터는 다수가 존재함)
설치형 MySQL 에서는 새로운 버전용 my.cnf 를 준비하는 과정에서 제거 및 변경해야 할 파라미터를 직접 수정 해야함으로 버전 차이간 파라미터를 확인해야 합니다.
특히 lower_case_table_names 파라미터 정책은 MySQL 8.0 버전부터는 인스턴스 생성 이후 변경이 안되기 때문에 8.0 버전으로 업그레이드 하기전에 정책을 명확히 정해야 합니다. 이 부분은 AWS RDS for MySQL 8.0 과 AWS Aurora MySQL 3.0 버전도 동일한 내용입니다.
그 외 버전 별로 없어진 파라미터에 대한 정보는 아래 문서를 참조해서 체크를 해봐야 합니다.
이런 부분에서는 AWS RDS 가 실수나 잘못될 수 있는 상황에 대해서 대처가 가능한 부분이 있습니다. AWS RDS 에서는 버전 별로 사용 가능 또는 불가능 파라미터가 템플릿으로 고정되어 있기 때문에 해당 버전에서 사용 불가한 파라미터는 목록에 애초에 없기 때문입니다.
또는 AWS RDS의 운영이나 기동 시 문제가 될 수 있는 파라미터는 변경이 불가한 타입으로 설정되어서 사용자가 변경할 수 없도록 하는 보호 장치도 마련되어 있습니다.
RDS 의 업그레이드 과정에서 사전에 파라미터 그룹을 버전에 맞게 생성 및 변경을 해야 하며, 해당 파라미터 그룹에서는 해당 버전에서만 사용 가능한 파라미터 목록이 나열되어 있으므로 제거해야 할 파라미터에 대한 부분은 이미 조치가 되어 있다고 생각 할 수 있습니다.
다만 위에서 언급한 내용처럼 lower_case_table_names 파라미터 경우 설치형 MySQL과 AWS RDS가 동일하게 동작하기 때문에 해당 파라미터의 정책은 사전에 정의 및 결정이 되어야 합니다.
[업데이트] 최근 개선되어 Aurora MySQL 3 버전에서도 innodb_flush_log_at_trx_commit 파라미터 변경이 가능 해졌습니다.
innodb_flush_log_at_trx_commit 파라미터 차이점은 AWS Aurora 에만 해당하는 사항으로 Aurora 2.0(compatible 5.7) 에서는 변경 가능한 파라미터였으나 Aurora 3.0(compatible 8.0) 에서는 수정이 불가한 파라미터로 변경되었습니다.
[Aurora 2.0 클러스터 파라미터 그룹 내역]
[Aurora 3.0 클러스터 파라미터 그룹 내역]
위의 이미지와 같이 Aurora 3.0 에서는 innodb_flush_log_at_trx_commit 파라미터에 대해서 Modifiable 값이 false 인 것을 확인할 수 있습니다.그래서 Aurora MySQL 2 버전에서 innodb_flush_log_at_trx_commit 파라미터에 대해서 다른 값으로 사용하였던 시스템의 경우 기본값 사용에 대한 부분이 사전에 논의나 고민을 해봐야 할 부분입니다. (기본값 1)
-> 내용 업데이트: Auora MySQL 2 버전에서 innodb_flush_log_at_trx_commit 파라미터 값을 기본값 1이 아닌 다른 값으로 사용하고 있는 환경에서도 Aurora MySQL 3 버전으로 업그레이드시 동일하게 innodb_flush_log_at_trx_commit 파라미터를 변경할 수 있게 되었습니다.
Aurora MySQL 3 버전에서 innodb_flush_log_at_trx_commit 파라미터 변경 관련 자세한 내용은 아래 포스팅을 참조하시면 됩니다.
SQL_MODE
버전이 변경되면서 바뀌는 부분 중에는 SQL_MODE 가 있습니다.
MySQL5.7.5 버전 부터 추가된 NO_AUTO_CREATE_USER 이 8.0 에서는 기본적으로 활성화되면서 목록에서 제거되었습니다. 그래서 설치형 MySQL 에서는 8.0 업그레이드시 NO_AUTO_CREATE_USER 이 지정되어 있다면 제거하시면 됩니다.
NO_AUTO_CREATE_USER 과 관련되어 프로시저나 트리거에 sql_mode "NO_AUTO_CREATE_USER" 선언되어 있다면 Upgrade Precheck 단계에서 warning 이 발생될 수 있습니다. Precheck 과정에서 검출된다면 해당 내용 제거하여 다시 재생성 하시면 됩니다.
그 외 사용되는 SQL 과 테이블에 입력된 데이터에 따라서 기존에 별도의 값으로 설정하여 SQL_MODE 를 사용하였다면 변경 없이 그대로 사용하시는 것이 SQL 에러 발생 소지를 줄일 수 있는 방법입니다. SQL_MODE에 따른 Side effect 확인이 어렵다면 기존의 값을 그대로 사용하시는 편이 좋습니다.
AWS Aurora 에서는 새로운 버전 파라미터를 생성하면 SQL_MODE의 경우 아무런 값도 지정되어 있지 않습니다.
기존에 사용하였던 파라미터 값이 있다면 해당 값을 따라 적용하시면 됩니다.
Character Set, Collation
MySQL 5.7에서도 utf8mb4 를 사용할 수 있었으며 8.0 버전 부터는 기본 Character Set 으로 됨에 따라서, 업그레이드 따른 Character Set 을 고민해야 하며, 정해진 Character Set 다음에는 사용할 Collation 을 선택해야 합니다.
물론 기존에 사용한 Character Set 과 Collation 이 큰 단점이나 사용상 불편이 없다면 그대로 사용하시면 됩니다.
서버 엔진의 Character Set 과 Collation 이 변경(정해졌다면) 되었다면, 테이블과 컬럼에 지정된 Character Set 과 Collation 의 변경을 할지 한다면 언제 시점에 작업할 지 등을 고민해야 합니다.
예약어(Reserved Words)
MySQL 버전에 업그레이드됨에 따라서 예약어는 추가되거나 변경되게 됩니다. 그래서 버전에 맞는 예약어 정보를 확인해서, 예약어로 생성된 테이블이나 컬럼이 있는지 사전에 체크해볼 필요성이 있습니다.
예약어(Reserved Words) 에 대한 정보는 아래 도큐먼트에서 확인하시면 됩니다.
TLS 버전
MySQL 8.0.28 버전부터 TLSv1.0, TLSv1.1 이 Removed 되었으며, MySQL 8.0.28과 호환되는 Amazon Aurora MySQL 3.04 버전도 출시되었습니다.
그에 따라 SSL/TLS로 접속을 사용하는 환경에서는 개발언어 및 접속 드라이버에서 TLSv1.2 이상을 지원하는지를 사전에 체크해야 합니다.
관련된 내용은 핀다 기술 블로그를 참고하시면 됩니다.
Upgrade checker(UC) Utility
MySQL 을 업그레이드 하기전에 체크해야 할 사항은 사용하는 환경에 따라서 다양할 수 있으며 이럴 때, 간단하고 손쉽게 체크해 볼 수 있는 도구인 upgrade checker utility 기능이 MySQL Shell 8.0과 함께 도입이 되었습니다.
설치 방법 및 자세한 사항 아래 이전 포스팅을 참조하시면 됩니다.
MySQL Shell 을 설치하였다면 아래와 같이 실행해서 체크해 볼 수 있습니다.
mysqlsh -u 계정명 -p -h 접속주소 -e "util.checkForServerUpgrade();"
MySQL Shell 의 Upgrade checker 에서는 아래 21개 항목에 대해서 점검하고 결과를 Report 를 출력합니다.
1) Usage of old temporal type
2) Usage of db objects with names conflicting with new reserved keywords
3) Usage of utf8mb3 charset
4) Table names in the mysql schema conflicting with new tables in 8.0
5) Partitioned tables using engines with non native partitioning
6) Foreign key constraint names longer than 64 characters
7) Usage of obsolete MAXDB sql_mode flag
8) Usage of obsolete sql_mode flags
9) ENUM/SET column definitions containing elements longer than 255 characters
10) Usage of partitioned tables in shared tablespaces
11) Circular directory references in tablespace data file paths
12) Usage of removed functions
13) Usage of removed GROUP BY ASC/DESC syntax
14) Removed system variables for error logging to the system log configuration
15) Removed system variables
16) System variables with new default values
17) Zero Date, Datetime, and Timestamp values
18) Schema inconsistencies resulting from file removal or corruption
19) Tables recognized by InnoDB that belong to a different engine
20) Issues reported by 'check table x for upgrade' command
21) New default authentication plugin considerations
MySQL Shell 은 다양한 기능을 포함 및 제공하고 있으며 그 중에서 Dump/Load 기능에 대해서는 이전의 포스팅에서 자세하게 확인하실 수 있습니다.
Aurora Upgrade
업그레이드 방법론 및 사전 점검 사항을 확이 하였다면 Aurora MySQL 을 업그레이드를 진행합니다.
In-Place Upgrade
이제 Aurora 2.0에서 3.0 버전으로 업그레이드할 때 In-Place Upgrade 를 지원하기 때문에, 해당 방법을 먼저 살펴보면, In-Place Upgrade 는 그 절차 방법은 간단 합니다.
먼저 Aurora 3.0 버전에 맞는 클러스터 파라미터 그룹과 인스턴스 파라미터 그룹을 각각 미리 준비를 합니다.
물론 파라미터 그룹을 생성 후에 각 업무별로 또는 회사별로 정해진 파라미터 값을 설정합니다.
파라미터 그룹이 준비가 되었다면 작업 공지 페이지 및 트래픽 유입 차단을 하고 RDS 업그레이드를 진행합니다.
업그레이드하려는 클러스터를 선택 후에 Modify(수정) 메뉴를 선택합니다.
업그레이드를 하려는 버전을 선택을 합니다. 글에서는 작성 시점에서의 최신 버전인 3.02.2 을 선택하고 진행하였습니다.
Aurora 3.0 버전으로 선택 후에 아래로 스크롤을 내리면 클러스터 파라미터 그룹과 DB 파라미터 그룹이 3.0(MySQL 8.0) 의 Default 파라미터 그룹으로 자동으로 선택된 것을 확인할 수 있습니다.
파라미터 그룹을 사전에 생성한 파라미터 그룹으로 변경합니다.
기존 설정에서 추가적으로 변경할 것이 있다면 변경하고, 변경 선택을 완료하였다면 스크롤을 가장 하단으로 이동 후에 "Continue(계속)" 버튼을 클릭합니다.
변경 사항을 최종적으로 확인하고, 적용 시점을 선택합니다. Apply Immediately 는 지금 바로 업그레이드를 진행하는 옵션입니다.
선택이 완료되었다면 하단의 "Modify cluster" 버튼을 클릭합니다.
업그레이드가 시작되면 아래 이미지와 같이 클러스터와 Writer Instance, Reader Instance 모두 업그레이드가 진행되는 것을 확인할 수 있습니다. AWS Aurora MySQL 의 경우 이와 같이 Upgrade 에 대해서는 Rolling Upgrade 는 불가하며, 모든 인스턴스가 접속이 안되는 Downtime 상황이 되게 됩니다.
물론 웹 콘솔에서 보이는 Upgrading 이라는 상태값이 유지는 되는 전체 시간 동안 접속이 불가한 것은 아닙니다.
테스트 장비인 db.t3.medium 기준으로 Writer 인스턴스가 접속이 불가하고 다시 접속이 가능할 때가지의 시간은 약 820초 정도 소요되었습니다. (시간은 클래스나 상황에 따라 차이가 있습니다.)
클러스터 Recent Events 정보를 기준으로 작업의 총 소요시간은 약 18~20분 정도 소요되었으며, 그 중 Writer Instance 가 실질적으로 접속이 안되는 시간은 820초 = 약 13.6분 이었습니다.
(이 시간은 사용하는 RDS Class 및 시스템 상황에 따라 달라집니다.)
업그레이드가 완료되어 접속이 되는 상태 이후에 아래와 같이 후속 작업 형태로 Performance Insights 나 enhanced-monitoring 을 활성화하는 과정이 수행될 수 있습니다. 그 과정에서는 사용하는 RDS의 클래스에 따라서 설정을 진행하는 과정에서 CPU 사용이 높아 질수도 있습니다.
그러므로 CPU 가 어느정도 안정화 될때 까지 기다린 후에 애플리케이션을 접속하여 테스트나 업무의 시작을 하시는 것도 좋을 것이라고 생각 합니다.
작업의 절차는 간편하나, Out-Of-Place 로 업그레이드를 진행하는 것에 비해서는 확실히 시간적 소요가 많이 된다고 할 수 있습니다.
Out-Of-Place Upgrade
이번에는 Out-Of-Place Upgrade 방식으로 진행했을 때 수행되는 절차에 대해서 확인해보도록 하겠습니다.
실제 운영에서 이 방법으로 진행할 때 2가지 정도를 선행적으로 고민을 해야 합니다.
- binlog 활성화를 위한 재시작(또는 Failover)
- blue-green 방식에서의 접속 방식의 변경
먼저 binlog 활성화입니다. 클러스터 파라미터에서 binlog_format 파라미터를 변경한 후에 인스턴스들을 각각 재시작 하거나, Failover 를 하여 동시에 재시작 하는 형태로 진행할 수 있습니다.
Aurora MySQL 의 Failover는 매우 짧은 시간안에 이루어지지만, 짧은 그 사이에 업무 트랜잭션이 실패하거나 업무가 정상적으로 수행이 되지 않는 등의 이슈가 있을 수 있습니다. 업그레이드를 하려고 하는 AWS Aurora 가 binlog 활성화가 안되어 있을 경우 활성화에 대한 작업 일정을 수립하고, binlog 활성화를 해야 합니다.
이 과정에서 실제로 짧은 시간이지만 업무적인 다운타임에 대비하거나 유관 부서와 일정 논의 및 협의가 필요하며, binlog 를 활성화하게 되면 기본설정인 binlog 비활성화에 비해서 상대적으로 CPU 자원 소모가 더 될 수도 있다는 점입니다.
두번째 고려해야 할 부분으로는 blue(현재 버전) 과 green(신규 버전) 간의 커넥션(세션)을 어떤 형태로 이동할지에 대한 부분입니다.
예를 들어 애플리케이션에서 새로운 버전인 green 클러스터의 Endpoint 정보대로 수정하여 재기동 하는 형태로 해서 새로운 버전의 클러스터 인스턴스로 접속을 하는 형태가 있을 것이며, 방법은 여러가지가 있을 수 있습니다.(가장 일반적인 방법)
참고) Amazon Aurora 및 RDS의 완전관리형 블루/그린 배포를 사용하게 되면 Aurora Cluster Endpoint 가 블루/그린 간에 서로 자동으로 교체를 지원합니다.
즉, 전환(Switch over) 수행을 하게 되면 Green 인스터스의 주소가 기존에 사용한 Blue 인스턴스 주소로 변경되는 기능입니다. 자세한 사항은 아래 링크를 참조하세요
다른 방법으로는 서브 도메인 과 CNAME 을 이용하는 방법입니다.
별도의 서브 도메인(접속용) 을 생성하여 CNAME Record에 Cluster endpoint 를 등록합니다.
애플리케이션의 접속 설정에서는 신규 생성한 서브 도메인으로 설정을 해둔다면, 새로운 버전의 green 클러스터로 전환시에 route53 에서 CNAME Record 갱신과 Reconnect 옵션이 있을 경우 DB에서 세션을 정리하게 되면 새로운 버전의 green 클러스터로 세션이 이동되게 할 수도 있습니다.
이 과정에서는 데이터 정합성 등을 위해서 현재 버전의 blue 클러스터에는 read_only=on 으로 변경하는 것도 하나의 방법이 될 수 있습니다.
또 다른 방법으로 HAProxy 나 다른 Proxy 툴을 통해서 접속하는 환경을 사전에 구성 및 애플리케이션에서는 Proxy 를 통해서 접속하도록 변경하고, 새로운 버전 green 클러스터로 이전시에는 Proxy 에서 트래픽을 blue 에서 green 으로 변경하는 방법을 사용할 수도 있습니다.
이처럼 현재 버전의 blue 에서 신규 버전인 green 으로의 전환 방식도 사전에 논의와 고려, 그리고 필요하다면 사전에 환경 구성이 필요한 부분입니다.
binlog 활성화
AWS Aurora MySQL 는 바이너리 로그를 통한 복제 방식을 사용하고 있지 않기 때문에 기본적으로는 바이너리 로그는 활성화되어 있지 않습니다. 그래서 위에서 설명한 내용처럼 바이너리 로그를 별도로 활성화를 해야 합니다.
바이너리 로그를 활성화하기 위해서 클러스터 파라미터 그룹을 수정해야 합니다. 클러스터에서 Configuration 탭으로 이동한 뒤에 사용중인 클러스터 파리미터 그룹을 클릭합니다.
binlog_format 으로 검색 후에 체크하고 "Edit parameters" 버튼을 클릭합니다.
OFF 에서 다른 값(ROW 나 MIXED)으로 변경 후에 "Save changes" 버튼을 클릭합니다.
포스팅에서 사용하는 테스트 시스템은 Writer , Reader 2대 임으로 Failover 를 통해서 2개 동시에 재시작을 하겠습니다.
인스턴스가 여러 개라면 각각 재시작을 하면 됩니다.
하단의 "Failover" 버튼을 클릭하여 진행을 시작합니다.
재시작 및 Failover 가 완료되었다면 DB에 접속하여 binlog 가 생성되었는지를 확인합니다.
mysql> show master status\G
*************************** 1. row ***************************
File: mysql-bin-changelog.000005
Position: 154
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.03 sec)
mysql> show binary logs;
+----------------------------+-----------+
| Log_name | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.000001 | 154 |
| mysql-bin-changelog.000002 | 154 |
| mysql-bin-changelog.000003 | 154 |
| mysql-bin-changelog.000004 | 154 |
| mysql-bin-changelog.000005 | 154 |
+----------------------------+-----------+
복제본에 대한 데이터베이스의 초기 복사가 완료되고 복제가 설정되기 전까지 binlog 파일은 보존이 되어있어야 합니다.
binlog 파일의 보관 기간을 설정이 필요하며, 이 설정을 지정하지 않으면 Aurora MySQL 에서 기본값은 NULL입니다.
NULL 설정은 Aurora MySQL 의 바이너리 로그가 특정 기간(보통 하루 이하) 시스템에 남아 있을 수 있습니다.
현재 binlog 보관 주기에 대한 정보는 rds_show_configuration 를 통해서 확인할 수 있습니다.
mysql> CALL mysql.rds_show_configuration; +------------------------+-------+------------------------------------------+ | name | value | description | +------------------------+-------+------------------------------------------+ | binlog retention hours | NULL | binlog retention hours specifies | | | | the duration in hours before binary logs | | | | are automatically deleted. | +------------------------+-------+------------------------------------------+
기본적으로는 설정 값은 NULL 이며, NULL 의 경우 보통 24시간 미만 정도이며, 상황에 따라서 보존 시간은 더 짧아질 수 있습니다.
그래서 업그레이드하는 과정에서는 binlog 보관 주기를 어느정도 길게 설정할 필요성이 있으며, 아래는 binlog 파일 보관주기를 7일로 설정하는 내용입니다.
binlog 보관기간은 168시간=7일까지 설정할 수 있습니다.
mysql> CALL mysql.rds_set_configuration('binlog retention hours', 168);
mysql> CALL mysql.rds_show_configuration;
+------------------------+-------+------------------------------------------+
| name | value | description |
+------------------------+-------+------------------------------------------+
| binlog retention hours | 168 | binlog retention hours specifies |
| | | the duration in hours before binary logs |
| | | are automatically deleted. |
+------------------------+-------+------------------------------------------+
binlog 를 활성화하였다면 다음에는 snapshot 을 생성하거나 binlog 를 활성화한 이후 생성된 백업본을 통해서 새로운 버전의 Cluster 를 생성을 진행합니다.
binlog I/O cache
바이너리 로그를 활성화하게 되면 binlog 이벤트에 대한 로깅이 트랜잭션 커밋과 같은 중요한 작업의 일부와 통합되기 때문에 데이터베이스 성능을 저하시킬 수 있습니다.(커밋 대기 시간 증가 및 처리량 감소)
일반적인 MySQL에서는 binlog 파일을 로컬 스토리지(디스크)에 작성하게 되지만, Aurora MySQL은 binlog 파일을 Aurora 스토리지 엔진에 쓰게 됩니다.
MySQL은 binlog 이벤트를 binlog 파일에 쓸 뿐만 아니라 동일한 파일에서 binlog 이벤트를 읽기 때문에 MySQL이 이러한 binlog 이벤트를 다른 MySQL 데이터베이스로 복제하기 시작할 때 binlog 파일에 의해 성능 병목 현상이 발생될 수도 있습니다.
Aurora MySQL 2.10 버전부터(3.0 버전도 포함) 이와 같은 성능 저하 사례를 개선하기 위해 binlog I/O 캐시라는 새로운 기능이 도입되었으며, Aurora MySQL은 바이너리 로그를 활성화하면 binlog 이벤트를 동일한 파일에 능동적으로 복제합니다.
binlog I/O 캐시는 최신 binlog 이벤트를 순환 캐시(circular cache)에 보관하여 Aurora 스토리지 엔진의 읽기 I/O를 최소화합니다.
(binlog I/O 캐시는 db.t2 및 db.t3 인스턴스 클래스를 제외한 대부분의 Aurora MySQL 인스턴스에서 활성화됩니다.)
다음 그래프에서는 binlog I/O 캐시를 켜고(파란색 선), binlog I/O 캐시 끄고(주황색 선) 초당 평균 쓰기 수를 측정했습니다. 이는 binlog I/O 캐시를 통해 얻을 수 있는 처리량 향상을 보여 주고 있습니다.
[그래프]
또한 그래프에서 "without Replica" 설정 처리량은 회색 선으로 표시되어 있으며, 읽기 전용 복제본의 I/O 경합 없이 최적의 성능을 보여 줍니다.
이는 binlog I/O 캐시가 활성화되면 원본 인스턴스가 쓰기 처리량(파란색)의 증가에 따라 복제본이 연결되지 않은 것처럼(회색) 최적의 쓰기 처리량으로 확장될 수 있음을 보여 줍니다.
snapshot 생성
binlog 활성화 이후에는 Snapshot 을 생성하여 새로운 버전의 클러스터를 생성하거나 또는 binlog 활성화 이후 수행된 백업을 통해서 새로운 버전 클러스터를 생성해야 합니다.
snapshot 은 클러스터 또는 인스턴스를 생성 후에 Actions 메뉴에서 기능을 찾을 수 있습니다.
"Take snapshot" 을 선택합니다.
snapshot 이름을 입력하고 아래 "Take snapshot" 버튼을 클릭합니다.
snapshot 생성이 시작되면 아래와 같이 진행 상태를 확인할 수 있습니다.
snapshot 생성도 백업과 동일한 것임으로 아래와 같이 상태가 "Backing-up" 이라고 확인할 수 있습니다.
백업이 수행되는 만큼 가급적 DB 사용이 적은 시간에 수행하는 것이 업무적 영향도를 줄일 수 있는 부분이라고 생각 합니다.
snapshot 생성이 완료될 때까지 잠시 대기합니다.
New Version Cluster 생성
snapshot 생성이 완료되었다면 snapshot 을 통해서 새로운 버전의 Aurora Cluster 를 생성하도록 하겠습니다.
이 과정도 In-Place Upgrade 와 동일하게 진행 전에 Aurora 3.0(MySQL 8.0) 용 클러스터,DB 파라미터 그룹을 먼저 준비해야 합니다.
생성된 snapshot 을 선택 후 Actions 메뉴에서 "Restore snapshot" 을 선택합니다.
먼저 버전을 선택을 하면 되며 업그레이드할 목표(새로운) 버전을 선택합니다.
그 다음으로 생성될 인스턴스 이름을 입력합니다. 클러스터 이름은 입력한 이름 뒤에 -cluster 가 붙는 네이밍으로 생성됩니다.
운영 네이밍 규칙에 맞지 않는다면 생성된 후 클러스터 및 인스턴스 이름을 변경하면 됩니다.
미리 생성 해둔 Aurora 3.0(MySQL 8.0) 버전용 파라미터 그룹으로 선택합니다.
그 외 다른 변경할 설정이 있는지 확인하고 필요 시 변경하며, 완료되었다면 하단의 "Restore DB Cluster" 버튼을 클릭하여 새로운 클러스터 생성을 시작합니다.
생성이 시작하면 아래와 같이 클러스터 1개, Writer 인스턴스 1개가 생성되고 있는 것을 확인할 수 있습니다.
생성이 완료되면 먼저 Point-in-Time Recovery 으로 인스턴스 생성(복구에 의한 생성)시 사용된 binlog 정보를 확인해야 합니다.
아래 이미지와 같이 Log & events 탭에서 Recent Events 정보에서 확인할 수 있으며 "Binlog position" 으로 검색하면 쉽게 찾을 수 있습니다.
간혹 인스턴스 이름을 변경 후에 위의 이미지 내용의 Recent events 가 확인이 안되는 경우가 있으니, 인스턴스 이름을 변경할 예정이라면 변경 전에 먼저 위의 정보를 별도로 기록 해두시면 됩니다.
만약 인스턴스 이름을 변경 후에 binlog 파일번호와 pos 번호가 확인이 안된다면 aws cli 명령어에서 "describe-events" 를 통해서 조회하시면 됩니다.
현재 상태에서는 Writer 1개의 인스턴스만 존재함으로 지금 단계에서 Reader 인스턴스 추가 및 인스턴스 이름의 재설정(변경) 등을 진행하시면 됩니다.
참고로 Reader 추가는 클러스터 선택 -> Actions -> Add reader 을 선택해서 진행하시면 됩니다.
복제를 설정하기 위해서 우선 복제 연결을 위한 유저를 생성해야 합니다.
현재 사용중인 버전의 Source 인스턴스(blue 클러스터 인스턴스) 에서 아래와 같이 복제 전용 유저를 생성합니다.
create user repl_uesr identified with 'mysql_native_password' by '비밀번호'; grant replication client, replication slave on *.* to repl_uesr; flush privileges;
복제 설정은 복제가 이루어지는 Replica Side 인스턴스(클러스터) 에서 진행하면 됩니다. snapshot 으로 생성된 인스턴스로 접속하여 아래와 같이 프로시저를 이용해서 복제를 설정 및 복제를 시작합니다.
-- 복제 설정
CALL mysql.rds_set_external_source ('rds-an2-hyunho-test-aurora.cluster-cqozlidrgu5j.ap-northeast-2.rds.amazonaws.com', 3306, 'repl_uesr', '비밀번호', 'mysql-bin-changelog.000005', 154, 0);
-- 복제 시작
CALL mysql.rds_start_replication;
첫 번째 인자는 복제대상(Source) 접속 주소이며, 두 번째 인자는 포트 번호, 세 번째 와 네 번째 인자는 복제를 위해 생성한 복제 유저 정보이고, 다섯 번째와 여섯 번째 인자는 위에서 확인한 복제 설정을 위한 binlog 파일과 pos 정보입니다.
복제가 설정 및 시작이 되었다면 아래와 같이 복제 상태를 확인하고, 추가적으로 데이터를 정상적으로 복제가 되는지 확인합니다.
mysql> show replica status\G
*************************** 1. row ***************************
Replica_IO_State: Waiting for master to send event
Source_Host: rds-an2-hyunho-test-aurora.cluster-cqozlidrgu5j.ap-northeast-2.rds.amazonaws.com
Source_User: repl_uesr
Source_Port: 3306
Connect_Retry: 60
Source_Log_File: mysql-bin-changelog.000005
Read_Source_Log_Pos: 770
Relay_Log_File: relaylog.000004
Relay_Log_Pos: 277
Relay_Source_Log_File: mysql-bin-changelog.000005
Replica_IO_Running: Yes <-- 정상
Replica_SQL_Running: Yes <-- 정상
< ... 중략 ... >
한가지 유의할 점은 external replication 으로 복제를 설정한 상태이기 때문에 복제가 되는 클러스터(인스턴스)에서 별도로 설정하지 않았다면 현재 인스턴스의 read_only 상태가 아닌 쓰기가 가능한 상태 라는 것입니다.
mysql> show variables like '%read_only%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_read_only | OFF | | read_only | OFF | | super_read_only | OFF | | transaction_read_only | OFF | +-----------------------+-------+
그래서 애플리케이션 호환성 테스트 등을 진행 시 데이터 조회 쿼리 수행은 문제가 없겠으나 DML 쿼리가 수행될 경우 복제가 중지가 될 수 있으며 데이터 정합성이 맞지 않게 될 수도 있습니다. 기본적인 상태는 쓰기가 가능한 상태의 인스턴스라는 점에 대해서는 체크 해둘 필요성은 있습니다.
복제가 완료된 상태임으로 새로운 green 클러스터로 전환 시, 위에서 설명한 내용 처럼 이관 전략에 따라서 새로운 버전으로 이동하시면 됩니다.
새로운 버전으로 이관이 완료되었다면 복제 설정 정보 삭제가 필요할 수 있습니다. 설정된 복제에 대한 삭제는 아래와 같이 수행합니다.
-- 복제 중지 CALL mysql.rds_stop_replication; -- 복제 정보 삭제 call mysql.rds_reset_external_source;
Reference
Reference URL
• amazon.com/aurora-supports-in-place-upgrades
• amazon.com/MajorVersionUpgrade
• amazon.com/Uprading.BlueGreenBlog
• amazon.com/upgrades-aurora-mysql-minimum-downtime
• amazon.com/AuroraMySQL.Replication
• amazon.com/aurora-mysql-improve-binlog-performance
• mysql.com/keywords-8-0-detailed-C
연관된 다른 글
Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중
Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io
글 잘봤습니다
소중한 코멘트 감사합니다.
좋은 하루 되세요