Aurora MySQL에 대한 메이저 버전 업그레이드 사전 확인 - Amazon Aurora
커뮤니티 MySQL 업그레이드 사전 확인Aurora MySQL 업그레이드 사전 확인Aurora MySQL 주 버전 업그레이드 경로Aurora MySQL 현재 위치 주 버전 업그레이드 작동 방식블루/그린 배포

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를 사용한다면, 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 블루/그린 배포 사용을 참조하세요.