PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Barman Cloud – Teil 1:WAL-Archiv

Präambel

Wie viele aktuelle Barman-Benutzer haben darüber nachgedacht, Backups an einem entfernten Ziel in der Cloud zu speichern? Wie viele haben daran gedacht, diese Sicherung direkt vom PostgreSQL-Server selbst zu nehmen?

Nun, seit Barmann 2.10 das ist jetzt möglich!
Wie?
Das entdecken wir gemeinsam in den folgenden Artikeln.

Anforderungen

Die folgenden zwei Artikel sollen eine praktische Einführung in das neue barman-cloud-wal-archive sein und barman-cloud-backup Werkzeuge, die im barman-cli hinzugefügt wurden Paket.
Der erste Teil behandelt das barman-cloud-wal-archive Befehl, während der zweite das barman-cloud-backup abdeckt Befehl.
Leser benötigen Grundkenntnisse der PostgreSQL-WAL-Archivierungs- und Sicherungsmethoden sowie von Barman. Es wird außerdem empfohlen, dass Sie sich mit Cloud-Technologien für Speicherlösungen wie Amazon S3 auskennen.

WAL-Archiv

Barman fungiert seit vielen Jahren als Remote-WAL-Archiv, und das Barman-CLI-Paket wurde entwickelt, um die Archivierungszuverlässigkeit und -robustheit auf der PostgreSQL-Seite zu erweitern. Genau genommen barman-cli bietet Skripte wie barman-wal-restore ermöglicht einem Standby-Knoten die intelligente und sichere Wiederherstellung von WAL-Dateien aus einem Barman-Archiv durch den restore_command -Parameter in der postgresql.auto.conf Datei (oder recovery.conf Datei bis PostgreSQL 12) und barman-wal-archive um WAL-Dateien von einem Master-Knoten zu Barman durch den archive_command zu archivieren Parameter, der in der postgresql.conf konfiguriert ist Datei.

Cloud WAL-Archiv

Dank des Feedbacks der Benutzer haben die Barman-Entwickler zwei neue Tools in Version 2.10 eingeführt :

  • barman-cloud-wal-archive
  • barman-cloud-backup

Version 2.11 enthält zwei zusätzliche Wiederherstellungstools namens barman-cloud-wal-restore und barman-cloud-restore .
Dieser Beitrag ist ausschließlich barman-cloud-wal-archive gewidmet , das WAL-Dateien in der Cloud speichern kann, eine mehrschichtige Archivierung mit Barman ermöglicht und die Aufbewahrungsrichtlinie für Backups erweitert.
In der Tat, barman-cloud-wal-archive kann als Hook-Skript verwendet werden, das das pre_archive_retry_script konfiguriert Parameter in Barman, um WAL-Dateien in den konfigurierten Cloud-Speicher zu kopieren, die Redundanz des Archivs zu erhöhen und es möglich zu machen, eine längere Aufbewahrungsrichtlinie als die von Barman zu wählen.

Das ist noch nicht alles!

barman-cloud-wal-archive kann das barman-wal-archive ersetzen Befehl im archive_command -Parameter, um WAL-Dateien direkt in der Cloud zu archivieren, anstatt sie auf den Barman-Server zu kopieren. Auf diese Weise kann sich sogar ein PostgreSQL-Cluster, der keinen separaten dedizierten Sicherungsserver hat, auf den Remote-Speicherdienst verlassen, um WAL-Dateien zu archivieren.

Wie funktioniert es?

Die folgenden Anweisungen dienen lediglich der Installation und Konfiguration von barman-cloud-wal-archive als archive_command in PostgreSQL.
Entscheiden Sie zuerst, wo WAL-Dateien archiviert werden sollen. In diesem Artikel verwenden wir Amazon S3, das zum Zeitpunkt des Schreibens die einzige unterstützte Technologie ist. Obwohl andere Technologien, die eine S3-ähnliche API unterstützen (Google Cloud, DigitalOcean, Microsoft Azure usw.), mit der boto3-Bibliothek funktionieren können, wurden sie noch nicht getestet.

Anforderungen

  1. barman-cli 2.10 (oder höher)
  2. Amazon AWS-Konto
  3. awscli
  4. S3-Bucket
  5. Eine PostgreSQL-Instanz

In diesem Artikel testen wir Barman CLI in einer virtuellen Maschine mit Debian Buster und PostgreSQL 12 die bereits läuft.

Installation

    1. Installieren Sie das öffentliche 2ndQuadrant-Repository
    2. Installieren Sie das barman-cli-Paket
      [email protected]:~# apt update
[email protected]:~# apt install barman-cli
    3. Installieren Sie awscli
      [email protected]:~# apt install awscli

    Konfiguration und Einrichtung

    Lesen wir das Handbuch:

    [email protected]:~$ man barman-cloud-wal-archive
[...]
SYNOPSIS
    barman-cloud-wal-archive [OPTIONS] DESTINATION_URL SERVER_NAME WAL_PATH
[...]
POSITIONAL ARGUMENTS

    DESTINATION_URL
    URL  of the cloud destination, such as a bucket in AWS S3.
    For example: s3://BUCKET_NAME/path/to/folder (where BUCKET_NAME is the bucket you have created in AWS).

    SERVER_NAME
    the name of the server as configured in Barman.

    WAL_PATH
    the value of the `%p' keyword (according to `archive_command').
[...]

    Um es richtig zu verwenden, müssen wir also nur die AWS-Anmeldeinformationen mit awscli konfigurieren als postgres Benutzer, indem Sie den zuvor im IAM-Abschnitt der AWS-Konsole erstellten Zugriffsschlüssel und geheimen Schlüssel kopieren:

    [email protected]:~$ aws configure --profile barman-cloud
AWS Access Key ID [None]: AKI*****************
AWS Secret Access Key [None]: ****************************************
Default region name [None]: eu-west-1
Default output format [None]: json

    Stellen Sie sicher, dass Sie einen verfügbaren S3-Bucket auf AWS haben. Ich habe mich für den Namen barman-s3-test entschieden um es deutlich zu machen.
    Wir sollten jetzt in der Lage sein, das barman-cloud-wal-archive zu testen Befehl:

    [email protected]:~$ barman-cloud-wal-archive -t -P barman-cloud s3://barman-s3-test/ pg12 /var/lib/postgresql/12/main/pg_wal/000000010000000000000001
[email protected]:~$ echo $?
0

    Der Exit-Status bestätigt, dass der Befehl erfolgreich war. Wir können jetzt die folgende Zeile am Ende der PostgreSQL-Konfigurationsdatei hinzufügen und die Instanz neu starten:
    archive_mode = on 

    [email protected]:~# systemctl restart [email protected]

    Da unsere Daten außerhalb unserer Kontrolle in einen externen Speicher kopiert werden, ist es wichtig, dass wir sie komprimiert speichern und verschlüsselt . Das barman-cloud-wal-archive Der Befehl unterstützt zwei verschiedene Komprimierungsmethoden:

    [email protected]:~$ barman-cloud-wal-archive --help
[...]
    -z, --gzip            gzip-compress the WAL while uploading to the cloud
    -j, --bzip2           bzip2-compress the WAL while uploading to the cloud
    -e ENCRYPTION, --encryption ENCRYPTION
                          Enable server-side encryption for the transfer.
                          Allowed values: 'AES256', 'aws:kms'
[...]

    Die Verschlüsselungsoption teilt dem S3-Bucket lediglich mit, welche Methode zum Speichern der verschlüsselten Daten verwendet werden soll. Verschlüsselte Daten können von keinem anderen AWS-Benutzer außer dem Eigentümer des Buckets gelesen werden. Die Barman-Cloud verschlüsselt kein Objekt, bevor es an S3 gesendet wird. Sie fordert den Bucket lediglich auf, sie verschlüsselt zu speichern, wenn S3 ordnungsgemäß konfiguriert wurde. Alle Verbindungen zu S3 werden jedoch sicher über https hergestellt .

    Lassen Sie uns die folgende Zeile am Ende der postgresql.conf hinzufügen Datei:

    archive_command = 'barman-cloud-wal-archive -P barman-cloud -e AES256 -j s3://barman-s3-test/ pg12 %p'

    Diesmal genügt ein Neuladen der Konfiguration, um die neuen Änderungen zu übernehmen:

    [email protected]:~$ psql -c “SELECT pg_reload_conf()”

    Um zu testen, ob der neue archive_command funktioniert, sollte PostgreSQL zu archivierende WAL-Dateien erzeugen, daher müssen wir mit Hilfe von pgbench etwas Verkehr machen Werkzeug:

    [email protected]:~$ createdb pg_bench_db
[email protected]:~$ pgbench -i -s10 pg_bench_db

[some irrelevant output here]

[email protected]:~$ pgbench -c 10 -j 2 -T 30 pg_bench_db
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10
query mode: simple
number of clients: 10
number of threads: 2
duration: 30 s
number of transactions actually processed: 84501
latency average = 3.552 ms
tps = 2815.224687 (including connections establishing)
tps = 2815.427535 (excluding connections establishing)

    An diesem Punkt sollten wir WAL-Dateien sehen, die im S3-Bucket archiviert sind. Lassen Sie es uns überprüfen, indem wir den Zielpfad mit dem Servernamen und dem WAL-Zielverzeichnis erstellen:

    [email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/
                        PRE 0000000100000000/

    Werfen wir einen Blick in das Verzeichnis 0000000100000000:

    [email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/0000000100000000/
2020-01-08 08:20:54    1624168 000000010000000000000001.bz2
2020-01-08 08:21:00     293422 000000010000000000000002.bz2
2020-01-08 08:21:06     301934 000000010000000000000003.bz2
2020-01-08 08:21:11     295648 000000010000000000000004.bz2
2020-01-08 08:21:16     293675 000000010000000000000005.bz2
2020-01-08 08:21:21     299348 000000010000000000000006.bz2
2020-01-08 08:21:27     551249 000000010000000000000007.bz2
2020-01-08 08:21:33     976523 000000010000000000000008.bz2
2020-01-08 08:21:37    4542104 000000010000000000000009.bz2
2020-01-08 08:21:46    5052693 00000001000000000000000A.bz2

    Großartig!

    WAL-Dateien werden vor dem Hochladen in den S3-Bucket komprimiert und verschlüsselt gespeichert, wodurch wir Platz (und Geld) sparen und das Sicherheitsniveau unserer Daten erhöhen.

    Schlussfolgerungen

    Das barman-cloud-wal-archive Befehl ist das, worauf Benutzer lange gewartet haben.

    Wenn Sie einer von denen sind, die pre_archive_retry_script verwendet haben um ein benutzerdefiniertes Skript zum Hochladen von WAL-Dateien in einen S3-Bucket zu implementieren, kann dies als besserer Ersatz verwendet werden, da es von Barman-Entwicklern entwickelt und gepflegt und vom 2ndQuadrant Continuous Delivery-System getestet und bereitgestellt wird.

    Falls Sie noch nicht darüber nachgedacht haben, eröffnet dies neue Aufbewahrungsrichtlinien, die für Cloud-Speicher länger sein können als die lokalen Barman-Richtlinien, wodurch das Alter der Objekte in der Cloud erhöht und gleichzeitig Speicherplatz auf dem lokalen Speicher gespart wird, indem sie richtig eingestellt werden eine längere Aufbewahrungsrichtlinie in der Konfiguration der S3-Buckets.

    Andernfalls kann es wie in diesem Artikel verwendet werden, um WAL-Dateien direkt vom PostgreSQL-Server zu archivieren. Dadurch entfällt zwar ein Zwischenschritt, der RPO erhöht sich im Vergleich zur Streaming-Methode, da PostgreSQL die WAL-Datei erst archiviert, nachdem sie geschlossen wurde. Daher könnten wir bei Problemen auf dem PostgreSQL-Knoten einige Änderungen verlieren. Wenn möglich, empfehlen wir, diese Methode zusammen mit dem Streaming auf einen Barman-Server zu implementieren, um RPO=0 zu erreichen (mit synchronem Streaming).

    Jetzt, da wir ein kontinuierliches Archivierungssystem eingerichtet haben, können wir unser erstes Cloud-Backup erstellen mit dem barman-cloud-backup Werkzeug.

    Wir sehen uns im zweiten Teil des Artikels.