pg_rewind - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

pg_rewind - Synchronisiere ein PostgreSQL-Datenverzeichnis mit einem anderen Datenverzeichnis, das
gegabelt vom ersten

ZUSAMMENFASSUNG

pg_rewind [zu erhalten...] {-D | --target-pgdata} Verzeichnis {--source-pgdata=Verzeichnis |
--source-server=connstr}

BESCHREIBUNG

pg_rewind ist ein Tool zum Synchronisieren eines PostgreSQL-Clusters mit einer anderen Kopie desselben
Cluster, nachdem die Zeitachsen der Cluster auseinandergegangen sind. Ein typisches Szenario ist, ein
alter Master-Server nach einem Failover wieder online, als Standby, der dem neuen Master folgt.

Das Ergebnis entspricht dem Ersetzen des Zieldatenverzeichnisses durch das Quellverzeichnis. Alle
Dateien kopiert werden, einschließlich Konfigurationsdateien. Der Vorteil von pg_rewind gegenüber dem Nehmen von a
neues Basis-Backup oder Tools wie rsync ist, dass pg_rewind kein Durchlesen erfordert
alle unveränderten Dateien im Cluster. Das macht es viel schneller, wenn die Datenbank groß ist
und nur ein kleiner Teil davon unterscheidet sich zwischen den Clustern.

pg_rewind untersucht die Zeitachsenverläufe der Quell- und Zielcluster, um zu bestimmen
den Punkt, an dem sie divergiert haben, und erwartet, WAL im pg_xlog . des Zielclusters zu finden
Verzeichnis, das bis zum Punkt der Divergenz zurückreicht. Im typischen Failover
Szenario, in dem der Zielcluster kurz nach der Divergenz heruntergefahren wurde, d. h
Problem, aber wenn der Zielcluster lange Zeit nach der Divergenz gelaufen war, wurde der alte
WAL-Dateien sind möglicherweise nicht mehr vorhanden. In diesem Fall können sie manuell aus dem
WAL-Archiv in das Verzeichnis pg_xlog. Abrufen fehlender Dateien aus einem WAL-Archiv
automatisch wird derzeit nicht unterstützt.

Wenn der Zielserver zum ersten Mal nach dem Ausführen von pg_rewind gestartet wird, wird er
Gehen Sie in den Wiederherstellungsmodus und geben Sie alle WAL wieder, die auf dem Quellserver nach dem Zeitpunkt generiert wurden
Abweichungen. Wenn ein Teil der WAL auf dem Quellserver nicht mehr verfügbar war, als pg_rewind
ausgeführt wurde und daher nicht von der pg_rewind-Sitzung kopiert werden konnte, muss es erstellt werden
verfügbar, wenn der Zielserver gestartet wird. Dies kann durch Erstellen von a
recovery.conf-Datei im Zieldatenverzeichnis mit einem geeigneten Wiederherstellungsbefehl.

pg_rewind erfordert, dass auf dem Zielserver entweder die Option wal_log_hints aktiviert ist
in postgresql.conf oder dass Datenprüfsummen aktiviert wurden, als der Cluster initialisiert wurde
mit initdb. Keines davon ist derzeit standardmäßig aktiviert. full_page_writes muss auch sein
aktiviert. Das ist die Vorgabe.

OPTIONAL

pg_rewind akzeptiert die folgenden Befehlszeilenargumente:

-D Verzeichnis
--target-pgdata=Verzeichnis
Diese Option gibt das Zieldatenverzeichnis an, das mit der Quelle synchronisiert wird.
Der Zielserver muss sauber heruntergefahren werden, bevor pg_rewind ausgeführt wird

--source-pgdata=Verzeichnis
Gibt den Pfad zum Datenverzeichnis des Quellservers an, um das Ziel zu synchronisieren
mit. Wann --source-pgdata verwendet wird, muss der Quellserver sauber heruntergefahren werden.

--source-server=connstr
Gibt eine libpq-Verbindungszeichenfolge für die Verbindung mit dem PostgreSQL-Quellserver an
Synchronisieren Sie das Ziel mit. Die Verbindung muss eine normale (keine Replikation) sein.
Verbindung mit Superuser-Zugriff. Der Server muss betriebsbereit sein und darf nicht
im Wiederherstellungsmodus.

-n
--Probelauf
Tun Sie alles, außer das Zielverzeichnis tatsächlich zu ändern.

-P
--Fortschritt
Aktiviert Fortschrittsberichte. Wenn Sie dies aktivieren, erhalten Sie einen ungefähren Fortschritt
Bericht beim Kopieren von Daten aus dem Quellcluster.

--debuggen
Ausgabe einer ausführlichen Debugging-Ausgabe, die vor allem für das Debugging von Entwicklern nützlich ist
pg_rewind.

-V
--Version
Versionsinformationen anzeigen, dann beenden.

-?
--help
Hilfe anzeigen, dann beenden.

Wann --source-server Option verwendet wird, verwendet pg_rewind auch die Umgebungsvariablen
unterstützt von libpq (siehe Abschnitt 31.14, „Umgebungsvariablen“, in der Dokumentation).

ANMERKUNG

Wie it PayDay
Die Grundidee besteht darin, alles aus dem neuen Cluster in den alten Cluster zu kopieren, außer
die Blöcke, von denen wir wissen, dass sie gleich sind.

1. Scannen Sie das WAL-Protokoll des alten Clusters, beginnend mit dem letzten Prüfpunkt vor dem
Punkt, an dem der Zeitachsenverlauf des neuen Clusters vom alten Cluster abgezweigt wurde. Zum
Notieren Sie sich bei jedem WAL-Datensatz die berührten Datenblöcke. Dies ergibt eine Liste
aller Datenblöcke, die im alten Cluster geändert wurden, nach dem neuen Cluster
abgezweigt.

2. Kopieren Sie alle geänderten Blöcke aus dem neuen Cluster in den alten Cluster.

3. Kopieren Sie alle anderen Dateien wie clog- und Konfigurationsdateien vom neuen Cluster in den
alter Cluster, alles außer den Relationsdateien.

4. Wenden Sie die WAL vom neuen Cluster an, beginnend mit dem Prüfpunkt, der beim Failover erstellt wurde.
(Streng genommen wendet pg_rewind die WAL nicht an, sondern erstellt nur ein Backup-Label
Datei, die angibt, dass beim Starten von PostgreSQL die Wiedergabe von dieser aus gestartet wird
Checkpoint und wenden Sie alle erforderlichen WAL an.)

Verwenden Sie pg_rewind online mit den onworks.net-Diensten