Läuft pg_dump auf einem Hot Standby Server?

Haftungsausschluss: Ich habe das zwar noch nicht ausprobiert, bin mir aber nicht sicher, ob es nicht richtig funktioniert, also wollte ich fragen.

Ich möchte einen nächtlichen Sicherungsjob (über pg_dumpall) von einem Hot-Standby-Server ausführen , auf dem die Streaming-Replikation ausgeführt wird, um zu vermeiden, dass diese Last auf die Primärdatenbank geladen wird. Ich habe nur die Erwähnung einiger Fallstricke gesehen, auf die Leute gestoßen sind, z. B. hier und hier , aber nur sehr wenig Anleitung. Es ist in Ordnung, wenn das Backup etwas hinter dem primären Backup zurückbleibt, solange es konsistent ist (was es auch sein sollte).

Meine Fragen sind:

1. Möchte ich das wirklich tun, oder sollte die Sicherung auf dem Primärserver erfolgen? Warum?

2. Welche Einstellungen und Verfahren benötige ich, um einen Dump im Standby-Modus durchzuführen? Muss ich zB die Replikation für die Dauer des Backups stoppen?

AFAIK, in pg_dumpeinem Hot-Standby-Modus zu arbeiten, ist eines der wichtigsten Dinge, für die Standbys nützlich sind. Es ist absolut sicher, auch wenn es nicht absolut zuverlässig ist - die Speicherauszüge können fehlschlagen, wenn der Standby-Modus die Transaktion abbricht, wenn sie zu weit hinter dem Master zurückbleibt.

Das einzige, was Sie wirklich sehen müssen, ist sicherzustellen, dass der Standby-Modus auf dem neuesten Stand ist und Schritt hält. Wenn das Standby die Verbindung zum Master verliert und zu weit zurückfällt, möchten Sie kein lustiges Backup für ein dreiwöchiges veraltetes Standby erstellen.

Sie müssen zulassen, dass der Standby-Modus während des Backups weit hinter dem Master zurückbleibt, da er sonst Ihre pg_dumpTransaktion abbrechen muss, um die WAL-Wiedergabe fortzusetzen. Weitere Informationen finden Sie in der Dokumentation zu Hot Standby , insbesondere im Abschnitt "Behandeln von Abfragekonflikten" sowie in den Parametern max_standby_archive_delayund max_standby_streaming_delay.

Beachten Sie, dass der Master bereit sein muss, genügend WAL-Archive zu führen, damit der Slave wieder aufholen kann.

1. Wir machen Backups im Standby, es ist vollkommen in Ordnung.
2. Um einen Konflikt mit abgebrochenen Anweisungen während der Sicherung im Standby-System zu vermeiden, müssen Sie die Replikation im Standby-Modus unterbrechen SELECT pg_xlog_replay_pause();und anschließend die Sicherung ausführen SELECT pg_xlog_replay_resume();, um die Replikation fortzusetzen. Beachten Sie, dass das Ausführen der obigen Befehle zu einer Verzögerung bei der Wiederherstellung des Slaves führt, die abhängig von der Größe Ihrer Datenbank sehr groß sein kann. Berücksichtigen Sie auch den Platz, den WAL-Segmente einnehmen, da sie während der Pause nicht auf dem Slave abgespielt werden.

Weitere nützliche Verwaltungsfunktionen finden Sie möglicherweise in der Dokumentation . Zum Beispiel überprüfen , ob der Server tatsächlich in der Genesung ist, bevor es zu pausieren: SELECT pg_is_in_recovery().

Wenn Sie die Replikation während der Sicherung anhalten (dies ist eine gute Idee, um die Integrität und Konsistenz zu erhalten), können Sie einige Zeilen in Ihrem Master-Postgresql bearbeiten:

Wie viel Zeit verzögert Ihr Backup gewöhnlich? Stellen Sie sicher, dass der Masterknoten die gesamten x_log-Dateien beibehält, die zum Fortsetzen der Replikation erforderlich sind. Sie können dies in der postgresql.conf-Bearbeitung tun

wal_keep_segments = 32      # in logfile segments, 16MB each; 0 disables

Wenn Sie dies nicht ändern und Ihr Sicherungsvorgang zu lang ist, löscht der Masterknoten wahrscheinlich die xlog-Dateien, bevor er sie an den Slave sendet.