Amazon RDS DB インスタンスのポイントインタイム復元に時間がかかるのはなぜですか？

簡単な説明

[Restore to point in time] (特定の時点に復元) オプションを使用すると、自動バックアップを有効にしている特定の時点に DB インスタンスを復元できます。 自動バックアップが有効になっている Amazon RDS インスタンスは、最も早い復元可能時刻まで復元できます。最も早い復元可能時刻は、バックアップ保持期間の範囲で遡ることができるインスタンスの復元可能時刻を指定します。最大保存期間は 35 日、つまり 5 暦週に設定されています。インスタンスを変更して、この値を 0 日から 35 日に変更できます。ポイントインタイムリストアを開始し、保持期間内の任意の日時から最新の復元可能時刻までを指定できます。最新の復元可能時刻は、インスタンスを復元できる最も近い時刻です。

AWS コマンドラインインターフェイス (AWS CLI) のコマンド describe-db-instances を使用して、インスタンスを復元可能な最も近い時刻に戻すことができます。最新の復元可能時刻は、通常、直近 5 分以内です。Amazon RDS コンソールで [自動バックアップ] を選択して、最新の復元可能時刻を確認することもできます。

DB インスタンスのポイントインタイム復元を開始すると、Amazon RDS がユーザーに代わり RestoreDBInstanceToPointInTime API を呼び出します。この API は AWS CloudTrail で追跡されます。詳細については、「CloudTrail コンソールでの CloudTrail イベントを表示する」を参照してください。

RDS ログファイルを確認して、ポイントインタイム復元の進行状況をチェックすることもできます。RDS インスタンスがバックアップから復元された後に、RDS ログファイルを使用して回復の進行状況を追跡できます。

RDS は、5 分ごとにDB インスタンスのトランザクションログを Amazon Simple Storage Service (Amazon S3) にアップロードします。ポイントインタイム復元では、ポイントインタイムで指定した時刻に最も近いスナップショットが最初に復元されます。次に、ポイントインリストアを開始したときに指定した時刻まで、トランザクションログが適用されます。適用が必要なトランザクションログの数によって、このオペレーションは時間がかかる場合があります。

例えば、今日 04:00 UTC に行った DB インスタンスの自動バックアップがあり、06:15 UTC にポイントインタイム復元を実行する必要があるとします。この場合、インスタンスは 04:00 UTC に作成されたバックアップから復元されます。次に、06:16 UTC までのトランザクションログが復元されたインスタンスに適用され、ポイントインタイム復元のプロセスが完了します。

解決方法

次のベストプラクティスを使用して、DB インスタンスを特定の時点に復元するのにかかる時間を短縮します。

• ソースインスタンスで自動バックアップを有効にした場合、定期的に手動でスナップショットをとって多数のデルタ変更が積み重ならないようにし、リカバリポイントの目標を下げることをお勧めします。
• ポイントインタイム復元の時点で、ソースデータベースで長時間実行しているクエリがないようにしてください。 トランザクションが長時間実行されると、リカバリ時間が長くなる可能性があります。つまり、データベースが使用可能になるまでに時間がかかることがあります。
• 可能な限り、正しいトランザクションのログサイズを使用してください。大きなトランザクションは一度にトランザクションファイルに書き込まれ、異なるファイルに分割されません。したがって、トランザクションログファイルが必要以上に大きくなり、クラッシュリカバリ時間が長くなります。
• ポイントインタイム復元では、S3 にあるスナップショットからのデータが、インスタンスのスナップショットが復元された後で、基盤となる Amazon Elastic Block Store (Amazon EBS) ボリュームにコピーされます。このプロセスは「lazy loading (遅延読み込み) 」として知られています。まだコピーされていないブロックにアクセスしようとすると、RDS はそのブロックを S3 からプルするため、I/O 遅延が発生します。すばやくアクセスする必要があるテーブルへの遅延読み込みの影響を少なくするために、**[SELECT**]**などのフルテーブルスキャンを含む操作を実行できます。 これにより、Amazon RDS がバックアップされたすべてのテーブルデータを S3 からダウンロードすることができます。

例:

PostgreSQL DB インスタンスのRDSを特定の時点に復元すると、ログファイルに次の情報が表示される場合があります。

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 でディザスタリカバリ戦略を実装する