마이너 버전 업그레이드를 수행하기 전 Aurora MySQL에 대한 마이너 버전 업그레이드 사전 확인 엔진 버전 수정 마이너 버전 간 자동 업그레이드 활성화 제로 가동 중지 패치 적용 기능 사용 대체 블루/그린 업그레이드 기법

Aurora MySQL DB 클러스터의 부 버전 또는 패치 수준 업그레이드

다음 방법을 사용하여 DB 클러스터의 마이너 버전을 업그레이드하거나 DB 클러스터에 패치를 적용할 수 있습니다.

엔진 버전을 수정하여 Aurora MySQL 업그레이드(Aurora MySQL 버전 2 및 3의 경우)
마이너 Aurora MySQL 버전 간 자동 업그레이드 활성화

제로 중지 시간 패치로 업그레이드 프로세스 중 중단을 줄이는 방법에 대한 자세한 내용은 제로 가동 중지 패치 적용 기능 사용 단원을 참조하세요.

마이너 버전 업그레이드를 수행하기 전

마이너 버전 업그레이드 중에 가동 중지 시간을 줄이려면 다음 작업을 수행하는 것이 좋습니다.

Aurora DB 클러스터 유지 관리는 트래픽이 적은 기간에 수행해야 합니다. 성능 개선 도우미를 사용하여 이러한 기간을 식별하여 유지 관리 기간을 올바르게 구성하세요. 성능 개선 도우미에 대한 자세한 내용은 Amazon RDS에서 성능 개선 도우미를 통한 DB 로드 모니터링을 참조하세요. DB 클러스터 유지 관리 기간에 대한 자세한 내용은 기본 DB 클러스터 유지 관리 기간 조정 섹션을 참조하세요.
지수 백오프와 지터를 지원하는 AWS SDK를 모범 사례로 사용하세요. 자세한 내용은 지수 백오프 및 지터를 참조하세요.

Aurora MySQL에 대한 마이너 버전 업그레이드 사전 확인

마이너 버전 업그레이드를 시작하면 Amazon Aurora가 자동으로 사전 검사를 실행합니다.

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

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

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

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

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

엔진 버전을 수정하여 Aurora MySQL 업그레이드

Aurora MySQL DB 클러스터의 마이너 버전을 업그레이드하면 기존 클러스터에 추가 수정 사항과 새로운 기능이 적용됩니다.

이 유형의 업그레이드는 원래 버전과 업그레이드된 버전이 모두 동일한 Aurora MySQL 메이저 버전 2 또는 3인 Aurora MySQL 클러스터에 적용됩니다. 이 프로세스는 Aurora MySQL 메타데이터 변환이나 테이블 데이터 재구성을 포함하지 않기 때문에 빠르고 간단합니다.

이 유형의 업그레이드를 수행하려면 AWS Management Console, AWS CLI 또는 RDS API를 사용하여 DB 클러스터의 엔진 버전을 수정합니다. 예를 들어, 클러스터가 Aurora MySQL 2.x를 실행하는 경우 더 높은 2.x 버전을 선택합니다.

Aurora 글로벌 데이터베이스에서 마이너 업그레이드를 수행하는 경우 기본 클러스터를 업그레이드하기 전에 모든 보조 클러스터를 업그레이드합니다.

참고

Aurora MySQL 버전 3.03.* 이상 또는 버전 2.12로 마이너 버전 업그레이드를 수행하려면 다음 프로세스를 사용하세요.

글로벌 클러스터에서 모든 보조 DB 클러스터를 제거합니다. Amazon Aurora 글로벌 데이터베이스에서 클러스터 제거 단원의 단계를 따르세요.
기본 리전의 엔진 버전을 버전 3.03.* 이상 또는 버전 2.12.* 중 적합한 것으로 업그레이드합니다. To modify the engine version of a DB cluster 단원의 단계를 따르세요.
글로벌 클러스터에 보조 리전을 추가합니다. Amazon Aurora Global Database에 AWS 리전 추가 단원의 단계를 따르세요.

DB 클러스터의 엔진 버전을 수정하는 방법

콘솔 사용하여 – 클러스터의 속성을 수정합니다. DB 클러스터 수정(Modify DB cluster) 창의 DB 엔진 버전(DB engine version) 상자에서 Aurora MySQL 엔진 버전을 변경합니다. 일반적인 클러스터 수정 절차에 익숙하지 않을 경우 콘솔, CLI, API를 사용하여 DB 클러스터 수정의 지침을 따르세요.
AWS CLI를 사용하여 modify-db-cluster AWS CLI 명령을 호출한 후 --db-cluster-identifier 옵션에 대한 DB 클러스터 이름, --engine-version 옵션에 엔진 버전을 지정합니다.

예를 들어, Aurora MySQL 버전 2.12.1로 업그레이드하려면 --engine-version 옵션을 5.7.mysql_aurora.2.12.1로 설정합니다. DB 클러스터의 엔진 버전을 즉시 업데이트하려면 --apply-immediately 옵션을 설정합니다.
RDS API를 사용하여 – ModifyDBCluster API 작업을 호출한 후 DBClusterIdentifier 파라미터에 대한 DB 클러스터 이름을 지정하고 EngineVersion 파라미터에 엔진 버전을 지정합니다. DB 클러스터의 엔진 버전을 즉시 업데이트하려면 ApplyImmediately 파라미터를 true로 설정합니다.

마이너 Aurora MySQL 버전 간 자동 업그레이드 활성화

Amazon Aurora MySQL DB 클러스터의 경우 Aurora가 DB 클러스터를 자동으로 새로운 마이너 버전으로 업그레이드하도록 지정할 수 있습니다. 이렇게 하려면 DB 클러스터의 AutoMinorVersionUpgrade 속성(AWS Management Console의 자동 마이너 버전 업그레이드)을 설정합니다.

자동 업그레이드는 유지 관리 기간 중에 발생합니다. DB 클러스터에서 개별 DB 인스턴스의 유지 관리 기간이 클러스터 유지 관리 기간과 다른 경우 클러스터 유지 관리 기간이 우선합니다.

마이너 버전 자동 업그레이드는 다음 종류의 Aurora MySQL 클러스터에는 적용되지 않습니다.

Aurora 글로벌 데이터베이스의 일부로 포함된 클러스터
리전 간 복제본이 있는 클러스터

운영 중단 기간은 워크로드, 클러스터 크기, 이진 로그 데이터의 양 및 Aurora가 제로 다운타임 패치 적용(ZDP) 기능을 사용할 수 있는지 여부에 따라 달라집니다. Aurora는 데이터베이스 클러스터를 재시작하므로 클러스터를 다시 사용하기 전에 잠시 동안 사용할 수 없게 될 수 있습니다. 특히 이진 로그 데이터의 양은 복구 시간에 영향을 미칩니다. DB 인스턴스는 복구 중에 이진 로그 데이터를 처리합니다. 따라서 이진 로그 데이터의 양이 많으면 복구 시간이 늘어납니다.

참고

Aurora는 DB 클러스터의 모든 DB 인스턴스에 AutoMinorVersionUpgrade 설정이 활성화된 경우에만 자동 업그레이드를 수행합니다. 설정하는 방법과 클러스터 및 인스턴스 수준에서 설정을 적용한 경우 작동 방식에 대한 자세한 내용은 Aurora DB 클러스터 마이너 버전 자동 업그레이드 섹션을 참조하세요.

그러면 AutoUpgrade가 true로 설정된 DB 클러스터의 인스턴스에 대해 마이너 DB 엔진 버전으로의 업그레이드 경로가 있는 경우 업그레이드가 수행됩니다. AutoUpgrade 설정은 동적이며 RDS에서 설정합니다.

자동 마이너 버전 업그레이드는 기본 마이너 버전으로 수행됩니다.

다음과 같은 CLI 명령을 사용하여 Aurora MySQL 클러스터의 모든 DB 인스턴스에 대한 AutoMinorVersionUpgrade 설정의 상태를 확인할 수 있습니다.


aws rds describe-db-instances \
  --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

이 명령을 실행하면 다음과 비슷한 출력이 생성됩니다.


[
  {
      "DBInstanceIdentifier": "db-t2-medium-instance",
      "DBClusterIdentifier": "cluster-57-2020-06-03-6411",
      "AutoMinorVersionUpgrade": true
  },
  {
      "DBInstanceIdentifier": "db-t2-small-original-size",
      "DBClusterIdentifier": "cluster-57-2020-06-03-6411",
      "AutoMinorVersionUpgrade": false
  },
  {
      "DBInstanceIdentifier": "instance-2020-05-01-2332",
      "DBClusterIdentifier": "cluster-57-2020-05-01-4615",
      "AutoMinorVersionUpgrade": true
  },
... output omitted ...

이 예시에서는 클러스터의 DB 인스턴스 중 하나에 대해 마이너 버전 자동 업그레이드 사용이 꺼져 있으므로, DB 클러스터 cluster-57-2020-06-03-6411에 대한 마이너 버전 자동 업그레이드 사용도 꺼져 있습니다.

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

Aurora MySQL DB 클러스터에 대한 업그레이드를 수행할 때는 데이터베이스가 종료되고 업그레이드되는 동안 중단될 가능성이 있습니다. 기본적으로 데이터베이스가 사용 중인 동안 업그레이드를 시작하면 DB 클러스터에서 처리하는 모든 연결 및 트랜잭션이 손실됩니다. 업그레이드를 수행하기 위해 데이터베이스가 유휴 상태가 될 때까지 기다리려면 오랜 시간을 기다려야 할 수 있습니다.

제로 가동 중지 패치 적용(ZDP) 기능은 최선의 노력을 기반으로 Aurora MySQL 업그레이드 중에 클라이언트 연결을 유지하려고 시도합니다. ZDP가 성공적으로 완료되면 업그레이드 진행 중에 애플리케이션 세션이 유지되고 데이터베이스 엔진이 다시 시작됩니다. 데이터베이스 엔진이 다시 시작되면 몇 초에서 약 1분간 처리량이 저하될 수 있습니다.

ZDP는 다음에는 적용되지 않습니다.

운영 체제(OS) 패치 및 업그레이드
메이저 버전 업그레이드

ZDP를 사용할 수 있는 모든 Aurora MySQL 버전과 DB 인스턴스 클래스에 사용할 수 있습니다.

Aurora Serverless v1 또는 Aurora 글로벌 데이터베이스에는 ZDP가 지원되지 않습니다.

참고

T DB 인스턴스 클래스는 개발 및 테스트 서버 또는 기타 비프로덕션 서버에만 사용하는 것이 좋습니다. T 인스턴스 클래스에 대한 자세한 내용은 개발 및 테스트에 T 인스턴스 클래스 사용 섹션을 참조하세요.

ZDP 중에 MySQL 오류 로그에서 중요한 속성의 지표를 볼 수 있습니다. AWS Management Console의 이벤트 페이지에서 Aurora MySQL이 ZDP를 사용하거나 ZDP를 사용하지 않도록 선택하는 경우에 대한 정보도 볼 수 있습니다.

Aurora MySQL 버전 2.10 이상 및 버전 3에서 Aurora는 바이너리 로그 복제가 활성화되었는지 여부와 상관없이 가동 중지 없는 패치를 수행할 수 있습니다. 바이너리 로그 복제가 활성화되어 있으면 Aurora MySQL은 ZDP 작업 중에 binlog 대상에 대한 연결을 자동으로 삭제합니다. Aurora MySQL은 binlog 대상에 자동으로 다시 연결하고 재시작이 완료된 후 복제를 재개합니다.

또한 ZDP는 Aurora MySQL 2.10 이상의 재부팅 개선 사항과 함께 작동합니다. 라이터 DB 인스턴스에 패치를 적용하면 동시에 리더에도 자동으로 패치가 적용됩니다. 패치를 수행한 후 Aurora는 라이터와 리더 DB 인스턴스에서 연결을 복원합니다. Aurora MySQL 2.10 이전에서 ZDP는 클러스터의 라이터 DB 인스턴스에만 적용됩니다.

다음 조건에서는 ZDP가 성공적으로 완료되지 않을 수 있습니다.

장기간 쿼리 또는 트랜잭션이 진행 중인 경우 이 경우 Aurora가 ZDP를 수행할 수 있다면 열린 트랙잭션은 취소되지만, 연결은 유지됩니다.
임시 표, 사용자 잠금 또는 표 잠금은 가령 데이터 정의 언어(DDL) 문이 실행되는 동안 사용됩니다. Aurora는 이러한 연결을 끊습니다.
보류 중인 파라미터 변경 사항이 존재하는 경우

이러한 조건 때문에 ZDP 수행을 위한 적절한 기간을 확보할 수 없는 경우 패치 적용이 표준 동작으로 돌아갑니다.

참고

Aurora MySQL 버전 2가 2.11.0 미만이고 버전 3이 3.04.0보다 낮은 경우 보안 소켓 계층(SSL) 또는 전송 계층 보안(TLS) 연결이 열려 있을 때 ZDP가 제대로 완료되지 않을 수 있습니다.

성공적인 ZDP 작업 후에 연결은 그대로 유지되지만 일부 변수와 기능은 다시 초기화됩니다. 다음 유형의 정보는 제로 다운타임 패치 적용으로 인한 다시 시작 중에 보관되지 않습니다.

글로벌 변수 Aurora는 세션 변수를 복원하지만 다시 시작 후 글로벌 변수를 복원하지 않습니다.
상태 변수. 특히 엔진 상태로 보고되는 가동 시간 값은 ZDR 또는 ZDP 메커니즘을 사용하는 다시 시작 후 재설정됩니다.
LAST_INSERT_ID.
테이블의 인 메모리 auto_increment 상태. 인 메모리 자동 증분 상태는 다시 초기화됩니다. 자동 증분 값에 대한 자세한 내용은 MySQL 참조 매뉴얼을 참조하세요.
INFORMATION_SCHEMA 및 PERFORMANCE_SCHEMA 테이블의 진단 정보. 이 진단 정보는 SHOW PROFILE 및 SHOW PROFILES와 같은 명령 출력에도 표시됩니다.

제로 다운타임 다시 시작과 관련된 다음 활동은 [이벤트(Events) 페이지에 보고됩니다.

제로 다운타임으로 데이터베이스를 업그레이드하려는 시도
제로 다운타임으로 데이터베이스를 업그레이드하려는 시도가 완료되었습니다. 이벤트는 프로세스에 걸린 시간을 보고합니다. 또한 이벤트는 다시 시작 중에 보관된 연결 수와 삭제된 연결 수를 보고합니다. 데이터베이스 오류 로그를 참조하여 다시 시작 중에 발생한 활동에 대한 자세한 내용을 확인할 수 있습니다.

대체 블루/그린 업그레이드 기법

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

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

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

문서 규칙

Amazon Aurora MySQL DB 클러스터 업그레이드

DB 클러스터의 Aurora MySQL 주 버전 업그레이드