Amazon RDS DB 인스턴스의 특정 시점으로 복원하는 데 시간이 오래 걸리는 이유는 무엇입니까?

간략한 설명

특정 시점 복원 옵션을 사용하면 자동 백업이 활성화된 특정 시점으로 DB 인스턴스를 복원할 수 있습니다. 자동 백업이 활성화된 Amazon RDS 인스턴스는 복원 가능한 가장 이른 시간까지 복원할 수 있습니다. 복원 가능한 가장 이른 시간은 인스턴스를 복원할 수 있는 백업 보존 기간 내에서 얼마나 되돌아 갈지를 지정하는 것입니다. 최대 보존 기간은 35일(달력 기준 5주)로 설정됩니다. 인스턴스를 수정하여 이 값을 0일에서 35일로 변경할 수 있습니다. 특정 시점으로 복원을 시작할 수 있으며, 복원 가능한 최근 시간까지 보존 기간 내에서 날짜 및 시간을 지정할 수 있습니다. 복원 가능한 최근 시간은 인스턴스를 복원할 수 있는 가장 늦은 시간입니다.

AWS Command Line Interface(AWS CLI) 명령 describe-db-instances를 사용하여 인스턴스의 복원 가능한 최근 시간을 반환할 수 있습니다. 복원 가능 최근 시간은 일반적으로 최근 5분 내입니다. Amazon RDS 콘솔에서 [자동 백업]을 선택하여 복원 가능한 최근 시간을 확인할 수도 있습니다.

DB 인스턴스의 특정 시점 복원을 시작하면 Amazon RDS가 사용자를 대신하여 RestoreDBInstanceToPointInTime API를 호출합니다. 이 API는 AWS CloudTrail에서 추적됩니다. 자세한 내용은 CloudTrail 콘솔에서 CloudTrail 이벤트 보기를 참조하세요.

RDS 로그 파일을 검토하여 특정 시점 복원의 진행률을 확인할 수도 있습니다. 백업에서 RDS 인스턴스를 복원한 후 RDS 로그 파일을 사용하여 복구 진행률을 추적할 수 있습니다.

RDS는 DB 인스턴스에 대한 트랜잭션 로그를 5분마다 Amazon Simple Storage Service(S3)에 업로드합니다. 특정 시간 복원 중에는 특정 시점으로 언급된 시간에 가장 가까운 스냅샷이 먼저 복원됩니다. 그런 다음 트랜잭션 로그는 특정 시점 복원을 시작할 때 언급한 시간까지 적용됩니다. 이 작업은 적용해야 하는 트랜잭션 로그 수에 따라 더 오래 걸릴 수 있습니다.

예를 들어, 오늘 04:00 UTC에 DB 인스턴스의 자동 백업을 수행하고 06:15 UTC에 특정 시점 복원을 수행해야 한다고 가정해 보겠습니다. 이 경우 04:00 UTC에 생성된 백업에서 인스턴스가 복원됩니다. 그런 다음 06:16 UTC까지의 트랜잭션 로그가 복원된 인스턴스에 적용되어 특정 시점 복원 프로세스를 완료합니다.

해결 방법

다음 모범 사례를 사용하여 DB 인스턴스를 특정 시점으로 복원하는 데 걸리는 시간을 줄일 수 있습니다.

• 소스 인스턴스에서 자동 백업을 활성화한 경우 정기적으로 수동 스냅샷을 생성하여 많은 델타 변경이 쌓이는 것을 방지하고 복구 시점 목표를 줄이는 것이 좋습니다.
• 특정 시점 복원 시 소스 데이터베이스에서 오래 실행되는 쿼리가 실행되고 있지 않은지 확인합니다. 트랜잭션이 오래 실행되면 복구 시간이 늘어날 수 있습니다. 즉, 데이터베이스를 사용할 수 있게 되는 데 시간이 더 오래 걸릴 수 있습니다.
• 가능하면 올바른 트랜잭션 로그 크기를 사용합니다. 대규모 트랜잭션은 한 번에 트랜잭션 파일에 기록되며 서로 다른 파일로 분할되지 않습니다. 따라서 트랜잭션 로그 파일이 필요 이상으로 커지므로 충돌 복구 시간이 늘어납니다.
• 특정 시점 복원 중에 인스턴스의 스냅샷이 복원된 후 S3에 있는 스냅샷의 데이터가 기본 Amazon Elastic Block Store(Amazon EBS) 볼륨으로 복사됩니다. 이 프로세스를 지연 로딩이라고 합니다. 아직 복사되지 않은 블록에 액세스하려고 하면 RDS가 S3에서 해당 블록을 가져오므로 I/O 지연 시간이 발생합니다. 빠른 액세스가 필요한 테이블에 대한 지연 로딩의 영향을 완화하기 위해 SELECT*와 같이 전체 테이블 스캔을 포함하는 작업을 수행할 수 있습니다. 이렇게 하면 Amazon RDS가 S3에서 백업된 모든 테이블 데이터를 다운로드할 수 있습니다.

예:

RDS for PostgreSQL DB 인스턴스를 특정 시점으로 복원할 때 로그 파일에 다음 정보가 표시될 수 있습니다.

2022-06-01 13:16:19 UTC::@:[8613]:LOG: starting point-in-time recovery to 2022-06-01 12:54:30+00
2022-06-01 13:16:19 UTC::@:[8613]:LOG: redo starts at 0/48A3220
waiting for 000000010000000000000001 archive /rdsdbdata/log/restore/pg-wal-archive.1.* to be downloaded
2022-06-01 13:17:22 UTC:127.0.0.1(46110):rdsadmin@rdsadmin:[10322]:FATAL: the database system is starting up
2022-06-01 13:17:25 UTC::@:[8613]:LOG: restored log file "000000010000000000000001" from archive
recovering 000000010000000000000002
2022-06-01 13:17:26 UTC::@:[8613]:LOG: restored log file "000000010000000000000002" from archive
recovering 000000010000000000000003
2022-06-01 13:17:28 UTC::@:[8613]:LOG: restored log file "000000010000000000000003" from archive
recovering 000000010000000000000004
2022-06-01 13:18:54 UTC::@:[8613]:LOG: restored log file "000000010000000000000022" from archive
recovering 000000010000000000000023
.
.
2022-06-01 13:33:16 UTC::@:[8613]:LOG: restored log file "00000001000000060000000B" from archive
2022-06-01 13:33:16 UTC::@:[8613]:LOG: recovery stopping before commit of transaction 9266438, time 2022-06-01 12:56:14.648042+00
2022-06-01 13:33:16 UTC::@:[8613]:LOG: redo done at 6/2C0003C0
2022-06-01 13:33:16 UTC::@:[8613]:LOG: last completed transaction was at log time 2022-06-01 12:51:14.646151+00
recovering 00000002.history
2022-06-01 13:33:16 UTC::@:[8613]:LOG: selected new timeline ID: 2
2022-06-01 13:33:16 UTC::@:[8613]:LOG: archive recovery complete
recovering 00000001.history
2022-06-01 13:33:16 UTC::@:[8620]:LOG: checkpoint starting: end-of-recovery immediate wait
2022-06-01 13:33:16 UTC::@:[8620]:LOG: checkpoint complete: wrote 2 buffers (0.0%); 0 WAL file(s) added, 0 removed, 8 recycled; write=0.002 s, sync=0.003 s, total=0.031 s; sync files=2, longest=0.003 s, average=0.002 s; distance=655360 kB, estimate=1611806 
kB
2022-06-01 13:33:16 UTC::@:[8607]:LOG: database system is ready to accept connections
2022-06-01 13:37:18 UTC::@:[8607]:LOG: received fast shutdown request
2022-06-01 13:37:18 UTC::@:[8607]:LOG: aborting any active transactions
2022-06-01 13:37:18 UTC::@:[8607]:LOG: background worker "logical replication launcher" (PID 7394) exited with exit code 1
2022-06-01 13:37:18 UTC::@:[8620]:LOG: shutting down
2022-06-01 13:37:18 UTC::@:[8620]:LOG: checkpoint starting: shutdown immediate
2022-06-01 13:37:18 UTC::@:[8620]:LOG: checkpoint complete: wrote 9 buffers (0.0%); 0 WAL file(s) added, 0 removed, 1 recycled; write=0.003 s, sync=0.003 s, total=0.024 s; sync files=7, longest=0.003 s, average=0.001 s; distance=65535 kB, estimate=1457179
        kB
2022-06-01 13:37:20 UTC::@:[8607]:LOG: database system is shut down
2022-06-01 13:37:24 UTC::@:[10870]:LOG: starting PostgreSQL 13.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-12), 64-bit
2022-06-01 13:37:24 UTC::@:[10870]:LOG: listening on IPv4 address "0.0.0.0", port 5432
2022-06-01 13:37:24 UTC::@:[10870]:LOG: listening on IPv6 address "::", port 5432
2022-06-01 13:37:24 UTC::@:[10870]:LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
2022-06-01 13:37:24 UTC::@:[10875]:LOG: database system was shut down at 2022-06-01 13:37:18 UTC
2022-06-01 13:37:24 UTC::@:[10870]:LOG: database system is ready to accept connections

---

관련 정보

DB 스냅샷에서 복원

Amazon EBS 스냅샷

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

Amazon RDS를 사용하여 재해 복구 전략 구현