DB 클러스터의 Amazon Aurora MySQL 메이저 버전 업그레이드 - Amazon Aurora
Aurora MySQL 2.x에서 3.x로 업그레이드Aurora MySQL 클러스터에 대한 주 버전 업그레이드 계획 Aurora MySQL에 대한 메이저 버전 업그레이드 사전 확인Aurora MySQL 주 버전 업그레이드 경로Aurora MySQL 현재 위치 주 버전 업그레이드 작동 방식대체 블루-그린 업그레이드 기술현재 위치 업그레이드 수행 방법현재 위치 업그레이드가 클러스터의 파라미터 그룹에 미치는 영향Aurora MySQL 버전 간의 클러스터 속성 변경글로벌 데이터베이스에 대한 현재 위치 메이저 업그레이드역추적 고려 사항Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결Aurora MySQL 현재 위치 업그레이드 자습서

DB 클러스터의 Amazon Aurora MySQL 메이저 버전 업그레이드

2.12.1과 같은 Aurora MySQL 버전 번호에서 2는 메이저 버전을 나타냅니다. Aurora MySQL 버전 2는 MySQL 5.7과 호환됩니다. Aurora MySQL 버전 3은 MySQL 8.0과 호환됩니다.

주 버전 간에 업그레이드하려면 부 버전보다 더 광범위한 계획 및 테스트가 필요합니다. 이 과정은 상당한 시간이 걸릴 수 있습니다. 업그레이드가 완료되면 후속 작업을 수행해야 할 수도 있습니다. 예를 들어 SQL 호환성의 차이 또는 특정 MySQL 관련 기능의 작동 방식 때문에 이러한 문제가 발생할 수 있습니다. 또는 이전 버전과 새 버전 간의 파라미터 설정이 다르기 때문에 발생할 수 있습니다.

Aurora MySQL 2.x에서 3.x로 업그레이드

MySQL 5.7 호환 클러스터가 있고 이를 MySQL 8.0 호환 클러스터로 업그레이드하려는 경우 클러스터 자체에서 업그레이드 프로세스를 실행하여 업그레이드할 수 있습니다. 이러한 종류의 업그레이드는 새 클러스터를 생성하여 수행하는 업그레이드와 달리 현재 위치 업그레이드입니다. 이 기술은 클러스터의 동일한 엔드포인트 및 기타 특성을 유지합니다. 해당 업그레이드는 모든 데이터를 새 클러스터 볼륨으로 복사할 필요가 없기 때문에 비교적 빠릅니다. 이러한 안정성은 애플리케이션 내 구성 변경을 최소화하는 데 도움이 됩니다. 또한 업그레이드된 클러스터에 대한 테스트 횟수를 줄이는 데도 도움이 됩니다. DB 인스턴스와 인스턴스 클래스의 수가 모두 동일하게 유지되기 때문입니다.

현재 위치 업그레이드 메커니즘에는 작업이 진행되는 동안 DB 클러스터를 종료하는 작업이 포함됩니다. Aurora는 완전히 종료하고 트랜잭션 롤백 및 제거 실행 취소와 같은 미결 작업을 완료합니다. 자세한 내용은 Aurora MySQL 현재 위치 주 버전 업그레이드 작동 방식 섹션을 참조하세요.

현재 위치 업그레이드 방법은 수행 방법이 단순하며 관련 애플리케이션에 대한 구성 변경을 최소화하므로 편리합니다. 예를 들어, 현재 위치 업그레이드는 클러스터의 엔드포인트 및 DB 인스턴스 세트를 보관합니다. 그러나 현재 위치 업그레이드에 필요한 시간은 스키마의 속성과 클러스터 사용 수준에 따라 달라질 수 있습니다. 따라서 클러스터의 요구 사항에 따라 여러 업그레이드 기법 중에서 선택할 수 있습니다. 여기에는 DB 클러스터 스냅샷에서 복원에서 설명한 대로 현재 위치 업그레이드 및 스냅샷 복원이 포함됩니다. 또한 대체 블루-그린 업그레이드 기술에서 설명한 것과 같은 다른 업그레이드 기법도 포함됩니다.

참고

스냅샷 복원 업그레이드 방법에 AWS CLI 또는 RDS API를 사용할 경우, 후속 작업을 실행하여 복원된 DB 클러스터에서 라이터 DB 인스턴스를 생성해야 합니다.

Aurora MySQL 버전 3 및 새로운 기능에 대한 일반적인 정보는 Aurora MySQL 버전 3은 MySQL 8.0과 호환 섹션을 참조하세요. 업그레이드 계획에 대한 자세한 내용은 Aurora MySQL 버전 3에 대한 업그레이드 계획 및 Aurora MySQL 버전 3으로 업그레이드을 참조하세요.

작은 정보

클러스터의 메이저 버전을 2.x에서 3.x로 업그레이드하면 원래 클러스터와 업그레이드된 클러스터는 모두 engine 속성을 위해 동일한 aurora-mysql 값을 사용합니다.

Aurora MySQL 클러스터에 대한 주 버전 업그레이드 계획

메이저 버전 간의 클러스터를 업그레이드한 후 애플리케이션 및 관리 절차가 원활하게 작동하도록 하려면 몇 가지 사전 계획 및 준비 작업을 수행하세요. AWS CLI 스크립트 또는 RDS API 기반 애플리케이션에 대해 업데이트하려는 관리 코드의 종류를 확인하려면 현재 위치 업그레이드가 클러스터의 파라미터 그룹에 미치는 영향 섹션을 참조하세요. Aurora MySQL 버전 간의 클러스터 속성 변경 단원도 참조하세요.

업그레이드 중에 발생할 수 있는 문제를 알아보려면 Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결 섹션을 참조하세요. 업그레이드 시간이 오래 걸릴 수 있는 문제를 대상으로 이러한 조건을 미리 테스트 및 수정할 수 있습니다.

업그레이드된 클러스터에 대한 애플리케이션 호환성, 성능, 유지 관리 절차 및 이와 유사한 고려 사항을 확인할 수 있습니다. 이를 위해 실제 업그레이드를 수행하기 전에 업그레이드 시뮬레이션을 수행할 수 있습니다. 이 기술은 생산 클러스터에 특히 유용할 수 있습니다. 여기서 가동 중지 시간을 최소화하고, 업그레이드가 완료되는 즉시 업그레이드된 클러스터를 준비하는 것이 중요합니다.

다음 단계를 사용합니다.

  1. 기존 클러스터의 클론을 생성합니다. Aurora DB 클러스터에 대한 볼륨 복제의 절차를 따르십시오.

  2. 기존 클러스터에서처럼 유사한 라이터 및 리더 DB 인스턴스 세트를 설정합니다.

  3. 클론 클러스터의 현재 위치 업그레이드 수행 현재 위치 업그레이드 수행 방법의 절차를 따르십시오.

    클론을 생성한 후 즉시 업그레이드를 시작합니다. 이러면 클러스터 볼륨이 기존 클러스터의 상태와 여전히 동일합니다. 업그레이드를 수행하기 전에 클론이 유휴 상태인 경우 Aurora 는 백그라운드에서 데이터베이스 정리 프로세스를 수행합니다. 이 경우 클론 업그레이드는 기존 클러스터 업그레이드의 정확한 시뮬레이션이 아닙니다.

  4. 복제된 클러스터를 사용하여 응용 프로그램 호환성, 성능, 관리 절차 등을 테스트합니다.

  5. 문제가 발생하면 업그레이드 계획을 조정하여 해당 문제를 해결하세요. 예를 들어 모든 애플리케이션 코드를 상위 버전의 기능 세트와 호환되도록 조정합니다. 클러스터의 데이터 양에 따라 업그레이드에 걸리는 시간을 예측합니다. 클러스터를 사용하지 않을 때 업그레이드를 예약하도록 선택할 수도 있습니다.

  6. 애플리케이션 및 워크로드가 테스트 클러스터에서 제대로 작동하면, 생산 클러스터에 현재 위치 업그레이드를 수행할 수 있습니다.

  7. 메이저 버전 업그레이드 중 클러스터의 총 가동 중지 시간을 최소화하기 위한 노력을 기울이세요. 그러기 위해서는 업그레이드 시 클러스터의 워크로드가 낮거나 0인지 확인해야 합니다. 특히 업그레이드를 시작할 때 진행 중인 장기 실행 트랜잭션이 없는지 확인하십시오.

Aurora MySQL 버전 3으로의 업그레이드에 대한 자세한 내용은 Aurora MySQL 버전 3에 대한 업그레이드 계획 섹션을 참조하세요.

Aurora MySQL에 대한 메이저 버전 업그레이드 사전 확인

MySQL 8.0에는 MySQL 5.7과 상당한 비호환성이 포함되어 있습니다. 이러한 비호환성으로 인해 MySQL 버전 2에서 버전 3으로 업그레이드하는 동안 문제가 발생할 수 있습니다. 업그레이드가 성공하려면 데이터베이스에 몇 가지 준비가 필요할 수 있습니다.

Aurora MySQL 버전 2에서 버전 3으로 업그레이드를 시작하면 Amazon Aurora가 자동으로 사전 확인을 실행하여 이러한 비호환성을 찾아냅니다.

이러한 사전 점검은 필수입니다. 건너뛸 수 없습니다. 사전 점검은 다음과 같은 이점을 제공합니다.

  • 이를 통해 업그레이드 중 예기치 않은 가동 중단을 피할 수 있습니다.

  • 비호환성이 있는 경우 Amazon Aurora가 업그레이드를 차단하고 이에 대해 알 수 있는 로그를 제공합니다. 그러면 로그를 사용해 비호환성을 제거함으로써 버전 3으로 업그레이드하기 위한 데이터베이스 준비를 마칠 수 있습니다. 비호환성 문제를 제거하는 방법에 대한 자세한 내용은 MySQL 설명서의 업그레이드를 위한 설치 준비 및 MySQL Server 블로그의  MySQL 8.0으로 업그레이드할 때 알아야 할 내용을 참조하세요.

    MySQL 8.0으로 업그레이드하는 방법에 대한 자세한 내용은 MySQL 설명서에서 MySQL 업그레이드를 참조하세요.

사전 확인에는 MySQL에 포함된 내용과 Aurora 팀에서 생성한 내용이 포함됩니다. MySQL에서 제공하는 사전 점검에 대한 자세한 내용은 업그레이드 확인 프로그램 유틸리티를 참조하십시오.

사전 점검은 업그레이드를 위해 DB 인스턴스가 중지되기 전에 실행됩니다. 즉, 점검을 실행해도 가동 중지를 일으키지 않습니다. 사전 확인에서 비호환성이 발견되면 Aurora는 DB 인스턴스가 중지되기 전에 자동으로 업그레이드를 취소합니다. 또한 Aurora는 비호환성에 대한 이벤트를 생성합니다. Amazon Aurora 이벤트에 대한 자세한 내용은 Amazon RDS 이벤트 알림 작업 섹션을 참조하세요.

Aurora는 각 비호환성에 대한 자세한 정보를 로그 파일 PrePatchCompatibility.log에 기록합니다. 대부분의 경우 로그 항목에는 비호환성 문제를 해결하기 위한 MySQL 설명서 링크가 포함되어 있습니다. 로그 파일 보기에 대한 자세한 내용은 데이터베이스 로그 파일 보기 및 나열 단원을 참조하십시오.

사전 점검의 특성으로 인해 데이터베이스의 객체를 분석합니다. 이 분석은 리소스를 소비하고 업그레이드가 완료되는 시간을 늘립니다.

커뮤니티 MySQL 업그레이드 사전 확인

MySQL 버전 5.7 및 8.0 간의 일반적인 비호환 목록은 다음과 같습니다.

  • MySQL 8.0에 지원되지 않는 기능을 MySQL 5.7 호환 DB 클러스터에서 사용해서는 안 됩니다.

    자세한 내용은 MySQL 설명서의 MySQL 8.0에서 제거된 기능을 참조하십시오.

  • 키워드 또는 예약된 단어 위반이 없어야 합니다. 이전에 예약되지 않은 일부 키워드는 MySQL 8.0에서 예약할 수 있습니다.

    자세한 내용은 MySQL 설명서의 키워드 및 예약어를 참조하십시오.

  • 유니코드 지원을 개선하기 위해 utf8mb3 charset을 사용하는 객체가 utf8mb4 charset을 사용하도록 변환하는 것을 고려하십시오. utf8mb3 문자 집합은 사용되지 않습니다. 또한, 현재 utf8mb4은 utf8 charset의 별칭이므로 utf8 대신 문자 집합 참조를 위한 utf8mb3 사용을 고려하십시오.

    자세한 내용은 MySQL 설명서의 utf8mb3 문자 집합(3바이트 UTF-8 유니코드 인코딩)을 참조하십시오.

  • 기본값이 아닌 행 형식을 가진 InnoDB 테이블은 없어야 합니다.

  • ZEROFILL 또는 display 길이 유형 속성이 없어야 합니다.

  • 기본 파티셔닝 지원이 없는 스토리지 엔진을 사용하는 분할된 테이블이 없어야 합니다.

  • MySQL 5.7 mysql 시스템 데이터베이스에는 MySQL 8.0 데이터 딕셔너리가 사용하는 테이블과 동일한 이름의 테이블이 없어야 합니다.

  • 사용되지 않는 데이터 형식이나 함수를 사용하는 테이블이 없어야 합니다.

  • 64자를 초과하는 외래 키 제약 조건 이름이 없어야 합니다.

  • sql_mode 시스템 변수 설정에 정의된 사용되지 않는 SQL 모드가 없어야 합니다.

  • 255자 길이를 초과하는 개별 ENUM 또는 SET 열 요소가 있는 테이블이나 저장 프로시저가 없어야 합니다.

  • 공유 InnoDB 테이블스페이스에 있는 테이블 파티션이 없어야 합니다.

  • 테이블스페이스 데이터 파일 경로에는 순환 참조가 없어야 합니다.

  • GROUP BY 절에서 ASC 또는 DESC 한정자를 사용하는 쿼리 및 저장 프로그램 정의가 없어야 합니다.

  • 제거된 시스템 변수가 없어야 하며, 시스템 변수는 MySQL 8.0의 새 기본값을 사용해야 합니다.

  • 날짜, 날짜/시간 또는 타임스탬프 값이 0(영)이면 안 됩니다.

  • 파일 제거 또는 손상으로 인한 스키마 불일치가 없어야 합니다.

  • FTS 문자열을 포함하는 테이블 이름이 없어야 합니다.

  • 다른 엔진에 속하는 InnoDB 테이블이 없어야 합니다.

  • MySQL 5.7에 유효하지 않은 테이블 또는 스키마 이름이 없어야 합니다.

MySQL 8.0으로 업그레이드하는 방법에 대한 자세한 내용은 MySQL 설명서에서 MySQL 업그레이드를 참조하세요.

Aurora MySQL 업그레이드 사전 확인

Aurora MySQL에는 버전 2에서 버전 3으로 업그레이드하는 데 필요한 고유한 요구 사항이 있습니다.

  • 뷰, 루틴, 트리거 및 이벤트에는 SQL_CACHE, SQL_NO_CACHE, QUERY_CACHE와 같이 더 이상 사용되지 않는 SQL 구문이 없어야 합니다.

  • FTS 인덱스가 없는 테이블에는 FTS_DOC_ID 열이 없어야 합니다.

  • InnoDB 데이터 사전과 실제 테이블 정의 간에 열 정의 불일치가 없어야 합니다.

  • lower_case_table_names 파라미터를 1로 설정하는 경우 모든 데이터베이스 및 테이블 이름은 소문자여야 합니다.

  • 이벤트 및 트리거에는 누락되었거나 빈 definer 또는 잘못된 생성 컨텍스트가 없어야 합니다.

  • 데이터베이스의 모든 트리거 이름은 고유해야 합니다.

  • Aurora MySQL 버전 3에서는 DDL 복구 및 빠른 DDL이 지원되지 않습니다. 데이터베이스에는 이러한 기능과 관련된 아티팩트가 없어야 합니다.

  • REDUNDANT 또는 COMPACT 행 형식의 테이블은 767바이트보다 큰 인덱스를 가질 수 없습니다.

  • tiny 텍스트 열에 정의된 인덱스의 접두사 길이는 255바이트를 초과할 수 없습니다. utf8mb4 문자 집합의 경우 지원되는 접두사 길이가 63자로 제한됩니다.

    MySQL 5.7에서는 innodb_large_prefix 파라미터를 사용하여 더 큰 접두사 길이를 허용했습니다. 이 파라미터는 MySQL 8.0에서 더 이상 사용되지 않습니다.

  • mysql.host 테이블에 InnoDB 메타데이터 불일치가 없어야 합니다.

  • 시스템 테이블에 열 데이터 유형 불일치가 없어야 합니다.

  • prepared 상태의 XA 트랜잭션이 없어야 합니다.

  • 클러스터의 HLL(기록 목록 길이)이 1백만 개보다 크면 업그레이드 시간이 더 걸릴 수 있습니다.

    자세한 내용은 Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결 섹션을 참조하세요.

  • 뷰의 열 이름은 64자를 초과할 수 없습니다.

  • 저장 프로시저의 특수 문자 불일치가 없어야 합니다.

  • 테이블에 데이터 파일 경로 불일치가 없어야 합니다.

Aurora MySQL 주 버전 업그레이드 경로

모든 종류 또는 버전의 Aurora MySQL 클러스터가 현재 위치 업그레이드 메커니즘을 사용할 수 있는 것은 아닙니다. 다음 테이블을 참조하여 각 Aurora MySQL 클러스터에 대한 적절한 업그레이드 경로를 확인할 수 있습니다.

Aurora MySQL DB 클러스터 유형 현재 위치 업그레이드를 사용할 수 있습니까? 작업

Aurora MySQL 프로비저닝된 클러스터(2.0 이상)

예

현재 위치 업그레이드는 5.7 호환 Aurora MySQL 클러스터에 지원됩니다.

Aurora MySQL 버전 3으로의 업그레이드에 대한 자세한 내용은 Aurora MySQL 버전 3에 대한 업그레이드 계획 및 Aurora MySQL 버전 3으로 업그레이드 섹션을 참조하세요.

Aurora MySQL 프로비저닝된 클러스터(3.01.0 이상)

N/A

마이너 버전 업그레이드 절차를 사용하여 Aurora MySQL 버전 3 간에 업그레이드하세요.

Aurora Serverless v1 클러스터

N/A

현재 Aurora Serverless v1는 Aurora MySQL의 버전 2에서만 지원됩니다.

Aurora Serverless v2 클러스터

N/A

 현재 Aurora Serverless v2는 Aurora MySQL의 버전 3에서만 지원됩니다.

Aurora Global Database의 클러스터

예

Aurora MySQL을 버전 2에서 버전 3으로 업그레이드하려면 Aurora Global Database에 있는 클러스터에 대한 현재 위치 업그레이드 수행 방법을 따르세요. 글로벌 클러스터에 업그레이드를 수행합니다. Aurora는 기본 클러스터와 글로벌 데이터베이스의 모든 보조 클러스터를 동시에 업그레이드합니다.

AWS CLI 또는 RDS API를 사용한다면, modify-global-cluster 명령 또는 ModifyGlobalCluster 작업을 modify-db-cluster 또는 ModifyDBCluster 대신 호출합니다.

lower_case_table_names 파라미터가 활성화 되어 있는 경우 Aurora MySQL 버전 2에서 버전 3으로 현재 위치 업그레이드를 수행할 수 없습니다. 자세한 내용은 메이저 버전 업그레이드 섹션을 참조하세요.

병렬 쿼리 클러스터

예

현재 위치 업그레이드를 수행할 수 있습니다. 이 경우 Aurora MySQL 버전에 대해 2.09.1 이상을 선택하십시오.

이진 로그 복제 대상인 클러스터

가능

Aurora MySQL 클러스터에서 바이너리 로그 복제를 했다면 현재 위치 업그레이드를 수행할 수 있습니다. 바이너리 로그 복제가 RDS for MySQL 또는 온프레미스 MySQL DB 인스턴스에서 생성되었다면 업그레이드를 수행할 수 없습니다. 이 경우 스냅샷 복원 메커니즘을 사용하여 업그레이드할 수 있습니다.

DB 인스턴스가 0인 클러스터

아니요

AWS CLI 또는 RDS API를 사용하여 연결된 DB 인스턴스 없이 Aurora MySQL 클러스터를 생성할 수 있습니다. 같은 방법으로 Aurora MySQL 클러스터 볼륨의 데이터는 그대로 유지하면서 클러스터에서 모든 DB 인스턴스를 제거할 수도 있습니다. 클러스터에 0의 DB 인스턴스가 있는 동안에는 현재 위치 업그레이드를 수행할 수 없습니다.

업그레이드 메커니즘을 사용하려면 클러스터의 라이터 인스턴스가 시스템 테이블, 데이터 파일 등에 대한 변환을 수행해야 합니다. 이 경우 AWS CLI 또는 RDS API를 사용하여 클러스터의 라이터 인스턴스를 만듭니다. 그런 다음 현재 위치 업그레이드를 수행할 수 있습니다.

백트랙이 활성화된 클러스터

예

백트랙 기능을 사용하는 Aurora MySQL 클러스터에 현재 위치 업그레이드를 수행할 수 있습니다. 그러나 업그레이드 후에는 업그레이드 전에 클러스터를 백트랙할 수 없습니다.

Aurora MySQL 현재 위치 주 버전 업그레이드 작동 방식

Aurora MySQL 는 주 버전 업그레이드를 다단계 프로세스로 수행합니다. 업그레이드의 현재 상태를 확인할 수 있습니다. 일부 업그레이드 단계는 진행 정보도 제공합니다. 각 단계가 시작되면 Aurora MySQL 에서는 이벤트를 기록합니다. RDS 콘솔의 이벤트 페이지에서 발생하는 이벤트를 검사할 수 있습니다. 이벤트 작업에 대한 자세한 내용은 Amazon RDS 이벤트 알림 작업 단원을 참조하십시오.

중요

프로세스가 시작되면 업그레이드가 성공하거나 실패할 때까지 프로세스가 실행됩니다. 진행 중에는 업그레이드를 취소할 수 없습니다. 업그레이드가 실패하면 Aurora 은 모든 변경 사항을 롤백하며 클러스터는 이전과 동일한 엔진 버전, 메타데이터 등을 갖춥니다.

업그레이드 프로세스는 세 단계로 구성됩니다:

  1. Aurora는 업그레이드 프로세스를 시작하기 전에 일련의 사전 확인을 수행합니다. Aurora 가 이러한 검사를 수행하는 동안 클러스터가 계속 실행됩니다. 예를 들어 클러스터는 준비된 상태의 XA 트랜잭션을 가질 수 없거나 DDL (데이터 정의 언어) 문을 처리할 수 없습니다. 예를 들어 특정 종류의 SQL문을 제출하는 응용 프로그램을 종료해야 할 수 있습니다. 또는 특정 장기 실행 명령문이 완료될 때까지 기다릴 수도 있습니다. 그런 다음 업그레이드를 다시 시도하십시오. 일부 검사는 업그레이드를 방해하지는 않지만 업그레이드 시간이 오래 걸리게 할 수 있는 조건을 테스트합니다.

    Aurora 은 필수 조건이 충족되지 않음을 감지하면 이벤트 세부 정보에서 식별된 조건을 수정합니다. Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결의 지침을 따릅니다. Aurora 가 느리게 업그레이드될 수 있는 조건을 감지하면 장기간 업그레이드를 모니터링하도록 계획합니다.

  2. Aurora 는 클러스터를 오프라인으로 전환합니다. 그 다음 Aurora 가 이전 단계에서의 테스트와 유사한 테스트 세트를 수행하여 종료 프로세스 중 새로운 문제가 발생하지 않았는지 확인합니다. Aurora 가 이 시점에서 업그레이드를 방해하는 조건을 감지하면 Aurora는 업그레이드를 취소하고 클러스터를 다시 온라인 상태로 만듭니다. 이 경우 조건이 더 이상 적용되지 않는 시점을 확인하고 업그레이드를 다시 시작하십시오.

  3. Aurora 는 클러스터 볼륨의 스냅샷을 생성합니다. 업그레이드가 완료된 후 호환성 또는 다른 종류의 문제를 발견했다고 가정합니다. 또는 기존 클러스터와 업그레이드된 클러스터를 모두 사용하여 테스트를 수행한다고 가정합니다. 이 경우 이 스냅샷에서 복원하여 기존 엔진 버전 및 원본 데이터로 새 클러스터를 만들 수 있습니다.

    작은 정보

    이 스냅샷은 수동 스냅샷입니다. 그러나 Aurora 는 수동 스냅샷에 대한 할당량에 도달한 경우에도 이를 생성하고 업그레이드 프로세스를 계속할 수 있습니다. 이 스냅샷은 삭제할 때까지 영구적으로(필요한 경우) 유지됩니다. 모든 업그레이드 후 테스트를 완료한 후 이 스냅샷을 삭제하여 스토리지 요금을 최소화할 수 있습니다.

  4. Aurora 는 클러스터 볼륨을 복제합니다. 복제는 실제 테이블 데이터를 포함하지 않는 빠른 작업입니다. Aurora 는 업그레이드 중에 문제가 발생하면 복제된 클러스터 볼륨에서 원래 데이터로 복구되며 클러스터가 다시 온라인 상태로 전환됩니다. 업그레이드 중 임시 복제된 볼륨은 단일 클러스터 볼륨에 관한 클론 수에 부여되는 일반적인 제한이 적용되지 않습니다.

  5. Aurora 는 작성자 DB 인스턴스에 대하여 새로 종료를 수행합니다. 클린 종료 중 다음 작업에 대해 15분마다 진행률 이벤트를 기록합니다. RDS 콘솔의 이벤트 페이지에서 발생하는 이벤트를 검사할 수 있습니다.

    • Aurora 는 이전 버전의 행에 대한 실행 취소 레코드를 소거합니다.

    • Aurora 커밋되지 않은 트랜잭션을 롤백합니다.

  6. Aurora 는 라이터 DB 인스턴스에서 엔진 버전을 업그레이드합니다.

    • Aurora 는 라이터 DB 인스턴스에 새 엔진 버전용 바이너리를 설치합니다.

    • Aurora 는 라이터 DB 인스턴스를 사용하여 데이터를 MySQL 5.7 호환 형식으로 업그레이드합니다. 이 단계에서 Aurora는 시스템 테이블을 수정하고 클러스터 볼륨의 데이터에 영향을 주는 다른 변환을 수행합니다. 특히, Aurora는 MySQL 5.7 파티션 형식과 호환되도록 시스템 테이블의 파티션 메타 데이터를 업그레이드합니다. 클러스터의 테이블에 파티션 수가 많은 경우 이 단계에 시간이 오래 걸릴 수 있습니다.

      이 단계에서 오류가 발생하면 MySQL 오류 로그에서 세부 정보를 찾을 수 있습니다. 이 단계가 시작된 후 어떤 이유로든 업그레이드 프로세스가 실패하면 Aurora 는 복제된 클러스터 볼륨에서 원래 데이터를 복원합니다.

  7. Aurora 는 Reader DB 인스턴스에서 엔진 버전을 업그레이드합니다.

  8. 업그레이드 프로세스가 완료되었습니다. Aurora는 업그레이드 프로세스가 성공적으로 완료되었음을 나타내는 최종 이벤트를 기록합니다. 이제 DB 클러스터가 새로운 주 버전을 실행하고 있습니다.

대체 블루-그린 업그레이드 기술

경우에 따라서는 오래된 클러스터에서 업그레이드된 클러스터로 즉시 전환하는 것이 가장 중요한 우선순위일 수 있습니다. 또는 이전 클러스터와 새 클러스터를 나란히 실행하는 다단계 프로세스를 따를 수도 있습니다. 이 경우 새 클러스터가 인수할 준비가 될 때까지 이전 클러스터의 데이터를 새 클러스터로 복제합니다. 자세한 내용은 데이터베이스 업데이트에 Amazon RDS 블루/그린 배포 사용을 참조하세요.

현재 위치 업그레이드 수행 방법

Aurora MySQL 현재 위치 주 버전 업그레이드 작동 방식의 배경 자료를 검토하는 것이 좋습니다.

아래 설명된 대로 사전 업그레이드 계획 및 테스트를 수행합니다.

다음 예제에서는 mydbcluster-cluster DB 클러스터를 Aurora MySQL 버전 3.04.1로 업그레이드합니다.

Aurora MySQL DB 클러스터의 주 버전을 업그레이드하는 방법

  1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.

  2. 원래 DB 클러스터에 사용자 지정 파라미터 그룹을 사용한 경우 새 메이저 버전과 호환되는 해당 파라미터 그룹을 생성합니다. 새 파라미터 그룹의 구성 파라미터를 필요에 따라 조정합니다. 자세한 내용은 현재 위치 업그레이드가 클러스터의 파라미터 그룹에 미치는 영향 섹션을 참조하세요.

  3. 탐색 창에서 데이터베이스를 선택합니다.

  4. 목록에서 수정할 DB 클러스터를 선택합니다.

  5. 수정을 선택합니다.

  6. 버전에 새 Aurora MySQL 메이저 버전을 선택합니다.

    일반적으로 메이저 버전의 최신 마이너 버전을 사용하는 것이 좋습니다. 여기에서는 현재의 기본 버전을 선택합니다.

    Aurora MySQL DB 클러스터 버전 2에서 버전 3으로의 현재 위치 업그레이드

  7. [Continue]를 선택합니다.

  8. 다음 페이지에서 업그레이드 수행 시기를 지정합니다. 다음 예약된 유지 관리 기간 중 또는 즉시를 선택합니다.

  9. (선택 사항) 업그레이드하는 동안 RDS 콘솔에서 이벤트 페이지를 주기적으로 검사합니다. 이렇게 하면 업그레이드 진행 상황을 모니터링하고 모든 문제를 식별할 수 있습니다. 업그레이드에 문제가 발생하면 수행할 단계에 대한 Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결를 참조하십시오.

  10. 이 절차를 시작할 때 새 파라미터 그룹을 생성한 경우 사용자 지정 파라미터 그룹을 업그레이드된 클러스터와 연결합니다. 자세한 내용은 현재 위치 업그레이드가 클러스터의 파라미터 그룹에 미치는 영향 섹션을 참조하세요.

    참고

    이 단계를 수행하려면 클러스터를 다시 시작하여 새 파라미터 그룹을 적용해야 합니다.

  11. (선택 사항) 업그레이드 후 테스트를 완료한 후 Aurora이 업그레이드 시작 시 생성한 수동 스냅샷을 삭제합니다.

Aurora MySQL DB 클러스터의 메이저 버전을 업그레이드하려면 다음 필수 파라미터와 함께 AWS CLI modify-db-cluster 명령을 사용합니다.

  • --db-cluster-identifier

  • --engine-version

  • --allow-major-version-upgrade

  • --apply-immediately 또는 --no-apply-immediately

클러스터에서 사용자 지정 파라미터 그룹을 사용하는 경우 다음 옵션 중 하나 또는 모두를 포함합니다.

  • --db-cluster-parameter-group-name클러스터가 사용자 지정 클러스터 파라미터 그룹을 사용하는 경우

  • --db-instance-parameter-group-name클러스터의 인스턴스가 사용자 지정 DB 파라미터 그룹을 사용하는 경우

다음 예제에서는 sample-cluster DB 클러스터를 Aurora MySQL 버전 3.04.1로 업그레이드합니다. 업그레이드는 다음 유지 관리 기간을 기다리는 대신 즉시 수행됩니다.

예

Linux, macOS, Unix:

aws rds modify-db-cluster \
          --db-cluster-identifier sample-cluster \
          --engine-version 8.0.mysql_aurora.3.04.1 \
          --allow-major-version-upgrade \
          --apply-immediately

Windows의 경우:

aws rds modify-db-cluster ^
          --db-cluster-identifier sample-cluster ^
          --engine-version 8.0.mysql_aurora.3.04.1 ^
          --allow-major-version-upgrade ^
          --apply-immediately

다른 CLI 명령을 modify-db-cluster와 결합하여 업그레이드 수행 및 확인을 위한 자동화된 종단 간 프로세스를 생성할 수 있습니다. 자세한 정보와 지침은 Aurora MySQL 현재 위치 업그레이드 자습서 단원을 참조하십시오.

참고

클러스터가 Aurora 글로벌 데이터베이스의 일부라면 현재 위치 업그레이드 절차가 약간 다릅니다. modify-global-cluster 명령 작업을 modify-db-cluster 대신 호출합니다. 자세한 내용은 글로벌 데이터베이스에 대한 현재 위치 메이저 업그레이드 섹션을 참조하세요.

Aurora MySQL DB 클러스터의 메이저 버전을 업그레이드하려면 다음 필수 파라미터와 함께 RDS API 작업 ModifyDBCluster를 사용합니다.

  • DBClusterIdentifier

  • Engine

  • EngineVersion

  • AllowMajorVersionUpgrade

  • ApplyImmediately (true 또는 false로 설정)

참고

클러스터가 Aurora 글로벌 데이터베이스의 일부라면 현재 위치 업그레이드 절차가 약간 다릅니다. ModifyGlobalCluster 작업을 ModifyDBCluster 대신 호출합니다. 자세한 내용은 글로벌 데이터베이스에 대한 현재 위치 메이저 업그레이드 섹션을 참조하세요.

현재 위치 업그레이드가 클러스터의 파라미터 그룹에 미치는 영향

Aurora 파라미터 그룹에는 MySQL 5.7 또는 8.0과 호환되는 클러스터에 대해 서로 다른 구성 설정 집합이 있습니다. 현재 위치 업그레이드를 수행할 때 업그레이드된 클러스터와 클러스터의 모든 인스턴스는 해당하는 클러스터 및 인스턴스 파라미터 그룹을 사용해야 합니다.

클러스터와 인스턴스는 기본 5.7 호환 파라미터 그룹을 사용할 수 있습니다. 그렇다면 업그레이드된 클러스터 및 인스턴스는 기본 8.0 호환 파라미터 그룹으로 시작합니다. 클러스터와 인스턴스가 사용자 지정 파라미터 그룹을 사용하는 경우 해당하는 8.0 호환 파라미터 그룹을 생성해야 합니다. 또한 업그레이드 프로세스 중에 이를 지정해야 합니다.

중요

업그레이드 프로세스 중에 사용자 지정 파라미터 그룹을 지정하는 경우 업그레이드가 완료된 후 클러스터를 수동으로 재부팅해야 합니다. 이렇게 하면 클러스터가 사용자 지정 파라미터 설정을 사용하기 시작합니다.

Aurora MySQL 버전 간의 클러스터 속성 변경

Aurora MySQL 버전 2에서 버전 3으로 업그레이드할 때는 Aurora MySQL 클러스터 및 DB 인스턴스를 설정하거나 관리하는 데 사용하는 애플리케이션 또는 스크립트를 변경해야 합니다.

또한 5.7 및 8.0 호환 클러스터에서 기본 파라미터 그룹 이름이 다르다는 사실을 설명하기 위해 파라미터 그룹을 조작하는 코드를 변경하세요. Aurora MySQL 버전 2 및 3 클러스터에 해당하는 기본 파라미터 그룹 이름은 각각 default.aurora-mysql5.7 및 default.aurora-mysql8.0입니다.

예를 들어 업그레이드 전에 클러스터에 적용되는 다음과 같은 코드가 있을 수 있습니다.

# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1

클러스터의 주 버전을 업그레이드한 후 다음과 같이 해당 코드를 수정합니다.

# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1

글로벌 데이터베이스에 대한 현재 위치 메이저 업그레이드

Aurora 글로벌 데이터베이스의 경우 글로벌 데이터베이스 클러스터를 업그레이드합니다. Aurora는 자동으로 모든 클러스터를 동시에 업그레이드하고 모든 클러스터가 동일한 엔진 버전을 실행하도록 합니다. 이 요구 사항은 시스템 테이블, 데이터 파일 형식 등에 대한 변경 내용이 모든 보조 클러스터에 자동으로 복제되기 때문입니다.

Aurora MySQL 현재 위치 주 버전 업그레이드 작동 방식의 지침을 따르세요. 업그레이드할 대상을 지정할 때 포함된 클러스터 중에서 대신 글로벌 데이터베이스 클러스터를 선택해야 합니다.

AWS Management Console을 사용하는 경우 글로벌 데이터베이스(Global database) 역할이 있는 항목을 선택합니다.

글로벌 데이터베이스 클러스터 업그레이드

AWS CLI 또는 RDS API를 사용하는 경우에는 modify-global-cluster 명령 또는 ModifyGlobalCluster 작업을 호출하여 업그레이드 프로세스를 시작합니다. modify-db-cluster 또는 ModifyDBCluster 대신 이중 하나를 사용합니다.

참고

해당 Aurora Global Database의 메이저 버전 업그레이드를 수행하는 동안에는 글로벌 데이터베이스 클러스터에 대한 사용자 지정 파라미터 그룹을 지정할 수 없습니다. 전역 클러스터의 각 리전에 사용자 지정 파라미터 그룹을 생성합니다. 그런 다음 업그레이드 후 리전 클러스터에 수동으로 적용합니다.

AWS CLI를 사용하여 Aurora MySQL 글로벌 데이터베이스 클러스터의 메이저 버전을 업그레이드하려면 다음 필수 파라미터와 함께 modify-db-cluster 명령을 사용합니다.

  • --global-cluster-identifier

  • --engine aurora-mysql

  • --engine-version

  • --allow-major-version-upgrade

다음 예에서는 글로벌 데이터베이스 클러스터를 Aurora MySQL 버전 2.10.2로 업그레이드합니다.

예

Linux, macOS, Unix:

aws rds modify-global-cluster \
          --global-cluster-identifier global_cluster_identifier \
          --engine aurora-mysql \
          --engine-version 5.7.mysql_aurora.2.10.2 \
          --allow-major-version-upgrade

Windows의 경우:

aws rds modify-global-cluster ^
          --global-cluster-identifier global_cluster_identifier ^
          --engine aurora-mysql ^
          --engine-version 5.7.mysql_aurora.2.10.2 ^
          --allow-major-version-upgrade

역추적 고려 사항

업그레이드한 클러스터에서 역추적 기능을 사용하도록 설정한 경우 업그레이드된 클러스터를 업그레이드 전의 시간으로 되돌릴 수 없습니다.

Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결

다음 팁을 사용하면 Aurora MySQL 인플레이스 업그레이드와 관련된 문제를 해결하는 데 도움이 됩니다. 이러한 팁은 Aurora Serverless DB 클러스터에는 적용되지 않습니다.

현재 위치 업그레이드가 취소되거나 느린 이유 Effect 유지 관리 기간 내에 현재 위치 업그레이드를 완료할 수 있는 솔루션
클러스터에 준비된 상태의 XA 트랜잭션이 있습니다. Aurora는 업그레이드를 취소합니다. 준비된 모든 XA 트랜잭션을 커밋하거나 롤백합니다.
클러스터가 데이터 정의 언어(DDL)문을 처리하고 있습니다. Aurora는 업그레이드를 취소합니다. 모든 DDL문이 완료된 후 대기하고 업그레이드를 수행하기를 고려하십시오.
클러스터에 많은 행에 대해 커밋되지 않은 변경 사항이 있습니다. 업그레이드에 시간이 오래 걸릴 수 있습니다.

업그레이드 프로세스는 커밋되지 않은 변경 사항을 롤백합니다. 이 조건에 대한 표시기는 TRX_ROWS_MODIFIED 테이블 내 INFORMATION_SCHEMA.INNODB_TRX의 값입니다.

모든 대규모 트랜잭션이 커밋되거나 롤백된 후에만 업그레이드를 수행하는 것이 좋습니다.
클러스터에 실행 취소 레코드 수가 많음 업그레이드에 시간이 오래 걸릴 수 있습니다.

커밋되지 않은 트랜잭션이 대량의 행에 영향을 미치지 않더라도 대량의 데이터가 포함될 수 있습니다. 예를 들어 대형 BLOB를 삽입할 수 있습니다. Aurora는 이러한 종류의 트랜잭션 활동에 대한 이벤트를 자동으로 감지하거나 생성하지 않습니다. 이 조건에 대한 지표는 HLL(기록 목록 길이)입니다. 업그레이드 프로세스는 커밋되지 않은 변경 사항을 롤백합니다.

SHOW ENGINE INNODB STATUS SQL 명령의 출력에서 HLL을 확인하거나 다음 SQL 쿼리를 사용하여 직접 확인할 수 있습니다.

SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

또한 Amazon CloudWatch를 사용하여 RollbackSegmentHistoryListLength 지표를 모니터링할 수도 있습니다.

HLL의 길이가 더 줄어든 후에 한하여 업그레이드 수행을 고려하세요.
클러스터가 큰 이진 로그 트랜잭션을 커밋하는 중입니다. 업그레이드에 시간이 오래 걸릴 수 있습니다.

업그레이드 프로세스는 이진 로그 변경 내용이 적용될 때까지 기다립니다. 이 기간 동안 더 많은 트랜잭션 또는 DDL문이 시작될 수 있으므로 업그레이드 프로세스가 느려질 수 있습니다.

클러스터가 이진 로그 복제 변경 내용을 생성하느라 바쁜 경우가 아니면 업그레이드 프로세스를 예약합니다. Aurora는 이 조건에 대한 이벤트를 자동으로 감지하거나 생성하지 않습니다.
파일 제거 또는 손상으로 인한 스키마 불일치 Aurora는 업그레이드를 취소합니다.

임시 테이블의 기본 스토리지 엔진을 MyISAM에서 InnoDB로 변경합니다. 다음 단계를 수행합니다.

  1. default_tmp_storage_engine DB 파라미터를 InnoDB로 수정합니다.

  2. DB 클러스터를 재부팅합니다.

  3. 재부팅한 후 default_tmp_storage_engine DB 파라미터가 InnoDB로 설정되어 있는지 확인합니다. 다음 명령을 사용합니다.

    show global variables like 'default_tmp_storage_engine';

  4. MyISAM 스토리지 엔진을 사용하는 임시 테이블을 만들지 마시기 바랍니다. 곧 업그레이드할 예정이므로 데이터베이스 워크로드를 일시 중지하고 새 데이터베이스 연결을 만들지 않는 것이 좋습니다.

  5. 현재 위치 업그레이드를 다시 시도합니다.
마스터 사용자 삭제됨 Aurora는 업그레이드를 취소합니다.
중요

마스터 사용자는 삭제하지 마세요.

하지만 어떤 이유로든 마스터 사용자를 삭제해야 하는 경우 다음 SQL 명령을 사용하여 복원하세요.

CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, 
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, 
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;

다음 단계를 사용하여 위 테이블의 일부 조건에 대해 직접 검사를 수행할 수 있습니다. 이렇게 하면 데이터베이스가 업그레이드가 성공적으로 신속하게 완료될 수 있는 상태임을 알고 있을 때 업그레이드를 예약할 수 있습니다.

  • XA RECOVER문을 실행하여 열린 XA 트랜잭션을 확인할 수 있습니다. 그런 다음 업그레이드를 시작하기 전에 XA 트랜잭션을 커밋하거나 롤백할 수 있습니다.

  • SHOW PROCESSLIST문을 실행하고 출력에서 CREATE, DROP, ALTER, RENAME 및 TRUNCATE 문을 찾아 DDL 문을 확인할 수 있습니다. 업그레이드를 시작하기 전에 모든 DDL 문이 완료될 수 있습니다.

  • INFORMATION_SCHEMA.INNODB_TRX 테이블을 쿼리하여 수행되지 않은 행의 총 수를 확인할 수 있습니다. 테이블은 각 트랜잭션에 대한 하나의 행을 포함합니다. TRX_ROWS_MODIFIED 열은 트랜잭션에 의해 수정되거나 삽입된 행 수를 포함합니다.

  • SHOW ENGINE INNODB STATUS SQL문을 실행하고 출력에서 History list length를 찾아 InnoDB 히스토리 목록의 길이를 확인할 수 있습니다. 다음 쿼리를 실행하여 값을 직접 확인할 수도 있습니다.

    SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

    기록 목록의 길이는 다중 버전 동시성 제어 (MVCC)를 구현하기 위해 데이터베이스에 저장된 실행 취소 정보의 양에 해당합니다.

Aurora MySQL 현재 위치 업그레이드 자습서

다음 Linux 예제에서는 AWS CLI를 사용하여 전체 업그레이드 절차의 일반적인 단계를 수행하는 방법을 보여 줍니다.

이 첫 번째 예시에서는 2.x 버전의 Aurora MySQL를 실행하는 Aurora DB 클러스터를 생성합니다. 클러스터에는 라이터 DB 인스턴스와 리더 DB 인스턴스가 포함됩니다. wait db-instance-available 명령은 라이터 DB 인스턴스를 사용할 수 있을 때까지 일시 중지됩니다. 이것이 바로 클러스터를 업그레이드할 준비가 된 시점입니다.

aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
  --db-cluster-version 5.7.mysql_aurora.2.10.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
  --db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1

클러스터를 업그레이드할 수 있는 Aurora MySQL 3.x 버전은 클러스터가 현재 실행 중인 2.x 버전과 클러스터가 위치한 AWS 리전에 따라 다릅니다. --output text를 갖춘 첫 번째 명령은 사용 가능한 대상 버전만 표시합니다. 두 번째 명령은 응답의 전체 JSON 출력을 보여줍니다. 이 응답에서 engine 파라미터에 사용하는 aurora-mysql 값과 같은 세부 정보를 볼 수 있습니다. 또한 3.02.0으로의 업그레이드가 메이저 버전 업그레이드를 나타낸다는 사실을 알 수 있습니다.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.10.2

aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
  --query '*[].[ValidUpgradeTarget]'
...
{
    "Engine": "aurora-mysql",
    "EngineVersion": "8.0.mysql_aurora.3.02.0",
    "Description": "Aurora MySQL 3.02.0 (compatible with MySQL 8.0.23)",
    "AutoUpgrade": false,
    "IsMajorVersionUpgrade": true,
    "SupportedEngineModes": [
        "provisioned"
    ],
    "SupportsParallelQuery": true,
    "SupportsGlobalDatabases": true,
    "SupportsBabelfish": false
},
...

이 예에서는 클러스터에 유효한 업그레이드 대상이 아닌 대상 버전 번호를 입력하면 Aurora에서 업그레이드를 수행하지 않는 상황을 보여줍니다. Aurora는 또한 --allow-major-version-upgrade 파라미터를 포함하지 않으면 메이저 버전 업그레이드를 수행하지 않습니다. 이러면 애플리케이션 코드를 광범위하게 테스트하여 변경해야 할 가능성이 있는 업그레이드를 우연히 수행하게 될 수 없습니다.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.10.2 with requested version 5.7.mysql_aurora.2.09.2.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --apply-immediately --allow-major-version-upgrade
{
  "DBClusterIdentifier": "mynewdbcluster",
  "Status": "available",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.2"
}

클러스터 및 관련 DB 인스턴스의 상태가 upgrading로 변경되려면 몇 분 정도 걸립니다. 클러스터와 DB 인스턴스의 버전 번호는 업그레이드가 완료된 경우에만 변경됩니다. 다시 말해 라이터 DB 인스턴스에 대한 wait db-instance-available 명령을 사용하여 업그레이드가 완료될 때까지 기다렸다가 계속 진행할 수 있습니다.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.10.2

aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
  --query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
    "DBInstanceIdentifier": "mynewdbcluster-instance1",
    "DBInstanceStatus": "upgrading"
}

aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1

이 시점에서 클러스터의 버전 번호는 업그레이드에 지정된 번호와 일치합니다.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].[EngineVersion]' --output text

8.0.mysql_aurora.3.02.0

앞의 예제에서는 --apply-immediately 파라미터를 지정하여 즉시 업그레이드를 수행했습니다. 클러스터가 사용 중일 것으로 예상되지 않는 편리한 시간에 업그레이드를 수행하도록 --no-apply-immediately 파라미터를 지정할 수 있습니다. 이러면 클러스터의 다음 유지 관리 기간 동안 업그레이드가 시작됩니다. 유지 관리 기간은 유지 관리 작업을 시작할 수 있는 기간을 정의합니다. 유지 관리 기간 동안 장기 실행 작업이 완료되지 않을 수 있습니다. 따라서 업그레이드에 시간이 오래 걸릴 것으로 예상되더라도 더 긴 유지 관리 시간을 정의할 필요는 없습니다.

다음 예시에서는 처음에 Aurora MySQL 버전 2.10.2를 실행하는 클러스터를 업그레이드합니다. describe-db-engine-versions 출력에서 False 및 True 값은 IsMajorVersionUpgrade 속성을 나타냅니다. 버전 2.10.2부터는 다른 2.* 버전으로 업그레이드할 수 있습니다. 이러한 업그레이드는 메이저 버전 업그레이드로 간주되지 않으므로 현재 위치 업그레이드가 필요하지 않습니다. 현재 위치 업그레이드는 목록에 표시된 3.* 버전으로 업그레이드할 때만 사용할 수 있습니다.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.10.2

aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
  --query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text

5.7.mysql_aurora.2.10.3 False
5.7.mysql_aurora.2.11.0 False
5.7.mysql_aurora.2.11.1 False
8.0.mysql_aurora.3.01.1 True
8.0.mysql_aurora.3.02.0 True
8.0.mysql_aurora.3.02.2 True


aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --no-apply-immediately --allow-major-version-upgrade
...

지정된 유지 관리 기간 없이 클러스터가 생성되면 Aurora에서 주중 임의의 요일을 선택합니다. 이 경우 modify-db-cluster 명령은 월요일에 제출됩니다. 따라서 유지 보수 기간을 화요일 아침으로 변경합니다. 모든 시간은 UTC 표준 시간대로 표시됩니다. tue:10:00-tue:10:30 기간은 태평양 표준시 오전 2시~2시 30분에 해당합니다. 유지 관리 기간의 변경 내용은 즉시 적용됩니다.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "sat:08:20-sat:08:50"
    ]
]

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "tue:10:00-tue:10:30"
    ]
]

다음 예시에서는 업그레이드로 생성된 이벤트에 대한 보고서를 가져오는 방법을 보여줍니다. --duration 인수는 이벤트 정보 검색 시간(분)을 나타냅니다. 이 인수는 기본적으로 마지막 시간의 describe-events 이벤트만 반환하기 때문에 필요합니다.

aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
    "Events": [
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "DB cluster created",
            "EventCategories": [
                "creation"
            ],
            "Date": "2022-11-17T01:24:11.093000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing online pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T22:57:08.450000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T22:57:59.519000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:00:22.318000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Cloning volume.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:01:45.428000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:02:25.141000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:06:23.036000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Upgrading database objects.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:06:48.208000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster major version has been upgraded",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:10:28.999000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        }
    ]
}