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으로 업그레이드
- Aurora MySQL 클러스터에 대한 주 버전 업그레이드 계획
- Aurora MySQL에 대한 메이저 버전 업그레이드 사전 확인
- Aurora MySQL 주 버전 업그레이드 경로
- Aurora MySQL 현재 위치 주 버전 업그레이드 작동 방식
- 블루/그린 배포
- 현재 위치 업그레이드 수행 방법
- 현재 위치 업그레이드가 클러스터의 파라미터 그룹에 미치는 영향
- Aurora MySQL 버전 간의 클러스터 속성 변경
- 글로벌 데이터베이스에 대한 현재 위치 메이저 업그레이드
- 역추적 고려 사항
- Aurora MySQL 현재 위치 업그레이드 자습서
- 업그레이드 실패 원인 조사
- Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결
- Aurora MySQL 버전 3에 대한 업그레이드 후 정리
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 버전 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 블루/그린 배포 사용을 참조하세요.
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 트랜잭션이 없어야 합니다. -
뷰의 열 이름은 64자를 초과할 수 없습니다.
-
저장 프로시저의 특수 문자 불일치가 없어야 합니다.
-
테이블에 데이터 파일 경로 불일치가 없어야 합니다.
Aurora MySQL 주 버전 업그레이드 경로
모든 종류 또는 버전의 Aurora MySQL 클러스터가 현재 위치 업그레이드 메커니즘을 사용할 수 있는 것은 아닙니다. 다음 테이블을 참조하여 각 Aurora MySQL 클러스터에 대한 적절한 업그레이드 경로를 확인할 수 있습니다.
Aurora MySQL DB 클러스터 유형 | 현재 위치 업그레이드를 사용할 수 있습니까? | 작업 |
---|---|---|
Aurora MySQL 프로비저닝된 클러스터(2.0 이상) |
예 |
현재 위치 업그레이드는 5.7 호환 Aurora MySQL 클러스터에 지원됩니다. Aurora MySQL 버전 3으로의 업그레이드에 대한 자세한 내용은 Aurora MySQL 클러스터에 대한 주 버전 업그레이드 계획 및 현재 위치 업그레이드 수행 방법 섹션을 참조하세요. |
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를 사용한다면,
|
병렬 쿼리 클러스터 |
예 |
현재 위치 업그레이드를 수행할 수 있습니다. 이 경우 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 은 모든 변경 사항을 롤백하며 클러스터는 이전과 동일한 엔진 버전, 메타데이터 등을 갖춥니다.
업그레이드 프로세스는 세 단계로 구성됩니다:
-
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 클러스터가 새로운 주 버전을 실행하고 있습니다.
블루/그린 배포
경우에 따라서는 오래된 클러스터에서 업그레이드된 클러스터로 즉시 전환하는 것이 가장 중요한 우선순위일 수 있습니다. 또는 이전 클러스터와 새 클러스터를 나란히 실행하는 다단계 프로세스를 따를 수도 있습니다. 이 경우 새 클러스터가 인수할 준비가 될 때까지 이전 클러스터의 데이터를 새 클러스터로 복제합니다. 세부 정보는 데이터베이스 업데이트에 Amazon RDS 블루/그린 배포 사용을 참조하세요.
현재 위치 업그레이드 수행 방법
Aurora MySQL 현재 위치 주 버전 업그레이드 작동 방식의 배경 자료를 검토하는 것이 좋습니다.
Aurora MySQL 클러스터에 대한 주 버전 업그레이드 계획에 설명된 대로 사전 업그레이드 계획 및 테스트를 수행합니다.
다음 예제에서는 mydbcluster-cluster
DB 클러스터를 Aurora MySQL 버전 3.04.1로 업그레이드합니다.
Aurora MySQL DB 클러스터의 주 버전을 업그레이드하는 방법
-
https://console.aws.amazon.com/rds/
에서 AWS Management Console에 로그인한 후 Amazon RDS 콘솔을 엽니다. -
원래 DB 클러스터에 사용자 지정 파라미터 그룹을 사용한 경우 새 메이저 버전과 호환되는 해당 파라미터 그룹을 생성합니다. 새 파라미터 그룹의 구성 파라미터를 필요에 따라 조정합니다. 자세한 내용은 현재 위치 업그레이드가 클러스터의 파라미터 그룹에 미치는 영향 섹션을 참조하세요.
-
탐색 창에서 데이터베이스를 선택합니다.
-
목록에서 수정할 DB 클러스터를 선택합니다.
-
수정을 선택합니다.
-
버전에 새 Aurora MySQL 메이저 버전을 선택합니다.
일반적으로 메이저 버전의 최신 마이너 버전을 사용하는 것이 좋습니다. 여기에서는 현재의 기본 버전을 선택합니다.
-
[Continue]를 선택합니다.
-
다음 페이지에서 업그레이드 수행 시기를 지정합니다. 다음 예약된 유지 관리 기간 중 또는 즉시를 선택합니다.
-
(선택 사항) 업그레이드하는 동안 RDS 콘솔에서 이벤트 페이지를 주기적으로 검사합니다. 이렇게 하면 업그레이드 진행 상황을 모니터링하고 모든 문제를 식별할 수 있습니다. 업그레이드에 문제가 발생하면 수행할 단계에 대한 Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결를 참조하십시오.
-
이 절차를 시작할 때 새 파라미터 그룹을 생성한 경우 사용자 지정 파라미터 그룹을 업그레이드된 클러스터와 연결합니다. 자세한 내용은 현재 위치 업그레이드가 클러스터의 파라미터 그룹에 미치는 영향 단원을 참조하십시오.
참고
이 단계를 수행하려면 클러스터를 다시 시작하여 새 파라미터 그룹을 적용해야 합니다.
-
(선택 사항) 업그레이드 후 테스트를 완료한 후 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로 업그레이드합니다. 업그레이드는 다음 유지 관리 기간을 기다리는 대신 즉시 수행됩니다.
예
대상 LinuxmacOS, 또는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 호환 파라미터 그룹을 생성해야 합니다. 또한 업그레이드 프로세스 중에 이를 지정해야 합니다.
참고
대부분의 파라미터 설정에서는 두 지점에서 사용자 정의 파라미터 그룹을 선택할 수 있습니다. 클러스터를 만들 때와 나중에 파라미터 그룹을 클러스터와 연결할 때입니다.
그러나 lower_case_table_names
파라미터에 대해 기본값이 아닌 설정을 사용하는 경우 미리 이 설정으로 사용자 정의 파라미터 그룹을 설정해야 합니다. 그런 다음, 클러스터를 생성하기 위해 스냅샷 복원을 수행하는 경우 파라미터 그룹을 지정합니다. lower_case_table_names
파라미터에 대한 모든 변경은 클러스터를 생성한 후에는 효력이 없습니다.
Aurora MySQL 버전 2에서 버전 3으로 업그레이드할 때 lower_case_table_names
에 동일한 설정을 사용하는 것이 좋습니다.
Aurora MySQL 기반 Aurora Global Database 사용 시 lower_case_table_names
파라미터가 활성화 되어 있는 경우 Aurora MySQL 버전 2에서 버전 3으로 현재 위치 업그레이드를 수행할 수 없습니다. 사용할 수 있는 메서드에 대한 자세한 내용은 메이저 버전 업그레이드 섹션을 참조하세요.
중요
업그레이드 프로세스 중에 사용자 지정 파라미터 그룹을 지정하는 경우 업그레이드가 완료된 후 클러스터를 수동으로 재부팅해야 합니다. 이렇게 하면 클러스터가 사용자 지정 파라미터 설정을 사용하기 시작합니다.
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) 역할이 있는 항목을 선택합니다.
![글로벌 데이터베이스 클러스터 업그레이드](images/aurora-global-databases-major-upgrade-global-cluster.png)
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로 업그레이드합니다.
예
대상 LinuxmacOS, 또는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 현재 위치 업그레이드 자습서
다음 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-immediatelyAn 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 text5.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" } ] }
업그레이드 실패 원인 조사
이전 자습서에서는 Aurora MySQL 버전 2에서 버전 3으로 업그레이드하는 데 성공했습니다. 하지만 업그레이드가 실패했다면 그 이유를 알고 싶을 것입니다.
먼저 describe-events
AWS CLI 명령을 사용하여 DB 클러스터 이벤트를 살펴볼 수 있습니다. 이 예제는 지난 10시간 동안의 mydbcluster
에 대한 이벤트를 보여줍니다.
aws rds describe-events \ --source-type db-cluster \ --source-identifier mydbcluster \ --duration 600
이 경우 업그레이드 사전 점검에 실패한 것이 원인입니다.
{ "Events": [ { "SourceIdentifier": "mydbcluster", "SourceType": "db-cluster", "Message": "Database cluster engine version upgrade started.", "EventCategories": [ "maintenance" ], "Date": "2024-04-11T13:23:22.846000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster" }, { "SourceIdentifier": "mydbcluster", "SourceType": "db-cluster", "Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Troubleshooting.", "EventCategories": [ "maintenance" ], "Date": "2024-04-11T13:23:24.373000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster" } ] }
문제의 정확한 원인을 진단하려면 라이터 DB 인스턴스에 대한 데이터베이스 로그를 검사합니다. Aurora MySQL 버전 3으로 업그레이드할 때 실패하면 라이터 인스턴스에 upgrade-prechecks.log
라는 이름의 로그 파일이 포함됩니다. 이 예에서는 해당 로그의 존재를 감지한 다음 검사를 위해 로컬 파일로 다운로드하는 방법을 보여줍니다.
aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \ --query '*[].[LogFileName]' --output text error/mysql-error-running.log error/mysql-error-running.log.2024-04-11.20 error/mysql-error-running.log.2024-04-11.21 error/mysql-error.log external/mysql-external.log upgrade-prechecks.log aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \ --log-file-name upgrade-prechecks.log \ --starting-token 0 \ --output text >upgrade_prechecks.log
upgrade-prechecks.log
파일은 JSON 형식입니다. 다른 JSON 래퍼 내에서 JSON 출력을 인코딩하지 않도록 --output text
옵션을 사용하여 다운로드합니다. Aurora MySQL 버전 3 업그레이드의 경우 이 로그에는 항상 특정 정보 메시시지와 경고 메시지가 포함됩니다. 업그레이드가 실패하는 경우에만 오류 메시지가 포함됩니다. 업그레이드가 성공하면 로그 파일이 생성되지 않습니다.
이러한 모든 오류를 요약하고 관련 객체 및 설명 필드를 표시하려면 upgrade-prechecks.log
파일의 내용에 관한 grep -A 2 '"level": "Error"'
명령을 실행합니다. 그러기 위해 각 오류 줄과 그 뒤에 두 줄이 표시됩니다. 여기에는 해당 데이터베이스 객체의 이름과 문제 수정 방법에 대한 지침이 포함되어 있습니다.
$
cat upgrade-prechecks.log | grep -A 2 '"level": "Error"' "level": "Error", "dbObject": "problematic_upgrade.dangling_fulltext_index", "description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
이 예제에서는 문제가 되는 테이블에서 다음 SQL 명령을 실행하여 문제를 해결하거나, 누락된 인덱스 없이 테이블을 다시 생성할 수 있습니다.
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
그런 다음 업그레이드를 다시 시도하세요.
Aurora MySQL 현재 위치 업그레이드를 위한 문제 해결
다음 팁을 사용하면 Aurora MySQL 인플레이스 업그레이드와 관련된 문제를 해결하는 데 도움이 됩니다. 이러한 팁은 Aurora Serverless DB 클러스터에는 적용되지 않습니다.
현재 위치 업그레이드가 취소되거나 느린 이유 | Effect | 유지 관리 기간 내에 현재 위치 업그레이드를 완료할 수 있는 솔루션 |
---|---|---|
관련 Aurora 크로스 리전 복제본이 아직 패치되지 않음 | Aurora는 업그레이드를 취소합니다. | Aurora 크로스 리전 복제본을 업그레이드하고 다시 시도합니다. |
클러스터에 준비된 상태의 XA 트랜잭션이 있습니다. | Aurora는 업그레이드를 취소합니다. | 준비된 모든 XA 트랜잭션을 커밋하거나 롤백합니다. |
클러스터가 데이터 정의 언어(DDL)문을 처리하고 있습니다. | Aurora는 업그레이드를 취소합니다. | 모든 DDL문이 완료된 후 대기하고 업그레이드를 수행하기를 고려하십시오. |
클러스터에 많은 행에 대해 커밋되지 않은 변경 사항이 있습니다. | 업그레이드에 시간이 오래 걸릴 수 있습니다. |
업그레이드 프로세스는 커밋되지 않은 변경 사항을 롤백합니다. 이 조건에 대한 표시기는 모든 대규모 트랜잭션이 커밋되거나 롤백된 후에만 업그레이드를 수행하는 것이 좋습니다. |
클러스터에 실행 취소 레코드 수가 많음 | 업그레이드에 시간이 오래 걸릴 수 있습니다. |
커밋되지 않은 트랜잭션이 대량의 행에 영향을 미치지 않더라도 대량의 데이터가 포함될 수 있습니다. 예를 들어 대형 BLOB를 삽입할 수 있습니다. Aurora는 이러한 종류의 트랜잭션 활동에 대한 이벤트를 자동으로 감지하거나 생성하지 않습니다. 이 조건에 대한 지표는 HLL(기록 목록 길이)입니다. 업그레이드 프로세스는 커밋되지 않은 변경 사항을 롤백합니다.
또한 Amazon CloudWatch를 사용하여 HLL의 길이가 더 줄어든 후에 한하여 업그레이드 수행을 고려하세요. |
클러스터가 큰 이진 로그 트랜잭션을 커밋하는 중입니다. | 업그레이드에 시간이 오래 걸릴 수 있습니다. |
업그레이드 프로세스는 이진 로그 변경 내용이 적용될 때까지 기다립니다. 이 기간 동안 더 많은 트랜잭션 또는 DDL문이 시작될 수 있으므로 업그레이드 프로세스가 느려질 수 있습니다. 클러스터가 이진 로그 복제 변경 내용을 생성하느라 바쁜 경우가 아니면 업그레이드 프로세스를 예약합니다. Aurora는 이 조건에 대한 이벤트를 자동으로 감지하거나 생성하지 않습니다. |
파일 제거 또는 손상으로 인한 스키마 불일치 | Aurora는 업그레이드를 취소합니다. |
임시 테이블의 기본 스토리지 엔진을 MyISAM에서 InnoDB로 변경합니다. 다음 단계를 수행합니다.
|
마스터 사용자 삭제됨 | Aurora는 업그레이드를 취소합니다. |
중요마스터 사용자는 삭제하지 마세요. 하지만 어떤 이유로든 마스터 사용자를 삭제해야 하는 경우 다음 SQL 명령을 사용하여 복원하세요.
|
업그레이드 사전 검사 실패를 유발하는 문제 해결에 대한 자세한 내용은 다음 블로그를 참조하세요.
다음 단계를 사용하여 위 테이블의 일부 조건에 대해 직접 검사를 수행할 수 있습니다. 이렇게 하면 데이터베이스가 업그레이드가 성공적으로 신속하게 완료될 수 있는 상태임을 알고 있을 때 업그레이드를 예약할 수 있습니다.
-
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 버전 3에 대한 업그레이드 후 정리
Aurora MySQL 버전 2 클러스터를 Aurora MySQL 버전 3으로 업그레이드한 후 다음과 같은 기타 정리 작업을 수행할 수 있습니다.
-
모든 사용자 지정 파라미터 그룹의 MySQL 8.0 호환 버전을 새로 만듭니다. 필요한 모든 사용자 파라미터 값을 새 파라미터 그룹에 적용합니다.
-
CloudWatch 경보, 설정 스크립트 등을 업데이트하여 이름이 포괄적 언어 변경의 영향을 받은 모든 표지에 새 이름을 사용합니다. 이런 지표 목록은 Aurora MySQL 버전 3에 대한 포괄적 언어 변경 섹션을 참조하세요.
-
모든 AWS CloudFormation 템플릿을 업데이트하여 이름이 포괄적 언어 변경의 영향을 받은 모든 구성 파라미터에 새 이름을 사용합니다. 이런 파라미터 전체 목록은 Aurora MySQL 버전 3에 대한 포괄적 언어 변경 섹션을 참조하세요.
공간 인덱스
Aurora MySQL 버전 3으로 업그레이드한 후 공간 인덱스와 관련된 객체 및 인덱스를 삭제하거나 다시 생성해야 하는지 확인합니다. MySQL 8.0 이전에 Aurora는 공간 리소스 식별자(SRID)를 포함하지 않은 인덱스를 사용하여 공간 쿼리를 최적화할 수 있었습니다. Aurora MySQL 버전 3은 SRID를 포함하는 공간 인덱스만 사용합니다. 업그레이드 중에 Aurora는 SRID 없는 모든 공간 인덱스를 자동으로 삭제하고 데이터베이스 로그에 경고 메시지를 인쇄합니다. 이러한 경고 메시지가 표시되면 업그레이드 후 SRID를 사용하여 새 공간 인덱스를 생성합니다. MySQL 8.0의 공간 함수와 데이터 유형 변경에 대한 자세한 내용은 MySQL 참조 설명서의 MySQL 8.0의 변경 사항