PostgreSQLs Datenbestände sichern
Dieser Artikel beschreibt die Möglichkeiten, Datenbestände aus PostgreSQL zu sichern. Hierzu stehen verschiedene Methoden zur Verfügung, die allesamt über Vor- und Nachteile verfügen. Sie werden näher vorgestellt und bewertet.
archive_command = 'cp %p /usr/backup/postgres-wal/%f'
Dabei sollte darauf geachtet werden, dass der Befehl auch ausgeführt wird, da ihn PostgreSQL sonst bis zum Gelingen wiederholt. So kann es unter Umständen vorkommen, dass das Dateisystem mit WAL-Dateien volläuft, da die Rotation der Logs nicht durchgeführt werden kann. Weiterhin ist es empfehlenswert, zumindest bei ausgelasteten Servern, die Größe und Anzahl der Logdateien zu benchmarken. Je mehr Transaktionen auftreten, die geloggt werden müssen, desto mehr werden die Logdateien rotiert, was wiederum zu Leistungseinbußen führen kann.
Um eine Sicherung des Datenbankclusters durchzuführen, muss man die Datenbank vor- und nachbereiten. Dazwischen kann der Datenbankcluster gesichert werden. Dies geschieht mit den folgenden SQL-Befehlen.
$ echo "select pg_start_backup('Label');" | psql -U pgsql template1
# fssconfig -x -c fss0 /pgcluster /
# dump -0 -f /usr/backuppgcluster.0 /dev/fss0
# fssconfig -u fss0
$ echo "select pg_stop_backup();" | psql -U pgsql template1
Erst wird der Datenbankcluster zur Sicherung vorbereitet und gesichert, anschließend wird der Backup-Checkpoint entsperrt und es können die neuen WALs rotiert werden. Hat man einen derart gesicherten Datenbankcluster, reicht es aus, die WALs, die danach erzeugt werden, zu sichern. Ist die Datenbankaktivität - und damit das Wachstum der Logs - recht hoch, empfiehlt es sich u. U., häufiger den Cluster zu sichern und somit die Zahl der zu archivierenden Logdateien zu minimieren.
Um einen derartig gesicherten Datenbestand zurückzuspielen, sind folgende Schritte notwendig:
- PostgreSQL neu installieren oder anhalten
- Sicherung des Datenbankclusters zurückspielen
- recovery.conf erstellen und
restore_commandundrecovery_target_timeauf gewünschten Zeitpunkt setzen- PostgreSQL starten
Punkt 1 wird erledigt, indem man den Dump von oben mit restore -r -f /usr/backuppgcluster.0 zurückspielt und ggf. die Dateirechte anpasst.
Punkt 2 und 3 setzen die entsprechenden Befehle, die der Postmaster ausführen soll. restore_command ist der Befehl, um die WALs zurückzukopieren, also etwas derart: restore_command=cp /usr/backup/postgres-wal/%f %p. Die Option recovery_target_time erwartet einen Zeitstempel, bis zu dem rückgesichert werden soll.
pg_dump, pg_dumpall und pg_restore
PostgreSQL verfügt auch über ein Werkzeug, um logische Backups zu erzeugen. Dabei werden SQL-Befehle zum Erstellen der Datenbank(en) in eine einfache ASCII-Textdatei oder ein Archiv geschrieben. Die entstandene ASCII-Datei kann danach mit Sicherungsmechanismen für Dateisysteme gesichert werden. Da PostgreSQL zur Transaktionsverwaltung Multi Version Concurrency Control (MVCC) einsetzt, können pg_dump und pg_dumpall problemlos im laufenden Betrieb eingesetzt werden. Es wird immer der aktuell gültige konsistente Datenbankbestand gesichert.
Um eine Datenbank zu sichern, benutzt man pg_dump(1). Um alle Datenbanken in eine Datei zu sichern, existiert pg_dumpall(1).
$ /usr/pkg/bin/vacuumdb -Upgoperator -f -z meineDB $ /usr/pkg/bin/pg_dump -Fc -Upgoperator -meineDB > /home/pgsql/meineDB_`date +%y%m%d` $ /usr/pkg/bin/pg_dumpall > pg_`date +%y%m%d`
Der erste Befehl bereinigt die Datenbank meineDB als PostgreSQL-Benutzer pgoperator mit vacuumdb(1). Dabei werden die Datensätze reorganisiert und leere Zeilen entfernt, um den Platzbedarf zu verringern. Der zweite Befehl schreibt die Datenbank mit komprimierten Large Objects in eine Sicherungsdatei. Der letzte Befehl verwendet pg_dumpall(1), um alle Datenbanken in eine Datei zu sichern.
Zum Rückspielen einer mit {pg_dump(1)} erzeugten Sicherung verwendet man pg_restore(1).
$ createdb meineDB $ pg_restore -d meineDB -f meineDB_051206 $ psql -f pg_051206 template1
Dazu muss die rückzusichernde Datenbank vorher allerdings mit createdb(1) erstellt worden sein. Anders verhält es sich mit pg_dumpall(1), denn dessen Sicherung enthält alle Befehle, um die gesicherten Datenbanken neu anzulegen, so das man sich mit einer beliebigen Datenbank verbinden kann.
Replikation
Replikationssysteme synchronisieren den Datenbestand von mehreren Servern. Dies kann auf verschiedene Arten geschehen, beispielsweise synchron/asynchron oder voll/teilweise.
Somit ist es möglich, ein Ersatzsystem (in Fachkreisen auch Hot-Backup genannt) bereitzuhalten, das per Replikation auf dem aktuellen Stand des Originals gehalten wird und bei dessen Ausfall dessen Funktion übernehmen kann.
Asynchrone Replikation verteilt die Daten erst nach einem erfolgreichen BEGIN ... COMMIT-Block auf die angeschlossenen Replikanten. Dies schränkt das System aber etwas ein:
- nur ein einziger Master ist sinnvoll, da sonst Konsistenzprobleme drohen (OIDs, Primärschlüssel)
- Lastverteilung ist nicht vorgebbar
Synchrone Replikation hingegen verteilt die Daten sofort bei Beginn der Transaktion, so das diese auf allen Rechnern ausgeführt wird. Hierbei ist allerdings die Konsistenz der Rechner untereinander ein Problem, denn es muss auf allen Maschinen ein erfolgreicher COMMIT garantiert werden. Die Slaves informieren nach einem erfolgten Schreibzugriff den Master von der Transaktion, so dass weitere Schreibtransaktionen ausgeführt werden können. Dieses Verfahren wird Zwei-Phasen-Commit genannt, da der Master jedesmal auf die Slaves warten muss, bevor eine Transaktion endgültig für den gesamten Rechnerverbund als commited markiert wird. So wird zwar eine sofortige Replikation des Datenbestandes erreicht, allerdings auf Kosten des Durchsatzes, da diese Transaktion eben auf jedem Rechner erfolgen und der Erfolg an den Master zurückgemeldet werden muss.
Synchrone Replikation mit Pgpool
Pgpool fungiert als sogenannter Connection Pool, d.h. er klinkt sich zwischen den eigentlichen PostgreSQL-Server und die Anwendungen ein. Dies funktioniert im Prinzip wie bei einem transparenten Proxy. Pgpool cached Verbindungen zum Datenbankserver, um so Lasten durch Verbindungsauf- und -abbau zu reduzieren. Weiterhin kann sich Pgpool mit zwei PostgreSQL-Servern verbinden und und so im Falle eines Ausfalls auf den anderen, noch funktionierenden, Server umschalten.
