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

Kurzbeschreibung

Mit der Option Wiederherstellen zu einem bestimmten Zeitpunkt kannst du eine DB-Instance zu einem bestimmten Zeitpunkt wiederherstellen, wenn du automatische Backups aktiviert hast. Amazon RDS-Instances, bei denen automatische Backups aktiviert sind, können bis zum frühesten wiederherstellbaren Zeitpunkt wiederhergestellt werden. Die früheste wiederherstellbare Zeit gibt an, wie weit du innerhalb des Backup-Aufbewahrungszeitraums deine Instance wiederherstellen kannst. Die maximale Aufbewahrungsfrist ist auf 35 Tage festgelegt, was fünf Kalenderwochen entspricht. Du kannst diesen Wert von 0 auf 35 Tage ändern, indem du die Instance änderst. Du kannst eine Wiederherstellung zu jedem beliebigen Datum und jeder beliebigen Uhrzeit innerhalb deines Wiederherstellungszeitraums bis zum letztmöglichen Zeitpunkt initiieren. Die letzte wiederherstellbare Zeit ist die letzte Zeit, von der aus du die Instanz wiederherstellen kannst.

Du kannst den AWS-Command-Line-Interface-Befehl (AWS CLI) describe-db-instances verwenden, um die letzte wiederherstellbare Zeit für deine Instance zurückzugeben. Die letzte wiederherstellbare Zeit liegt normalerweise innerhalb der letzten fünf Minuten. Du kannst den letzten wiederherstellbaren Zeitpunkt auch ermitteln, indem du in der Amazon-RDS-Konsole die Option Automatisierte Sicherungen auswählst.

Wenn du eine Point-in-Time-Wiederherstellung für deine DB-Instance initiierst, ruft Amazon RDS in deinem Namen die RestoredBinstanceToPointInTime-API auf. Diese API wird in AWS CloudTrail nachverfolgt. Weitere Informationen findest du unter Anzeigen von CloudTrail-Ereignissen in der CloudTrail-Konsole.

Du kannst den Fortschritt der Point-in-Time-Wiederherstellung auch überprüfen, indem du die RDS-Protokolldateien überprüfst. Nachdem die RDS-Instance aus der Sicherung wiederhergestellt wurde, kannst du die RDS-Protokolldateien verwenden, um den Wiederherstellungsfortschritt zu verfolgen.

RDS lädt alle fünf Minuten Transaktionsprotokolle für DB-Instances auf Amazon Simple Storage Service (Amazon S3) hoch. Bei einer Point-in-Time-Wiederherstellung wird zuerst der Snapshot wiederhergestellt, der der in Point-in-Time genannten Zeit am nächsten liegt. Anschließend werden die Transaktionsprotokolle bis zu dem Zeitpunkt angewendet, den du beim Initiieren der Point-in-Wiederherstellung angegeben hast. Dieser Vorgang kann länger dauern, abhängig von der Anzahl der Transaktionslogs, die angewendet werden müssen.

Angenommen, du hast die automatische Sicherung einer DB-Instance heute um 04:00 Uhr UTC durchgeführt und musst um 06:15 UTC eine Point-in-Time-Wiederherstellung durchführen. In diesem Fall wird die Instance aus der Sicherung wiederhergestellt, die um 04:00 UTC erstellt wurde. Anschließend werden die Transaktionsprotokolle bis 06:16 UTC auf die wiederhergestellte Instance angewendet, um den Point-in-Time-Wiederherstellungsprozess abzuschließen.

Lösung

Verwende die folgenden Bewährten Methoden um den Zeitaufwand für die Wiederherstellung deiner DB-Instance auf einen bestimmten Zeitpunkt zu reduzieren:

• Wenn Sie automatische Backups auf deinen Quellinstanzen aktiviert hast, solltest du in regelmäßigen Abständen manuelle Snapshots erstellen, um zu verhindern, dass sich eine große Anzahl von Delta-Änderungen anhäuft und das Ziel des Wiederherstellungspunkts verringert.
• Stelle sicher, dass zum Zeitpunkt der Point-in-Time-Wiederherstellung keine lang andauernden Abfragen in der Quelldatenbank ausgeführt werden. Langfristige Transaktionen können die Wiederherstellungszeit verlängern, was bedeutet, dass es länger dauern kann, bis die Datenbank verfügbar ist.
• Verwende nach Möglichkeit die richtige Transaktionsloggröße. Große Transaktionen werden gleichzeitig in die Transaktionsdatei geschrieben und nicht auf verschiedene Dateien aufgeteilt. Daher wird die Transaktionsprotokolldatei größer als nötig, was die Wiederherstellungszeit für Abstürze verlängert.
• Während der Point-in-Time-Wiederherstellung, nachdem der Snapshot Ihrer Instance wiederhergestellt wurde, werden die Daten aus dem Snapshot, der sich in S3 befindet, in das zugrunde liegende Amazon-Elastic-Block-Store-Volume (Amazon EBS) kopiert. Dieser Vorgang wird als Lazy Loading bezeichnet. Wenn du versuchst, auf einen Block zuzugreifen, der noch nicht kopiert wurde, ruft RDS diesen Block aus S3 ab, was zu einer I/O-Latenz führt. Um die Auswirkungen des verzögerten Ladens auf Tabellen, auf die du schnellen Zugriff benötigst, zu minimieren, kannst du Vorgänge ausführen, die Scans vollständiger Tabellen beinhalten, wie AUSWÄHLEN*. Dadurch kann Amazon RDS alle gesicherten Tabellendaten von S3 herunterladen.

Beispiel:

Möglicherweise werden die folgenden Informationen in einer Protokolldatei angezeigt, wenn du deine RDS for PostgreSQL-DB-Instance zu einem bestimmten Zeitpunkt wiederherstellst:

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

Relevante Informationen

Wiederherstellen aus einem DB-Snapshot

Amazon-EBS-Snapshots

Warum dauert der Klon meines Amazon-Aurora-DB-Clusters, die Wiederherstellung von Snapshots oder die Wiederherstellung zu einem bestimmten Zeitpunkt so lange?

Implementieren einer Notfallwiederherstellungsstrategie mit Amazon RDS