Wir machen uns weiterhin mit dem Tool pg_probackup vertraut .
Im ersten Teil haben wir pg_probackup installiert, eine Instanz erstellt und konfiguriert, zwei Sicherungen durchgeführt - vollständig und inkrementell im DELTA-Modus - und gelernt, wie die Instanzkonfiguration angezeigt und geändert wird. Wir haben eine Liste der Sicherungen erhalten, ein Skript (bkp_base.sh) geschrieben, das den Cluster sichert und die Ergebnisse der letzten Sicherungsoperation an das Überwachungssystem sendet. Heute werden wir nicht weniger interessante Aufgaben angehen.
Problem 2
Gegeben: Wir haben zwei Server, auf dem ersten haben wir unsere Datenbank (Hostname srv_db1, Benutzer postgres) und auf dem zweiten speichern wir Backups (Hostname srv_bkp, Benutzer backup_user). Zusätzlich zu den Sicherungen auf demselben Server speichern wir Kopien der Protokolle vor der Aufzeichnung, um sie innerhalb der letzten 3 Tage zu einem beliebigen Zeitpunkt (Wiederherstellung zu einem bestimmten Zeitpunkt) wiederherstellen zu können.
Lösung:
Um zum ausgewählten Zeitpunkt (Wiederherstellungspunkt) wiederherstellen zu können, müssen vor dem Wiederherstellungspunkt eine Sicherung sowie alle WAL-Dateien ab dem Zeitpunkt der Sicherung bis zum Wiederherstellungspunkt erstellt werden.
Wir haben bereits Backups, es bleibt die Konfiguration der WAL-Archivierung auf srv_bkp.
Stellen Sie mit dem Benutzer postgres eine Verbindung zu srv_db1 her und führen Sie die folgenden Befehle aus:
ssh-keygen -t rsa
ssh-copy-id backup_user@srv_bkpÄndern wir die Datei ~ / .ssh / autorized_keys in srv_bkp:
command="pg_probackup-12 agent" ssh-rsa AAAA....Zurück zu srv_db1 müssen Sie den Archivierungsmodus (archive_mode) aktivieren und den Parameter archive_command konfigurieren. Es enthält einen Befehl zum Sichern eines vollständigen WAL-Segments.
psql -c 'show archive_mode'Wenn es wieder ausgeschaltet ist, wechseln Sie zu Ein
psql -c 'alter system set archive_mode = on'Damit die Änderung angewendet werden kann, müssen Sie PostgreSQL neu starten. Im Moment werden wir diese Aktion jedoch verschieben und einen weiteren Parameter konfigurieren.
Wenn der Stream der WAL-Dateien groß genug ist, hat der Sicherungsserver möglicherweise bald keinen Speicherplatz mehr, sodass wir die Option --compress in die Zeile archive_command einfügen können. Die Protokolldateien werden komprimiert, bevor sie an srv_bkp gesendet werden. Und wir müssen uns keine Sorgen machen, dass diese Dateien während der Wiederherstellung separat entpackt werden müssen - pg_probackup kann mit komprimierten Dateien arbeiten.
alter system set archive_command = 'pg_probackup-12 archive-push -B /home/backup_user/backup_db --instance=db1 --wal-file-path=%p --wal-file-name=%f --remote-host=srv_bkp --remote-user=backup_user --compress';Jetzt können Sie neu starten.
Was wir in der ersten Aufgabe getan haben, wird als Offline-Sicherung bezeichnet. Es wird so genannt, weil eine solche Kopie alle WAL-Dateien enthält, die zum Wiederherstellen erforderlich sind. In der aktuellen Aufgabe wechseln wir von Offline-Kopien zu Archivkopien. Diese Kopien enthalten nicht die erforderlichen Protokolle. Dies spielt jedoch keine Rolle, da wir alle benötigten WAL-Dateien in einem Archiv speichern werden. Beim Wiederherstellen von Sicherungskopien werden WAL-Dateien aus dem Archiv kopiert.
Da wir in der betrachteten Situation von Offline-Sicherungen (im Stream-Modus erstellt) zu archivierten Backups (im Archivmodus) wechseln, kann es vorkommen, dass wir eine Kopie erstellt haben, als der Archivierungsmodus noch nicht aktiviert war und einige der WAL-Segmente bereits angezeigt wurden entfernt. Dies bedeutet, dass die erste Sicherung nach dem Wechsel in den Archivierungsmodus nicht im PAGE-Modus durchgeführt werden kann, da Das WAL-Segment im Archiv zwischen der Vergangenheit und der aktuellen Kopie ist möglicherweise nicht vollständig.
Lassen Sie uns dies mit dem Skript tun, das in der ersten Aufgabe erstellt wurde:
./bkp_base.sh DELTADann erstellen wir unser erstes Backup im PAGE-Modus
./bkp_base.sh PAGEIch möchte Sie daran erinnern, dass drei inkrementelle Modi verfügbar sind: PAGE, DELTA und PTRACK. Sie unterscheiden sich darin, wie sie die erforderlichen Informationen zu den geänderten Seiten erhalten:
Nehmen wir nun an, die Sicherungskopie benötigt die WAL-Dateien, die während der Erstellung der Sicherung erstellt wurden, um sie wiederherstellen zu können. Jene. Wenn wir 30 Minuten lang eine inkrementelle Sicherung durchführen und während dieser 30 Minuten 10 GB WAL erstellt wurden, werden nur diese 10 GB benötigt, damit wir sie konsistent wiederherstellen können. Alle anderen WAL-Dateien werden nur für die Wiederherstellung zu einem bestimmten Zeitpunkt benötigt.
Die Aufgabe ergab, dass wir uns in den letzten 3 Tagen jederzeit erholen können möchten. Das heißt, alle WAL für diesen Zeitraum müssen gespeichert werden. Außerdem müssen alle WAL gespeichert werden, die für die Wiederherstellung aus früheren Sicherungen erforderlich sind. Wir müssen jedoch nicht alle anderen WAL-Dateien speichern!
Wenn wir den Befehl find verwenden können, um veraltete WALs zu entfernen und mtime und -exec rm {} hinzuzufügen, ist es keine leichte Aufgabe, zu bestimmen, welches WAL-Segment zum konsistenten Wiederherstellen einer bestimmten Sicherung erforderlich ist. Es ist gut, dass die Entwickler darüber nachgedacht und den Parameter --wal-depth hinzugefügt haben, mit dem Sie die in Backups berechnete WAL-Speichertiefe festlegen können.
Dies kann schematisch wie folgt beschrieben werden:
Bitte beachten Sie, dass es jetzt irgendwo Mitte Samstag ist, was bedeutet, dass wir alle WAL-Dateien löschen können, die nicht benötigt werden, um Backups wiederherzustellen, die älter als drei Tage sind (braune Farbe in der Grafik). Die noch benötigten WALs werden gelb hervorgehoben. Hier kann sich eine logische Frage stellen - aber es ist doch schon Mitte Samstag, was bedeutet, dass einige der am Mittwoch erstellten Morgenprotokolle nicht mehr benötigt werden und gelöscht werden können. Ja, dies ist so, und Sie können das Löschen überschüssiger WAL mindestens jede Minute konfigurieren. In unserem Artikel werden jedoch Protokolle zusammen mit der Erstellung von Sicherungen gelöscht. Obwohl sie nicht mehr in die Aufbewahrungsrichtlinie fallen, werden sie beim Erstellen der nächsten Sicherung gelöscht ...
Ändern Sie die Einstellungen der db1-Instanz - fügen Sie die Lebensdauer der WAL-Dateien hinzu
pg_probackup set-config --instance db1 --wal-depth=3Lassen Sie uns überprüfen, ob die Einstellungen angewendet wurden:
pg_probackup show-config --instance=db1 | grep wal-depthFügen Sie dem Sicherungsbefehl im Skript bkp_base.sh das Flag --delete-wal hinzu und entfernen Sie auch den Schalter --stream, da wir von Offline-Sicherungen zu archivierten wechseln
pg_probackup backup --instance=db1 -j 2 --progress -b $1 --compress --delete-expired --delete-walDerzeit haben wir die Erstellung von Archivsicherungen auf einem separaten Server konfiguriert. Außerdem werden hier Protokolldateien hinzugefügt, sodass wir die Wiederherstellung nicht nur für eine bestimmte Sicherung verwenden können, sondern auch eine Wiederherstellung zu einem bestimmten Zeitpunkt durchführen können - die Wiederherstellung zu einem bestimmten Zeitpunkt.
Da wir jetzt ein Archiv von WAL-Dateien haben, können wir den PAGE-Modus verwenden, um inkrementelle Sicherungen zu erstellen. Ich möchte Sie daran erinnern, dass in diesem Modus Änderungen gegenüber der vorherigen Sicherung nicht nach Datendateien berechnet werden, sondern nach WAL, die seit der vorherigen Sicherung akkumuliert wurden.
PS Nur zu Bildungszwecken! Erstellen wir eine Tabelle in der Datenbank auf dem Server srv_db1:
psql -c 'create table timing(time_now timestamp with time zone)'Schreiben Sie dann die folgende Zeile an crontab:
* * * * * psql -c 'insert into timing(select now())'Jede Minute werden Informationen über die aktuelle Uhrzeit in der Datenbank aufgezeichnet. Diese Informationen sind für uns nützlich, wenn wir zu einem bestimmten Zeitpunkt wiederherstellen.
Problem 3
Gegeben:
Wir haben zwei Server, der erste hat unsere Datenbank (Hostname srv_db1, Benutzer postgres), der zweite speichert archivierte Backups und WAL-Dateien (Hostname srv_bkp, Benutzer backup_user). In unserer Umgebung wird ein weiterer Server srv_db2 angezeigt (Benutzer postgres), auf dem wir ein Replikat unseres Clusters bereitstellen und pg_probackup neu konfigurieren müssen, damit Sicherungen vom Replikat erstellt werden.
Entscheidung:
Das Internet ist voll von Beschreibungen zum Erstellen von Replikaten in PostgreSQL. Alles, was Sie tun müssen, ist, "Erstellen eines Replikats in PostgreSQL" in die Suchmaschine zu fahren - wählen Sie, ich möchte nicht! Es gibt Dokumentationen, Artikel und sogar Video-Tutorials. Alle diese Methoden sind gut, berücksichtigen jedoch normalerweise nicht, dass wir bereits Backups haben. Wir möchten ein Replikat mithilfe einer Sicherung erstellen, daher entfernen wir die Leselast vom Master. Das heißt, unser Produktionsserver wird nicht wissen, dass irgendwo daneben ein Replikat erstellt wird (dies natürlich mit Vorbehalten - hier muss der Replikationssteckplatz erstellt und die Zugriffsrechte festgelegt werden, aber während wir ein Replikat erstellen, wird der Master nicht zusätzlich belastet wird nicht).
Wir haben den Zugriff über Schlüssel zwischen den Servern srv_bkp und srv_db2 eingerichtet, PostgreSQL und pg_probackup auf srv_db2 installiert (wir haben alles außer der PostgreSQL-Installation während der ersten Aufgabe durchgeführt, aber wenn Sie Fragen zur Installation des DBMS haben, schauen Sie hier ).
Gehen Sie zu srv_db2
ssh-keygen -t rsa
ssh-copy-id backup_user@srv_bkpGehen Sie zu srv_bkp
ssh-copy-id postgres@srv_db2Lassen Sie uns unser internes Paranoid einschalten und ~ / .ssh / autorized_keys bearbeiten - einfügen
command="pg_probackup-12 agent"vor neuen Schlüsseln.
Die Verwendung von WAL-Dateien ist viel langsamer als die Wiederherstellung aus einer Sicherung. Erstellen Sie also eine weitere inkrementelle Sicherung. Stellen Sie mit backup_user eine Verbindung zum srv_bkp-Server her und führen Sie den folgenden Befehl aus:
pg_probackup backup --instance=db1 -j 2 --progress -b PAGE --compressWarum haben wir das von uns erstellte Skript nicht verwendet? Tatsache ist, dass wir dem Skript früher die Option --delete-wal hinzugefügt haben, dh nach dem Erstellen dieser Sicherung konnten wir nicht zu einem Zeitpunkt wiederherstellen, der vor drei Tagen lag. Wenn wir diese Sicherung verlassen, verlässt die nächste Sicherung, die durch Ausführen unseres Skripts erstellt wird, WAL nur für die letzten zwei Tage. Das heißt, nachdem wir diese Sicherung wiederhergestellt haben, ist es sinnvoll, sie zu löschen.
Wir erholen uns:
time pg_probackup restore --instance=db1 -D /var/lib/pgsql/12/data -j 2 --restore-as-replica --progress --remote-proto=ssh --remote-host=srv_db2 --archive-host=srv_bkp --archive-user=backup_user --log-level-console=log --log-level-file=verbose --log-filename=restore_rep.logDas Verzeichnis / var / lib / pgsql / 12 / data muss leer sein. Außerdem müssen Sie auf dem Server srv_db1 Änderungen an pg_hba.conf vornehmen. Ermöglichen Sie den Zugriff vom Server srv_db2 mithilfe des Replikationsprotokolls.
host replication all srv_db2 md5Wir haben die Konfiguration erneut gelesen:
psql -c 'select pg_reload_conf()'Auf Tippfehler prüfen:
psql -c 'select * from pg_hba_file_rules'Erstellen Sie eine Datei ~ / .pgpass auf srv_db2, in der wir die Verbindungsberechtigungen in srv_db1 angeben, diesmal jedoch mit der Replikationsbasis, und starten Sie PostgreSQL.
srv_db1:5432:replication:backup:Strong_PWDUnd ändern wir seine Rechte auf 600:
chmod 600 ~/.pgpassWir starten den Cluster auf srv_db2.
Lassen Sie uns überprüfen, ob alles gut funktioniert. Wir werden dafür die folgenden Möglichkeiten nutzen.
Wir schauen uns die Replik-Protokolldatei an, irgendwo gegen Ende sollte die folgende Zeile erscheinen:
Database system is ready to accept read only connectionspsql -c 'select pg_is_in_recovery()' sollte t zurückgeben
Jetzt erstellen wir eine Platte t1 im Assistenten:
srv_db1: psql -c 'create table t1()'Lassen Sie uns überprüfen, ob es auf dem Replikat angezeigt wurde.
srv_db2: psql -c '\d'Die Platte ist angebracht, dann funktioniert die Replikation. Wir entfernen die Platte am Master.
srv_db1: psql -c 'drop table t1'Natürlich sollten Sie in einer realen Datenbank jetzt einen Replikationssteckplatz auf dem Master erstellen und das Replikat so konfigurieren, dass es über diesen Steckplatz an den Master geht. Das Thema unseres Artikels sind jedoch keine Replikate, sondern Sicherungen. Fahren wir also fort.
Das Replikat funktioniert also für uns. Bei Bedarf können wir zum Replikat wechseln, aber stellen wir uns eine Frage: Können wir es besser machen?
Natürlich kannst du. Warum müssen wir Backups vom Master erstellen, wenn wir die Leselast vom Master entfernen und auf ein Replikat übertragen können?
VORSICHT! REPLIC LACK MONITORING MUSS ÜBERWACHT WERDEN, andernfalls kann es herauskommen, dass Sie nicht wissen, dass die REPLICA LAGGED ist, und weiterhin von der REPLICA LAG sichern.
Lass uns das tun!
Wir nehmen Änderungen an den Clustereinstellungen auf den Servern srv_db1 und srv_db2 vor:
alter system set archive_timeout=180;
select pg_reload_conf();Gehen Sie zu srv_bkp und ändern Sie den Wert des Remote-Host-Parameters:
pg_probackup set-config --instance db1 --remote-host=srv_db2Wir nehmen Änderungen an .pgpass auf dem srv_bkp-Server vor - fügen Sie die Verbindungszeichenfolgen zum srv_db2-Server hinzu:
srv_db2:5432:replication:backup:Strong_PWD
srv_db2:5432:backupdb:backup:Strong_PWDUnd lassen Sie uns versuchen, ein weiteres Backup zu erstellen.
srv_bkp: ./bkp_base.sh PAGEWir sehen, dass das Backup funktioniert hat.
Das Problem ist gelöst!
Der nächste Teil ist der Wiederherstellung aus Sicherungen gewidmet: Wir werden uns verschiedene Wiederherstellungsoptionen ansehen, lernen, wie eine Wiederherstellung zu einer bestimmten Sicherung zu einem bestimmten Zeitpunkt durchgeführt wird, und uns mit teilweisen und inkrementellen Wiederherstellungen vertraut machen.