Aurora MySQL 버전 2에서 버전 3으로 업그레이드 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에서 버전 3으로 업그레이드

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

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

현재 위치 업그레이드 방법은 수행 방법이 단순하며 관련 애플리케이션에 대한 구성 변경을 최소화하므로 편리합니다. 예를 들어, 현재 위치 업그레이드는 클러스터의 엔드포인트 및 DB 인스턴스 세트를 보관합니다. 그러나 현재 위치 업그레이드에 필요한 시간은 스키마의 속성과 클러스터 사용 수준에 따라 달라질 수 있습니다. 따라서 클러스터의 요구 사항에 따라 다음의 업그레이드 방법 중에서 선택할 수 있습니다.

현재 위치 업그레이드
블루/그린 배포
스냅샷 복원

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

Aurora MySQL 버전 3 및 새로운 기능에 대한 일반적인 정보는 Aurora MySQL 버전 3은 MySQL 8.0과 호환 섹션을 참조하세요.

업그레이드 계획에 대한 자세한 내용은 Aurora MySQL 클러스터에 대한 주 버전 업그레이드 계획 및 현재 위치 업그레이드 수행 방법을 참조하세요.

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

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

Aurora MySQL DB 클러스터 유형	현재 위치 업그레이드를 사용할 수 있습니까?	작업
Aurora MySQL 프로비저닝된 클러스터(버전 2)	예	현재 위치 업그레이드는 MySQL 5.7 호환 Aurora MySQL 클러스터에 지원됩니다. Aurora MySQL 버전 3으로의 업그레이드에 대한 자세한 내용은 Aurora MySQL 클러스터에 대한 주 버전 업그레이드 계획 및 현재 위치 업그레이드 수행 방법 섹션을 참조하세요.
Aurora MySQL 프로비저닝된 클러스터(버전 3)	해당 사항 없음	마이너 버전 업그레이드 절차를 사용하여 Aurora MySQL 버전 3 간에 업그레이드하세요.
Aurora Serverless v1 클러스터	해당 사항 없음	Aurora Serverless v1은 Aurora MySQL의 버전 2에서만 지원됩니다.
Aurora Serverless v2 클러스터	해당 사항 없음	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 클러스터에서 바이너리 로그 복제를 했다면 현재 위치 업그레이드를 수행할 수 있습니다. 바이너리 로그 복제가 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 은 모든 변경 사항을 롤백하며 클러스터는 이전과 동일한 엔진 버전, 메타데이터 등을 갖춥니다.

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

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

Aurora 은 필수 조건이 충족되지 않음을 감지하면 이벤트 세부 정보에서 식별된 조건을 수정합니다. Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결의 지침을 따릅니다. Aurora 가 느리게 업그레이드될 수 있는 조건을 감지하면 장기간 업그레이드를 모니터링하도록 계획합니다.
Aurora 는 클러스터를 오프라인으로 전환합니다. 그 다음 Aurora 가 이전 단계에서의 테스트와 유사한 테스트 세트를 수행하여 종료 프로세스 중 새로운 문제가 발생하지 않았는지 확인합니다. Aurora 가 이 시점에서 업그레이드를 방해하는 조건을 감지하면 Aurora는 업그레이드를 취소하고 클러스터를 다시 온라인 상태로 만듭니다. 이 경우 조건이 더 이상 적용되지 않는 시점을 확인하고 업그레이드를 다시 시작하십시오.
Aurora 는 클러스터 볼륨의 스냅샷을 생성합니다. 업그레이드가 완료된 후 호환성 또는 다른 종류의 문제를 발견했다고 가정합니다. 또는 기존 클러스터와 업그레이드된 클러스터를 모두 사용하여 테스트를 수행한다고 가정합니다. 이 경우 이 스냅샷에서 복원하여 기존 엔진 버전 및 원본 데이터로 새 클러스터를 만들 수 있습니다.

작은 정보
이 스냅샷은 수동 스냅샷입니다. 그러나 Aurora 는 수동 스냅샷에 대한 할당량에 도달한 경우에도 이를 생성하고 업그레이드 프로세스를 계속할 수 있습니다. 이 스냅샷은 삭제할 때까지 영구적으로(필요한 경우) 유지됩니다. 모든 업그레이드 후 테스트를 완료한 후 이 스냅샷을 삭제하여 스토리지 요금을 최소화할 수 있습니다.
Aurora 는 클러스터 볼륨을 복제합니다. 복제는 실제 테이블 데이터를 포함하지 않는 빠른 작업입니다. Aurora 는 업그레이드 중에 문제가 발생하면 복제된 클러스터 볼륨에서 원래 데이터로 복구되며 클러스터가 다시 온라인 상태로 전환됩니다. 업그레이드 중 임시 복제된 볼륨은 단일 클러스터 볼륨에 관한 클론 수에 부여되는 일반적인 제한이 적용되지 않습니다.
Aurora 는 작성자 DB 인스턴스에 대하여 새로 종료를 수행합니다. 클린 종료 중 다음 작업에 대해 15분마다 진행률 이벤트를 기록합니다. RDS 콘솔의 이벤트 페이지에서 발생하는 이벤트를 검사할 수 있습니다.
- Aurora 는 이전 버전의 행에 대한 실행 취소 레코드를 소거합니다.
- Aurora 커밋되지 않은 트랜잭션을 롤백합니다.
Aurora 는 라이터 DB 인스턴스에서 엔진 버전을 업그레이드합니다.
- Aurora 는 라이터 DB 인스턴스에 새 엔진 버전용 바이너리를 설치합니다.
- Aurora 는 라이터 DB 인스턴스를 사용하여 데이터를 MySQL 5.7 호환 형식으로 업그레이드합니다. 이 단계에서 Aurora는 시스템 테이블을 수정하고 클러스터 볼륨의 데이터에 영향을 주는 다른 변환을 수행합니다. 특히, Aurora는 MySQL 5.7 파티션 형식과 호환되도록 시스템 테이블의 파티션 메타 데이터를 업그레이드합니다. 클러스터의 테이블에 파티션 수가 많은 경우 이 단계에 시간이 오래 걸릴 수 있습니다.
  
  이 단계에서 오류가 발생하면 MySQL 오류 로그에서 세부 정보를 찾을 수 있습니다. 이 단계가 시작된 후 어떤 이유로든 업그레이드 프로세스가 실패하면 Aurora 는 복제된 클러스터 볼륨에서 원래 데이터를 복원합니다.
Aurora 는 Reader DB 인스턴스에서 엔진 버전을 업그레이드합니다.
업그레이드 프로세스가 완료되었습니다. Aurora는 업그레이드 프로세스가 성공적으로 완료되었음을 나타내는 최종 이벤트를 기록합니다. 이제 DB 클러스터가 새로운 주 버전을 실행하고 있습니다.

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

업그레이드할 적절한 시기와 접근 방식을 결정하는 데 도움이 되도록 Aurora MySQL 버전 3과 현재 환경의 차이점을 알아볼 수 있습니다.

RDS for MySQL 8.0 또는 MySQL 8.0 커뮤니티 버전에서 변환하는 경우 Aurora MySQL 버전 3과 MySQL 8.0 커뮤니티 에디션 비교 섹션을 참조하세요.
Aurora MySQL 버전 2, RDS for MySQL 5.7 또는 커뮤니티 MySQL 5.7에서 업그레이드하는 경우 Aurora MySQL 버전 2와 Aurora MySQL 버전 3의 비교 섹션을 참조하세요.
모든 사용자 지정 파라미터 그룹의 MySQL 8.0 호환 버전을 새로 만듭니다. 필요한 모든 사용자 파라미터 값을 새 파라미터 그룹에 적용합니다. 파라미터 변경에 대해 알아보려면 Aurora MySQL 버전 3에 대한 파라미터 변경 사항 섹션을 참조하세요.
MySQL 8.0 Community Edition에 도입된 새로운 예약 키워드의 사용에 대해 Aurora MySQL 버전 2 데이터베이스 스키마 및 객체 정의를 검토하세요. 업그레이드하기 전에 완료하세요. 자세한 내용은 MySQL 설명서의 MySQL 8.0 새 키워드 및 예약어를 참조하세요.

또한 MySQL별 업그레이드 고려 사항과 팁에 대한 자세한 내용은 MySQL 참조 설명서의 MySQL 8.0의 변경 사항을 참조하세요. 예를 들어 mysqlcheck --check-upgrade 명령을 사용하여 기존 Aurora MySQL 데이터베이스를 분석하고 잠재적인 업그레이드 문제를 식별할 수 있습니다.

참고

현재 위치 업그레이드 또는 스냅샷 복원 기술을 사용하여 Aurora MySQL 버전 3으로 업그레이드할 때는 더 큰 DB 인스턴스 클래스를 사용하는 것이 좋습니다. 예로는 db.r5.24xlarge 및 db.r6g.16xlarge가 있습니다. 이렇게 하면 DB 인스턴스에서 사용 가능한 CPU 용량의 대부분을 사용하여 업그레이드 프로세스를 더 빠르게 완료할 수 있습니다. 메이저 버전 업그레이드가 완료된 후 원하는 DB 인스턴스 클래스로 변경할 수 있습니다.

업그레이드를 완료하면 Aurora MySQL 버전 3에 대한 업그레이드 후 정리에서 업그레이드 후 절차를 따를 수 있습니다. 마지막으로 애플리케이션의 기능과 성능을 테스트합니다.

RDS에서 MySQL 또는 커뮤니티 MySQL로 변환하는 경우 Amazon Aurora MySQL DB 클러스터로 데이터 마이그레이션에 설명된 마이그레이션 절차를 따르세요. 경우에 따라 마이그레이션의 일부로 이진 로그 복제를 사용하여 데이터를 Aurora MySQL 버전 3 클러스터와 동기화할 수 있습니다. 그렇다면 소스 시스템에서 대상 DB 클러스터와 호환되는 버전을 실행해야 합니다.

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

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

참고

현재 위치 업그레이드에는 작업이 진행되는 동안 DB 클러스터를 종료하는 작업이 포함됩니다. Aurora MySQL은 완전히 종료하고 제거 실행 취소와 같은 미결 작업을 완료합니다. 제거해야 할 실행 취소 레코드가 많으면 업그레이드 시간이 많이 소요될 수도 있습니다. 기록 목록 길이(HLL)가 줄어든 후에 한하여 업그레이드를 수행하는 것이 좋습니다. 일반적으로 허용되는 HLL 값은 100,000 이하입니다. 자세한 내용은 이 블로그 게시물을 참조하십시오.

DB 클러스터를 복제하여 업그레이드 시뮬레이션

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

다음 단계를 사용합니다.

기존 클러스터의 클론을 생성합니다. Aurora DB 클러스터에 대한 볼륨 복제의 절차를 따르십시오.
기존 클러스터에서처럼 유사한 라이터 및 리더 DB 인스턴스 세트를 설정합니다.
클론 클러스터의 현재 위치 업그레이드 수행 현재 위치 업그레이드 수행 방법의 절차를 따르십시오.

클론을 생성한 후 즉시 업그레이드를 시작합니다. 이러면 클러스터 볼륨이 기존 클러스터의 상태와 여전히 동일합니다. 업그레이드를 수행하기 전에 클론이 유휴 상태인 경우 Aurora 는 백그라운드에서 데이터베이스 정리 프로세스를 수행합니다. 이 경우 클론 업그레이드는 기존 클러스터 업그레이드의 정확한 시뮬레이션이 아닙니다.
복제된 클러스터를 사용하여 응용 프로그램 호환성, 성능, 관리 절차 등을 테스트합니다.
문제가 발생하면 업그레이드 계획을 조정하여 해당 문제를 해결하세요. 예를 들어 모든 애플리케이션 코드를 상위 버전의 기능 세트와 호환되도록 조정합니다. 클러스터의 데이터 양에 따라 업그레이드에 걸리는 시간을 예측합니다. 클러스터를 사용하지 않을 때 업그레이드를 예약하도록 선택할 수도 있습니다.
애플리케이션 및 워크로드가 테스트 클러스터에서 제대로 작동하면, 생산 클러스터에 현재 위치 업그레이드를 수행할 수 있습니다.
메이저 버전 업그레이드 중 클러스터의 총 가동 중지 시간을 최소화하기 위한 노력을 기울이세요. 그러기 위해서는 업그레이드 시 클러스터의 워크로드가 낮거나 0인지 확인해야 합니다. 특히 업그레이드를 시작할 때 진행 중인 장기 실행 트랜잭션이 없는지 확인하십시오.

블루/그린 배포

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

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

제로 가동 중지 패치 적용 기능 사용

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