MySQL 인스턴스용 Amazon Relational Database Service(Amazon RDS)의 스냅샷 복원 시간을 줄이려면 어떻게 해야 합니까?

간략한 설명

일반적으로 스냅샷 복원 시간이 긴 것은 데이터베이스 복구 시간이 길기 때문입니다. 데이터베이스 복구 시간은 스냅샷이 발생한 시점의 인스턴스 워크로드를 기반으로 합니다. 소스 DB 인스턴스에서 바이너리 로깅을 활성화한 경우 복구 및 스냅샷 복원 시간이 더 오래 걸릴 수 있습니다.

스냅샷을 복원하면 Amazon RDS가 복구 프로세스를 수행하고 새 DB 인스턴스에서 MySQL DB 엔진이 시작됩니다. 복구 세션 시간을 기준으로 하면 새 DB 인스턴스를 시작하는 데 최대 몇 분 정도 걸릴 수 있습니다. 자세한 내용은 MySQL 웹사이트에서 InnoDB 충돌 복구를 참조하십시오.

참고: Amazon Simple Storage Service(Amazon S3)에서 볼륨이 완전히 복원될 때까지 약간의 지연 시간 또는 지연 로딩이 발생합니다. 자세한 내용은 DB 스냅샷에서 복원을 참조하십시오.

시점 복구(PITR)에 대해서는 Amazon RDS for MySQL 인스턴스의 시점 복구를 수행하는 데 시간이 오래 걸리는 이유는 무엇입니까?를 참조하십시오.

해결 방법

스냅샷 복원 시간을 줄이려면 다음 모범 사례를 사용하십시오.

• 백업 기간을 예약하거나 사용량이 많지 않은 시간대에 DB 인스턴스의 수동 스냅샷을 생성합니다. 스냅샷을 생성할 때 소스 DB 인스턴스에서 수행하는 활동은 데이터베이스 및 스냅샷 복구 시간에 영향을 줍니다.
• 소스 인스턴스가 스냅샷 중에 마그네틱 스토리지 유형을 사용하는 경우 복원된 인스턴스는 수정 중 상태입니다. 예를 들어 DB 스냅샷을 범용 SSD gp2 또는 프로비저닝된 IOPS 스토리지 유형으로 복원하면 볼륨 변경이 발생합니다. 이 기간 동안 Amazon RDS 인스턴스에 연결할 수 있지만 성능 저하가 발생할 수 있습니다.
• 인스턴스를 임시로 상위 DB 인스턴스 클래스로 복원합니다. DB 인스턴스 클래스를 업그레이드하면 일시적으로 더 많은 리소스가 확보되고 충돌 복구 시간이 단축됩니다. 스냅샷 복원이 완료된 후 인스턴스 클래스를 스케일 다운할 수 있습니다.

바이너리 로깅이 켜진 스냅샷의 스냅샷 복원 시간을 줄이려면 다음 모범 사례를 사용하십시오.

• binlog 복구 시간을 줄이려면 대규모 트랜잭션 및 대규모 binlog 파일을 피합니다. 대규모 데이터가 포함된 바이너리 로그는 binlog 복구 시간이 길어집니다. 또한 스냅샷 복원 시간도 늘어납니다.
• 적절한 트랜잭션 크기를 사용합니다. 대규모 트랜잭션은 바이너리 로그 파일에 한 번에 기록되며 서로 다른 파일 간에 분할되지 않습니다. 따라서 바이너리 로그 파일이 커지고 충돌 복구 시간이 길어집니다.
• 적절한 바이너리 로깅 형식을 사용합니다. 바이너리 로깅 형식은 충돌 복구의 크기와 효율성에 영향을 줄 수 있습니다. 자세한 내용은 MySQL 웹사이트에서 행 기반 로깅 및 복제 사용을 참조하십시오. 바이너리 로깅 형식에 대한 자세한 내용은 MySQL 웹사이트에서 명령문 기반 및 행 기반 복제의 장점 및 단점을 참조하십시오.

참고: 지연 로딩을 더 빠르게 완료하려면 처리량이 더 높은 Amazon RDS 인스턴스 유형과 Amazon Elastic Block Store(Amazon EBS) 볼륨을 사용하십시오. 지연 로딩이 완료된 후 인스턴스 클래스 유형을 다운그레이드하고 IOPS 및 처리량 값을 줄일 수 있습니다.