Warum dauert die Point-in-Time-Wiederherstellung meiner Amazon-RDS-DB-Instance sehr lange?
Ich führe eine Point-in-Time-Wiederherstellung meiner Amazon-Relational-Database-Service-DB-Instance (Amazon RDS) durch. Dieser Vorgang dauert 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
Implementieren einer Notfallwiederherstellungsstrategie mit Amazon RDS

Relevanter Inhalt
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 9 Monaten
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 3 Jahren