為什麼我的 Amazon RDS 資料庫執行個體執行時點還原需要很長時間？

解決方法

從備份還原 RDS DB 執行個體後，請檢視 Amazon RDS 日誌檔案，以追蹤時點還原的進度。

Amazon RDS 每 5 分鐘會將資料庫執行個體的交易日誌上傳到 Amazon Simple Storage Service (Amazon S3)。在執行時點還原期間，系統會優先還原最接近您所設定時間點的快照。然後，Amazon RDS 會套用交易日誌，直到您所設定的時間點為止。作業的長度取決於交易日誌的數量。

例如，您必須在 06:15 UTC 對同一天 04:00 UTC 進行的資料庫執行個體自動備份執行時點還原。在此範例中，執行個體會從 04:00 UTC 建立的備份進行還原。接著，Amazon RDS 會將交易日誌套用到還原的執行個體，直到 06:15 UTC，以完成時點還原程序。

若要減少將資料庫執行個體還原到特定時間所需的時間，請採用下列最佳做法：

• 定期手動拍攝快照，以減少已啟用自動備份的來源執行個體的還原點目標。
• 確保來源資料庫在執行時點還原時，沒有正在執行的長時間查詢。長時間執行的交易可能會增加復原時間，並導致資料庫無法使用的時間延長。
• 檢查您的交易日誌大小。大型交易會一次性寫入交易檔案，且 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 資料庫執行個體還原到特定時間點時，您會在日誌檔案中收到相關資訊。

輸出範例：

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 資料庫叢集複製、快照還原或時點還原需要這麼長時間？