Amazon Aurora DB 클러스터 복제, 스냅샷 복원 또는 특정 시점 복원에 시간이 너무 오래 걸리는 이유는 무엇입니까?

3분 분량
0

Amazon Aurora 클러스터에서 클러스터 복제, 스냅샷 복원 또는 특정 시점 작업을 수행하고 있습니다.

간략한 설명

Amazon Aurora의 지속적인 백업 및 복원 기술은 복원 시간의 변동성을 없애도록 최적화되어 있습니다. 또한 클러스터를 사용할 수 있게 되는 즉시 클러스터의 스토리지 볼륨이 최대 성능에 도달하는 데 도움이 됩니다. 일반적으로 긴 복원 시간은 백업을 수행할 때 소스 데이터베이스의 장기 실행 트랜잭션으로 인해 발생합니다.

해결 방법

참고: AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생할 경우 AWS CLI의 최신 버전을 사용하고 있는지 확인하세요.

Amazon Aurora는 클러스터 볼륨의 변경 사항을 자동으로 지속적으로 백업합니다. 백업은 백업 보존 기간 동안 보존됩니다. 이렇게 지속적으로 백업하면 지정된 보존 기간 내의 어느 시점으로든 데이터를 새 클러스터로 복원할 수 있습니다. 이렇게 하면 시간이 오래 걸리는 이진 로그 롤포워드 프로세스가 필요하지 않습니다. 새 클러스터를 생성하므로 원래 데이터베이스의 성능이나 중단에 영향을 미치지 않습니다.

복제, 스냅샷 또는 특정 시점 복원을 시작하면 Amazon Relational Database Service(RDS)는 사용자를 대신하여 다음 API를 호출합니다.

이 단계가 완료되면 클러스터가 사용 가능 상태로 변경됩니다. 콘솔을 새로 고치거나 AWS CLI를 확인하여 클러스터 상태를 확인할 수 있습니다.

인스턴스 생성 프로세스는 클러스터가 사용 가능 상태일 때만 시작됩니다. 이는 인스턴스 구성 설정 및 데이터베이스 크래시 복구의 두 단계로 이루어집니다.

MySQL 오류 로그 파일을 찾아 API가 인스턴스 설정을 완료했는지 확인할 수 있습니다. 인스턴스가 생성 중 상태인 경우에도 이 작업을 수행할 수 있습니다. 오류 로그 파일을 다운로드할 수 있는 경우 인스턴스가 설정되고 엔진이 크래시 복구를 수행하고 있는 것입니다. 오류 로그 파일은 Amazon CloudWatch 지표와 함께 데이터베이스 크래시 복구 진행 상황을 확인할 수 있는 최고의 리소스입니다.

참고: AWS CLI 또는 API를 사용하여 복원 작업을 수행하는 경우 CreateDBInstance 호출은 자동이 아니므로 호출해야 합니다.

소스 데이터베이스에서 장기 실행 쓰기 작업 확인

스냅샷, 특정 시점 또는 복제본 생성 시점에 소스 데이터베이스에 장기 실행 쓰기 작업이 없는지 확인하는 것이 가장 좋습니다. 장기 실행 DCL, DDL 또는 DML(열린 쓰기 트랜잭션)을 사용하면 복원된 데이터베이스를 사용할 수 있게 되는 데 걸리는 시간이 늘어날 수 있습니다.

예를 들어 Aurora 클러스터에 대해 이진 로그를 활성화하면 복구를 수행하는 데 걸리는 시간이 늘어납니다. 이는 InnoDB가 자동으로 로그를 검사하고 현재 시점으로 데이터베이스의 롤포워드를 수행하기 때문입니다. 그런 다음 복구 시 존재하는 커밋되지 않은 트랜잭션을 롤백합니다. InnoDB 크래시 복구에 대한 자세한 내용은 Innodb 복구를 참조하십시오.

인스턴스가 생성 및 복구 프로세스를 완료하면 클러스터와 인스턴스가 들어오는 연결을 수락할 준비가 됩니다.

참고: Aurora에는 이진 로그가 필요하지 않습니다. 꼭 필요한 경우가 아니면 비활성화하는 것이 가장 좋습니다. 리전 간 복제의 경우 대신 Aurora 글로벌 데이터베이스를 평가할 수 있습니다. Aurora 글로벌 데이터베이스에는 이진 로그도 필요하지 않습니다.


관련 정보

Amazon Aurora 스토리지 및 안정성

DB 클러스터 스냅샷에서 복원

AWS 공식
AWS 공식업데이트됨 일 년 전