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

해결 방법

백업에서 RDS DB 인스턴스를 복원한 후 Amazon RDS 로그 파일을 보고 특정 시점 복원의 진행 상황을 추적합니다.

Amazon RDS는 DB 인스턴스의 트랜잭션 로그를 5분마다 Amazon Simple Storage Service(Amazon S3)에 업로드합니다. 특정 시점 복원 중에는 특정 시점 복원에서 설정한 시간에 가장 가까운 스냅샷이 먼저 복원됩니다. 그런 다음 Amazon RDS는 설정한 특정 시점까지 트랜잭션 로그를 적용합니다. 작업 길이는 트랜잭션 로그 수를 기반으로 합니다.

예를 들어, 같은 날 04:00 UTC에 생성된 DB 인스턴스의 자동 백업을 위해 06:15 UTC에 특정 시점 복원을 수행해야 합니다. 이 예시에서는 04:00 UTC에 생성된 백업에서 인스턴스를 복원합니다. 그런 다음 Amazon RDS는 복원된 인스턴스에 06:15 UTC까지의 트랜잭션 로그를 적용하여 특정 시점 복원 프로세스를 완료합니다.

DB 인스턴스를 특정 시간으로 복원하는 데 걸리는 시간을 줄이려면 다음 모범 사례를 사용하십시오.

• 수동 스냅샷을 정기적으로 생성하여 자동 백업이 활성화된 소스 인스턴스의 복구 시점 목표를 줄이십시오.
• 특정 시점 복원 시 소스 데이터베이스에 장기 실행 쿼리가 포함되어 있지 않아야 합니다. 트랜잭션이 오래 실행되면 복구 시간이 길어지면서 데이터베이스를 더 오래 사용할 수 없게 될 수 있습니다.
• 트랜잭션 로그 크기를 확인하십시오. 대규모 트랜잭션은 한 번에 트랜잭션 파일에 기록되고, Amazon RDS는 트랜잭션을 서로 다른 파일로 분할하지 않습니다.
  참고: 트랜잭션 로그 파일이 크면 충돌 복구 시간이 길어집니다.
• 각 테이블에서 SELECT *와 같은 전체 테이블 스캔을 실행하면 복구 후 중요 테이블에 빠르게 액세스할 수 있습니다. 그러면 Amazon RDS는 Amazon S3의 모든 테이블 데이터를 Amazon Elastic Block Store(Amazon EBS) 볼륨으로 다운로드합니다.
  참고: 테이블 데이터를 모두 다운로드하지 않은 채 EBS 블록에 액세스하려고 하면 지연 로딩이 발생할 수 있습니다. 인스턴스 스냅샷 복원 이후 Amazon S3에 있는 스냅샷의 데이터가 EBS 볼륨으로 복사됩니다. 아직 복사되지 않은 블록에 액세스하려고 하면 Amazon RDS가 Amazon S3에서 해당 블록을 가져오고, 이로 인해 I/O 지연 시간이 발생합니다.

Amazon 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+002022-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

관련 정보

Amazon EBS 스냅샷

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