Amazon RDS for MySQL DB 인스턴스의 스냅샷을 복원하는 데 오랜 시간이 걸리는 이유는 무엇입니까?

간략한 설명

스냅샷 복구 시간이 긴 것은 일반적으로 긴 데이터베이스 복구로 인해 발생합니다. 복구 시간은 스냅샷 생성 시 해당 인스턴스의 워크로드에 따라 다릅니다. 원본 DB 인스턴스에 바이너리 로깅이 활성화되어 있으면 복구 시간이 오래 걸릴 수 있습니다. 따라서 스냅샷 복구 기간도 영향을 받을 수 있습니다.

해결 방법

스냅샷을 복원하면 Amazon RDS가 복구 프로세스를 수행하며 새 DB 인스턴스에서 MySQL DB 엔진이 시작됩니다. 새 DB 인스턴스 시작은 인스턴스 시작 중 복구 세션의 길이에 따라 최대 몇 분 정도 걸릴 수 있습니다. 자세한 내용은 MySQL 웹 사이트에서 InnoDB 충돌 복구를 참조하세요.

참고: Amazon Simple Storage Service(Amazon S3)에서 볼륨이 완전히 공급될 때까지 지연 시간(또는 지연 로딩)이 발생할 수 있습니다. 지연 로딩에 대한 자세한 내용은 스냅샷에서 복원을 참조하세요.

Amazon RDS에서 스냅샷 복원 완료 시간을 줄이려면 다음 방법을 고려하세요.

• 사용량이 적은 시간에 백업 기간을 예약하거나 DB 인스턴스의 수동 스냅샷을 생성합니다. 스냅샷을 생성하는 동안 원본 DB 인스턴스에서 수행되는 작업은 데이터베이스 복구 시간과 스냅샷 복원 시간에 영향을 줍니다.
• 스냅샷 중에 소스 인스턴스가 마그네틱 스토리지 유형을 사용하는 경우 새로 복원된 인스턴스는 수정 상태가 됩니다. 예를 들어 DB 스냅샷을 범용 SSD(GP2) 또는 프로비저닝된 IOPS(PIOPS) 스토리지 유형으로 복원하면 기본 볼륨 변경이 발생합니다. 결과적으로 새 인스턴스는 ‘수정’ 상태가 표시됩니다. 이 기간 동안에는 일부 성능 저하가 발생할 수 있지만 Amazon RDS 인스턴스에 연결할 수 있습니다.
• 일시적으로 인스턴스를 더 높은 DB 인스턴스 클래스(예: 메모리 또는 RAM이 더 많은 인스턴스 클래스)로 복원합니다. DB 인스턴스 클래스를 업그레이드하면 충돌 복구 시간을 향상시킬 수 있습니다. 일시적으로 더 많은 리소스를 확보하여 전체 충돌 복구 시간을 단축할 수 있습니다. 스냅샷 복원이 완료된 후 인스턴스 클래스를 축소할 수 있습니다.

Amazon RDS에서 바이너리 로깅이 활성화된 스냅샷의 스냅샷 복원 완료 시간을 줄이려면 다음 사항을 고려하세요.

• 바이너리 로깅이 활성화되면(예: 원본 인스턴스에 자동 백업이 활성화된 경우) 바이너리 로그는 스냅샷 복원 시간에 직접적인 영향을 줍니다. 충돌 복구 중에 스냅샷 복원 프로세스는 바이너리 로그 복구도 수행합니다.
• binlog 복구 시간을 줄이려면 대규모 트랜잭션과 큰 binlog 파일을 피하세요. 바이너리 로그에 기록되는 데이터가 많을수록 binlog 복구 중에 복원 프로세스가 처리해야 하는 데이터가 많아집니다. 따라서 복구 시간이 늘어나고 스냅샷 복구 시간도 늘어납니다.
• 가능하면 올바른 트랜잭션 크기를 사용하세요. 대규모 트랜잭션은 한 번에 바이너리 로그 파일에 기록되며 서로 다른 파일 사이에 분할되지 않습니다. 결과적으로 바이너리 로그 파일이 커지면서 충돌 복구 시간이 늘어납니다.
• 사용되는 바이너리 로깅 형식 유형은 복구의 크기와 효율성에 영향을 줄 수도 있습니다. 일부 형식(예: 행 기반 로깅)은 바이너리 로그의 다른 형식보다 더 많은 정보를 기록합니다. 테이블에서 많은 수의 행을 수정하는 문을 사용하면 DB 엔진이 수정된 모든 행에 대해 binlog 항목을 생성합니다. 결과적으로 큰 binlog 파일을 얻을 수 있습니다. 행 기반 로깅 형식에 대한 자세한 내용은 MySQL 웹 사이트에서 행 기반 로깅 및 복제 사용을 참조하세요. 다양한 유형의 바이너리 로깅 형식에 대한 자세한 내용은 MySQL 웹 사이트에서 문 기반 및 행 기반 복제의 장점과 단점을 참조하세요.

---