Amazon RDS for MySQL 인스턴스에서 특정 시점으로 복구를 수행하는 데 시간이 오래 걸리는 이유는 무엇입니까?

간략한 설명

특정 시점으로 복구(PITR)는 데이터베이스를 지정된 날짜 및 시간에 있던 상태로 복원하는 프로세스입니다. PITR을 시작하면 가장 최근의 백업(자동 또는 수동)이 복원됩니다. 그런 다음 트랜잭션 로그가 적용되어 Amazon RDS 데이터베이스를 PITR 시간으로 포워드합니다.

해결 방법

오래 걸리는 특정 시점으로 복구 방지를 위한 모범 사례

오래 걸리는 특정 시점으로 복구를 방지하려면 다음 모범 사례를 따르세요.

• 재해 복구 전략을 생성합니다.
• 작은 트랜잭션을 사용하고 COMMIT 명령을 더 자주 실행합니다.
• 대규모 트랜잭션을 실행하려면 대규모 트랜잭션 전후에 스냅샷을 만듭니다. 그러나 max_allowed_packet 파라미터보다 큰 트랜잭션은 PITR 실패를 일으킵니다.
• 스냅샷 복원 시간을 최소화합니다. 스냅샷 복원은 특정 시점으로 복구 프로세스의 일부로 시작됩니다. 스냅샷 복원이 길어지면 특정 시점으로 복구 세션이 길어질 수 있습니다. 자세한 내용은 Amazon RDS for MySQL DB 인스턴스의 스냅샷을 복원하는 데 오랜 시간이 걸리는 이유는 무엇입니까?를 참조하세요.
• 로그 적용 프로세스는 적용할 로그 수에 따라 시간이 많이 걸릴 수 있습니다. 적용할 로그 수를 줄이려면 자동 백업 사이에 수동 스냅샷을 생성하는 것이 좋습니다. 특정 시점으로 복구는 PITR 시간 근처에서 생성된 자동 또는 수동 스냅샷을 자동으로 선택하므로 중간 수동 스냅샷이 있으면 적용할 로그 수를 줄일 수 있습니다. 대량의 변경 사항을 처리하는 경우 3~4시간마다 수동 스냅샷을 생성하세요.
• 대규모 트랜잭션을 재생하는 경우 wait_timeout 값이 낮으면 Amazon RDS for MySQL에서 특정 시점으로의 복원 프로세스가 중단될 수 있습니다. 예를 들어 대량의 행 기반 대량 업데이트, 삽입 또는 삭제를 수행하고 재생이 wait_timeout보다 오래 걸리는 경우 중단이 발생합니다. PITR 프로세스 중단을 방지하려면 wait_timeout 값을 ‘600’(10분) 이상으로 설정합니다. 자세한 내용은 Amazon RDS for MySQL에 대한 파라미터를 구성하는 모범 사례의 wait_timeout을 참조하세요.
• 행 기반 이진 로깅을 사용하는 경우 binlog_row_image 파라미터 값을 ‘FULL’ 대신 ‘MINIMAL’로 설정하는 것이 좋습니다. 이 업데이트된 값은 이진 로그의 크기를 줄여 binlog 복구 시간을 최소화합니다.
• 특정 binlog 형식이 필요한 경우가 아니라면 MIXED 로깅 형식을 사용하는 것이 좋습니다. 혼합 로깅에서는 문 기반 로깅이 기본적으로 사용되지만 로깅 모드는 필요에 따라 자동으로 행 기반으로 전환됩니다. 이러한 전환을 통해 binlog 크기를 줄일 수 있습니다. MIXED 로깅에 대한 자세한 내용은 MySQL 웹 사이트의 이진 로깅 형식을 참조하세요.

특정 시점으로 복구 실패

다음 시나리오에서는 특정 시점으로 복구가 실패합니다.

• ‘스토리지 가득 참’ 상태에 있는 DB 인스턴스.
• MySQL에서 MyISAM 테이블 사용. MyISAM 스토리지 엔진이 신뢰할 수 있는 충돌 복구 프로세스를 지원하지 않음. MyISAM 테이블이 특정 시점으로 복구 프로세스가 제대로 작동하는 것을 방해함.
• 임시 테이블, 분산 트랜잭션 및 인 메모리 테이블 사용.

---