PostgreSQL WAL Archivierung
Alles über wal-archivierung in PostgreSQL.
PostgreSQL wird mit den Tools geliefert, die Sie benötigen, um Backups, inkrementelle/kontinuierliche Backups und Point-in-Time-Recovery von Backups durchzuführen. Die Archivierung von WAL-Dateien ist eine grundlegende Operation, die diese Funktionen erleichtert. Lesen Sie weiter, um mehr darüber zu erfahren, worum es geht.
Was ist überhaupt ein WAL?
WAL ist die Abkürzung für Write Ahead Log.
WALs werden in fast allen modernen RDBMS-Systemen verwendet, um dauerhafte und atomare Transaktionen bereitzustellen. Einfach ausgedrückt, wird jede Transaktion, die in der Datenbank ausgeführt wird, zuerst als WAL-Datei ausgeschrieben und dann auf die tatsächlichen Tabellendatendateien auf der Festplatte angewendet. WAL-Dateien sind streng sequenziell. Dies macht die WAL-Dateisequenz zu einem "Replay-Protokoll" von Änderungen.
Das Konzept ähnelt Redis' AOF, MySMs Binlog und MongoDS Oplog.
Sind es also tatsächliche Dateien? Ja, das ist der Konsens Sie befinden sich in $PGDATA /pg_xlog, wobei $PGDATA das Datenverzeichnis ist, wie /var/lib/postgresql/9.6/main. Es handelt sich um Binärdateien mit jeweils 16 MB.
Werden sie sich nicht weiter anhäufen? Sie werden es tun, wenn Sie Postgres nicht sagen, wann sie aufräumen sollen. Sie können diese Dateien nach Anzahl (wal_keep_segments) und/oder Gesamtgröße (max_wal_size) begrenzen.
Archivierung von WALs
Wenn Sie die Daten in den Datenbanken auf einem Server ständig ändern, werden WAL-Dateien immer wieder generiert (und nach einer Weile verworfen).
Wenn Sie eine Kopie jeder generierten WAL-Datei speichern, können Sie den gesamten Satz von Änderungen auf einem anderen Server wiedergeben. Dies in Echtzeit zu tun, wird besser als Replikation bezeichnet.
Das Speichern aller generierten WAL-Dateien an einem sicheren Offline-Speicherort wird im Wesentlichen zu einem inkrementellen Backup.
[Randnotiz: Technisch gesehen gibt es eine Sequenz von WAL-Dateien für eine einzelne Instanz eines laufenden PostgreSQL-Servers. Die WAL-Dateien würden alle Änderungen in allen von dieser Instanz verwalteten Datenbanken enthalten.]
In PostgreSQL-Begriffen wird das Kopieren generierterWAL-Files als Archivierung bezeichnet, und den Server dazu zu bringen, eine WAL-Datei einzulesen und anzuwenden, wird als Wiederherstellung bezeichnet.
Der Archivbefehl
Da PostgreSQL nicht weiß, wie Sie die WAL-Dateien archivieren möchten, müssen Sie ein Skript bereitstellen. PostgreSQL ruft dieses Skript auf, wenn jede WAL-Datei für die Archivierung bereit ist. Das Skript muss es verarbeiten (normalerweise an einen sicheren Ort kopieren) und über den Beendigungscode berichten, ob es erfolgreich war (d. b. Beenden Sie 0 aus Ihrem Skript nach erfolgreichem Abschluss).
Sobald das Skript eine WAL-Datei erfolgreich verarbeitet hat, kann der Server sie löschen oder recyceln, wenn er es für richtig hält.
Das Skript wird mit der Konfigurationseinstellung archive_command festgelegt. (Dokumente). Hier einige Beispiele:
# Kopieren Sie die Datei an einen sicheren Speicherort (z. B. ein gemountetes NFS-Volume)
archive_command = 'cp %p /mnt/nfs/%f'
# Nichtüberschreibung der Dateien ist eine gute Praxis
archive_command = 'test ! -f /mnt/nfs/%f && cp %p /mnt/nfs/%f'
# In S3-Bucket kopieren
archive_command = 's3cmd put %p s3://BUCKET/path/%f'
# In Google Cloud-Bucket kopieren
archive_command = 'gsutil cp %p gs://BUCKET/path/%f'
# Ein externes Skript
archive_command = '/opt/scripts/archive_wal %p'
Beachten Sie beim Schreiben Ihres eigenen Skripts einige Dinge:
- Wenn das Skript fehlschlägt, wird es wiederholt erneut aufgerufen, bis es erfolgreich ist. Es gibt keine Verzögerungen zwischen Wiederholungen oder Stop-after-N-Wiederholungsfunktionen.
- Dateien sind 16 MB groß und werden normalerweise gut komprimiert.
- Das Skript wird sequenziell aufgerufen, es gibt keinen Parallelismus.
- Es ist eine bewährte Methode, Zieldateien nicht zu überschreiben, wenn sie vorhanden sind.
- Sie sollten die Datei, die PostgreSQL Ihnen übergibt, als schreibgeschützt behandeln. Wenn Sie es komprimieren möchten, stellen Sie sicher, dass Sie das Original nicht ändern.
- Das Skript wird als Benutzer postgres aufgerufen. Stellen Sie sicher, dass dieser Benutzer über die erforderlichen Lese-/Schreibberechtigungen für relevante Verzeichnisse verfügt.
Das WAL-Level
Standardmäßig enthalten WAL-Dateien nur die Informationen, die für die Wiederherstellung nach einem Absturz oder sofortigen Herunterfahren erforderlich sind. Dies ist der minimale WAL-Level.
Die nächste Ebene ist das Archiv (oder Replikat in Version 9.6 und höher). Wenn Sie die WAL-Ebene auf Archivieren oder höher festlegen, enthält der Server genügend Informationen, um die Archivierung (und Wiederherstellung) von WAL-Dateien zu ermöglichen.
Die Ebene danach heißt hot_standy (in Version 9.6 und höher auch replica zugeordnet) und enthält Informationen, die zum Ausführen schreibgeschützter Abfragen auf einem Standbyserver erforderlich sind.
Mit der letzten logischen Ebene ist es möglich, logische Änderungssätze aus WAL zu extrahieren.
Die WAL-Ebene ist eine Konfigurationseinstellung, die wal_level bezeichnet wird. Für unsere Bedürfnisse müssen wir festlegen, dass dies mindestens archiviert wird. PostgreSQL weigert sich zu starten, wenn Sie eine Archivierung anfordern, aber wal_level ist geringer als dies.
# Die WAL-Ebene muss archive oder höher sein.
wal_level = archive
Archiv-Timeout
Wenn Ihr PostgreSQL-Server einen ruhigen Tag mit einer niedrigen Transaktionsrate hat, kann es eine Weile dauern, bis eine vollständige WAL-Datei ausgefüllt ist. Aus Sicht des Betriebs ist es jedoch in der Regel eine gute Idee, mindestens eine WAL-Datei alle X Minuten (oder Stunden oder Tage, je nach Setup) zu sichern.
Die Einstellung archive_timeout kann verwendet werden, um PostgreSQL anzuweisen, mindestens eine WAL-Datei pro "archive_timeout" -Dauer zu generieren, auch wenn sie leer ist.
# Stellen Sie sicher, dass für jede "archive_timeout" -Dauer mindestens eine WAL-Datei vorhanden ist.
archive_timeout = 1h
Steuern der WAL-Dateien
PostgreSQL bietet einige Hebel, um die Anzahl der WAL-Dateien zu steuern, die im pg_xlog Verzeichnis liegen.
Die Einstellungen min_wal_size und max_wal_size begrenzen die Gesamtgröße der WAL-Dateien. Ein Mindestlimit ermöglicht das Recycling alter Dateien (sie werden zuerst umbenannt). Die Obergrenze ist eine weiche Grenze, da der Server nur die Dateien sicher löschen kann, die erfolgreich archiviert wurden.
Die wal_keep_segments kann verwendet werden, um ein Mindestlimit für die Anzahl der WAL-Dateien in pg_xlog festzulegen. Dies dient hauptsächlich dazu, langsame oder intermittierende Standby-Server zu ermöglichen.
# Dies ist eine weiche Obergrenze für die Gesamtgröße von WAL-Dateien.
max_wal_size = 1GB
# Halten Sie mindestens diese vielen WAL-Dateien (auch bekannt als Segmente) bereit.
wal_keep_segments = 10
Die Archivierungseinstellungen
Schließlich gibt es noch die archive_mode Einstellung, die natürlich eingeschaltet werden muss, damit die Archivierung funktioniert. Hier sind die wichtigen Einstellungen für die Archivierung, abgerundet:
# Die WAL-Ebene muss archive oder höher sein.
wal_level = archive
# Dies ist eine weiche Obergrenze für die Gesamtgröße von WAL-Dateien.
max_wal_size = 1GB
# Halten Sie mindestens diese vielen WAL-Dateien (auch bekannt als Segmente) bereit.
wal_keep_segments = 10
# Die archive_mode muss auf On gesetzt sein, damit die Archivierung stattfinden kann.
archive_mode = on
# Dies ist der Befehl, der für jede zu archivierende WAL-Datei aufgerufen werden soll.
archive_command = '/opt/scripts/archive_wal %p'
# Stellen Sie sicher, dass für jede "archive_timeout" -Dauer mindestens eine WAL-Datei vorhanden ist.
archive_timeout = 1h
Wiederherstellen von WALs
Das Wiederherstellen von WALs erfolgt in der Regel im Zusammenhang mit der Wiederherstellung aus einer Sicherung, der Durchführung einer Point-in-Time-Recovery (PITR) oder der Streaming-Replikation. Es ist ein bisschen zu umfangreich, um es in demselben Blog Beitrag zu behandeln, also müssen wir dies nur als einen weiteren Beitrag tun.
Überwachung der WAL-Archivierung
PostgreSQL bietet einen Statistiksammler, der abgefragt werden kann, um den Status der WAL-Archivierung zu untersuchen. Insbesondere können Sie die pg_stat_archiver verwenden, um die WAL-Erfolgs- und Misserfolgszahlen zu sehen.