Barmann 2.11:Barmann-Cloud-Wiederherstellung und Barmann-Cloud-Wal-Wiederherstellung

Dank der neuen Dienstprogramme barman-cloud-restore und barman-cloud-wal-restore eingeführt in Barman 2.11 , ist es jetzt möglich, die Wiederherstellung einer PostgreSQL-Instanz mithilfe einer zuvor mit barman-cloud-wal-archive ausgeführten vollständigen Sicherung durchzuführen und barman-cloud-backup Befehle. Lassen Sie uns im folgenden Artikel gemeinsam herausfinden, wie Sie dies umsetzen können.

Es ist erwähnenswert, dass sich in Barman 2.11 alle Cloud-Dienstprogramme für Barman jetzt in einem separaten Paket namens barman-cli-cloud befinden .

Anforderungen

1. barman-cli-cloud Paket
2. Eine PostgreSQL-Instanz
3. Ein AWS S3-Bucket
4. Eine zweite virtuelle Maschine, auf der die Wiederherstellung ausgeführt wird

In diesem Artikel testen wir barman-cli-cloud Funktionalitäten in einer virtuellen Maschine mit Debian Buster und PostgreSQL 12. Um die Anweisungen in diesem Artikel richtig zu befolgen, gehen wir außerdem davon aus, dass Sie:

konfigurierte Postgres zum Archivieren von WAL-Dateien in einem vorhandenen S3-Bucket mit barman-cloud-wal-archive
eine Sicherung ausgeführt und über barman-cloud-backup an denselben S3-Bucket gesendet

Sie können dies leicht erreichen, indem Sie den Anweisungen in diesen vorherigen Blog-Artikeln folgen:

Barman Cloud – Teil 1:WAL-Archiv
Barman Cloud – Teil 2:Cloud-Sicherung

Richten Sie den Wiederherstellungsserver ein

Als Ergebnis haben wir einen S3-Bucket auf AWS mit dem Namen barman-s3-test die bereits die WAL-Dateien und Backups enthält, die über barman-cloud-wal-archive archiviert wurden und barman-cloud-backup Tools, müssen wir jetzt einen Server richtig konfigurieren, der der Host für die Wiederherstellung der PostgreSQL-Instanz sein wird.

1. Installieren Sie PostgreSQL 12 aus dem offiziellen PGDG-Repository

2. Installieren Sie das öffentliche 2ndQuadrant-Repository

3. Installieren Sie die barman-cli-cloud Paket:

example@sqldat.com:~# apt updateexample@sqldat.com:~# apt install barman-cli-cloud

4. Installieren Sie awscli Paket:

example@sqldat.com:~# apt install awscl

5. Konfigurieren Sie AWS-Anmeldeinformationen mit dem awscli-Tool als postgres-Benutzer:

example@sqldat.com:~$ aws configure --profile barman-cloudAWS Access Key ID [Keine]:AKI********************AWS Secret Access Key [Keine ]:**************************************** Standardregionsname [Keine]:eu -west-1Standardausgabeformat [Keine]:json

Führen Sie den Wiederherstellungsvorgang durch

Nachdem der Wiederherstellungsserver nun korrekt konfiguriert ist, können wir mit der Wiederherstellung beginnen.

Barman 2.11 führt die barman-cloud-backup-list ein Befehl, mit dem Sie Informationen über die mit barman-cloud-backup erstellten Sicherungen abrufen können :

example@sqldat.com:~$ barman-cloud-backup-list \ --profile barman-cloud \ s3://barman-s3-test pg12Backup ID End Time Begin Wal20200713T120856 2020-07-13 12:09:05 00000001000000000000000C

Wir sind jetzt bereit, die Wiederherstellung mit barman-cloud-restore auszuführen Befehl:

example@sqldat.com:~$ barman-cloud-restore \ --profile barman-cloud \ s3://barman-s3-test \ pg12 20200713T120856 \ /var/lib/postgresql/12/main/

Sobald die Wiederherstellung erfolgreich abgeschlossen ist, können wir den Inhalt des PGDATA-Verzeichnisses überprüfen:

example@sqldat.com:~$ ls /var/lib/postgresql/12/main/PG_VERSION global pg_hba.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.confbackup_label pg_commit_ts pg_ident.conf pg_notify pg_snapshots pg_subtrans pg_wal postgresql.confbase pg_replslot pg_stat pg_tblspc pg_xact

Um nun sicherzustellen, dass der Wiederherstellungsprozess ordnungsgemäß funktioniert hat, müssen wir die wiederhergestellte PostgreSQL-Instanz starten und überprüfen, ob alles wie erwartet funktioniert. Dieser Vorgang erfordert einige zusätzliche Schritte.

Da wir uns auf einem Debian-System befinden, müssen wir zunächst die Dateien mit der PostgreSQL-Konfiguration unter /etc/postgresql/12/main/ kopieren Verzeichnis:

example@sqldat.com:~$ cp /var/lib/postgresql/12/main/postgresql.conf /etc/postgresql/12/main/example@sqldat.com:~$ cp /var/lib/postgresql /12/main/pg_hba.conf /etc/postgresql/12/main/example@sqldat.com:~$ cp /var/lib/postgresql/12/main/pg_ident.conf /etc/postgresql/12/main/

Zweitens erstellen Sie das recovery.signal Datei:

example@sqldat.com:~$ touch /var/lib/postgresql/12/main/recovery.signal

Deaktivieren Sie dann den archive_command um zu verhindern, dass die wiederhergestellte Instanz in denselben Bucket wie die ursprüngliche Instanz schreibt:

example@sqldat.com:~$ echo \"archive_command ='cd .'\">> /etc/postgresql/12/main/postgresql.conf

Danach müssen Sie PostgreSQL konfigurieren, um die WAL-Dateien der neuesten verfügbaren Zeitachse aus dem S3-Bucket abzurufen, indem Sie den barman-cloud-wal-restore verwenden im restore_command :

example@sqldat.com:~$ echo \"restore_command ='barman-cloud-wal-restore --profile barman-cloud s3://barman-s3-test pg12 %f %p'\">> / etc/postgresql/12/main/postgresql.confexample@sqldat.com:~$ echo \"recovery_target_timeline ='latest'\">> /etc/postgresql/12/main/postgresql.conf

WICHTIG :Bevor Sie fortfahren, vergewissern Sie sich bitte, dass die PostgreSQL-Instanz nicht läuft und dass das Zielverzeichnis (das standardmäßige PostgreSQL-Datenverzeichnis) leer ist.

Schließlich sind wir bereit, die neue wiederhergestellte Instanz zu starten:

example@sqldat.com:~# systemctl restart example@sqldat.com

Toll! Wie wir aus dem PostgreSQL-Protokoll ersehen können, werden WAL-Dateien aus dem S3-Bucket wiederhergestellt und die Instanz wurde korrekt gestartet:

example@sqldat.com:~$ less /var/log/postgresql/postgresql-12-main.log...2020-07-13 12:43:25.093 UTC [9458] LOG:Starten von PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) auf x86_64-pc-linux-gnu, kompiliert von gcc (Debian 8.3.0-6) 8.3.0, 64-bit2020-07-13 12:43:25.093 UTC [9458] LOG:Lauschen auf IPv4-Adresse „127.0.0.1“, Port 54322020-07-13 12:43:25.095 UTC [9458] LOG:Lauschen auf Unix-Socket „/var/run/postgresql/.s.PGSQL.5432“2020-07- 13 12:43:25.111 UTC [9459] LOG:Datenbanksystem wurde unterbrochen; zuletzt bekannt am 13.07.2020 12:08:56 UTC2020-07-13 12:43:25.508 UTC [9459] LOG:Beginn der Wiederherstellung des Archivs2020-07-13 12:43:26.010 UTC [9459] LOG:wiederhergestelltes Protokoll Datei "00000001000000000000000C" aus Archiv2020-07-13 12:43:26.052 UTC [9459] LOG:Wiederholen beginnt bei 0/C0000282020-07-13 12:43:26.054 UTC [9459] LOG:Konsistenter Wiederherstellungsstatus erreicht bei 0/C002013820.3820.382 -07-13 12:43:26.054 UTC [9458] LOG:Datenbanksystem ist bereit, Nur-Lese-Verbindungen zu akzeptieren2020-07-13 12:43:26.469 UTC [9459] LOG:wiederhergestellte Protokolldatei "000000010000000000000000D" aus Archiv2020-07- 13 12:43:26.823 UTC [9459] LOG:Wiederholen durchgeführt um 0/D0001B02020-07-13 12:43:27.242 UTC [9459] LOG:wiederhergestellte Protokolldatei „00000001000000000000000D“ aus Archiv2020-07-13 12:43:27.5 UTC [9459] LOG:ausgewählte neue Timeline-ID:22020-07-13 12:43:27.644 UTC [9459] LOG:Wiederherstellung des Archivs abgeschlossen2020-07-13 12:43:27.979 UTC [9458] LOG:Datenbanksystem ist bereit Verbindungen akzeptieren

Schlussfolgerung

Wie bei jeder neuen Version von Barman üblich, empfehlen wir jedem, sein System auf die neueste Version zu aktualisieren. Eine vollständige Liste der Änderungen und Fehlerbehebungen finden Sie hier.

Bitte beachten Sie, wenn Sie bereits barman-cloud-wal-archive verwenden oder barman-cloud-backup über das RPM/Apt-Paket installiert haben und Sie Ihr System aktualisieren, müssen Sie barman-cli-cloud installieren Paket. Dies liegt daran, dass mit Barman 2.11 alle Cloud-bezogenen Tools Teil der barman-cli-cloud sind Paket wie am Anfang des Artikels erklärt.

Die nächsten Versionen von Barman könnten die Benutzerfreundlichkeit und die Automatisierungsmöglichkeiten des Wiederherstellungsbefehls verbessern, zum Beispiel durch die Erstellung einer recovery.conf oder recovery.signal Datei wie der eigentliche Barkeeper.