Warum dauert die Point-in-Time-Wiederherstellung meiner Amazon-RDS-DB-Instance so lange?

Lösung

Nachdem du die RDS-DB-Instance aus dem Backup wiederhergestellt hast, sieh dir die Amazon RDS-Protokolldateien an, um den Fortschritt deiner Point-in-Time-Wiederherstellung zu verfolgen.

Amazon RDS lädt alle 5 Minuten Transaktionsprotokolle für DB-Instances auf Amazon Simple Storage Service (Amazon S3) hoch. Bei einer Point-in-Time-Wiederherstellung wird der Snapshot, der dem Zeitpunkt, den du für den Zeitpunkt festgelegt hast, am nächsten kommt, zuerst wiederhergestellt. Anschließend wendet Amazon RDS die Transaktionsprotokolle bis zu dem von dir festgelegten Zeitpunkt an. Die Länge des Vorgangs basiert auf der Anzahl der Transaktionsprotokolle.

Beispielsweise musst du eine Point-in-Time-Wiederherstellung um 06:15 Uhr UTC für ein automatisiertes Backup einer DB-Instance durchführen, das am selben Tag um 04:00 Uhr UTC erstellt wurde. In diesem Beispiel wird die Instance anhand des Backups wiederhergestellt, das um 04:00 Uhr UTC erstellt wurde. Anschließend wendet Amazon RDS die Transaktionsprotokolle bis 06:15 Uhr UTC auf die wiederhergestellte Instance an, um den Point-in-Time-Wiederherstellungsvorgang abzuschließen.

Verwende die folgenden Best Practices, um die Zeit zu reduzieren, die für die Wiederherstellung deiner DB-Instance auf einen bestimmten Zeitpunkt benötigt wird:

• Erstelle regelmäßig manuelle Snapshots, um das Recovery-Point-Objective für Quell-Instances zu verringern, für die automatische Backups aktiviert sind.
• Stelle sicher, dass in der Quelldatenbank zum Zeitpunkt der Point-in-Time-Wiederherstellung keine Abfragen mit langer Laufzeit verarbeitet werden. Lange Transaktionen können die Wiederherstellungszeit verlängern und dazu führen, dass die Datenbank länger nicht verfügbar ist.
• Überprüfe die Größe deines Transaktionsprotokolls. Große Transaktionen schreiben gleichzeitig in die Transaktionsdatei und Amazon RDS teilt die Transaktionen nicht auf verschiedene Dateien auf.
  Hinweis: Große Transaktionsprotokolldateien verlängern die Wiederherstellungszeit nach einem Absturz.
• Führe für jede Tabelle einen vollständigen Tabellenscan durch, z. B. SELECT *, um den Zugriff auf wichtige Tabellen nach einer Wiederherstellung zu beschleunigen. Dies veranlasst Amazon RDS, alle Tabellendaten von Amazon S3 auf das Amazon Elastic Block Store (Amazon EBS)-Volume herunterzuladen.
  Hinweis: Wenn du nicht alle Tabellendaten herunterlädst, sondern versuchst, auf einen EBS-Block zuzugreifen, kann es zu verzögertem Laden kommen. Nach der Wiederherstellung des Snapshots deiner Instance werden Daten aus dem Snapshot, der sich in Amazon S3 befindet, in das EBS-Volume kopiert. Wenn du versuchst, auf einen Block zuzugreifen, der noch nicht kopiert wurde, ruft Amazon RDS diesen Block aus Amazon S3 ab, woraufhin sich die I/O-Latenz ergibt.

Wenn du eine Amazon RDS für PostgreSQL-DB-Instance zu einem bestimmten Zeitpunkt wiederherstellst, erhältst du Informationen in deiner Protokolldatei.

Beispielausgabe:

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

Ähnliche Informationen

Amazon-EBS-Snapshots

Warum dauert mein Amazon-Aurora-DB-Cluster-Klon-, meine Snapshot- oder meine Point-in-Time-Wiederherstellung so lange?