Backup einer großen PostgreSQL Datenbank
Um eine Datenbank zu sichern, wird üblicherweise ein SQL Dump erzeugt, welcher dann bei einem Ausfall wieder eingespielt werden kann. Bei kleineren Datenbank ist das auch durchaus ein guter Weg. Wenn allerdings eine Datenbank z.B. größer als 20GB wird, dann dauert der Dump extrem lange und belastet das System.
PostgreSQL bietet aber auch die Möglichkeit im Betrieb ein sogenanntes Write-Ahead-Log (WAL), neben den eigentlichen Datenbestand, auf die Festplatte zu schreiben. Es enthält alle Aufzeichnungen sämtlicher im Datenbanksystem vorgenommenen Schreiboperationen. Falls das System ausfällt, können diese Aufzeichnungen verwendet werden, um die Datenbank wieder herzustellen. Es handelt sich hierbei um das gleiche Prinzip wie ein “Journal” von Linux Dateisystemen.
Eigentlich wird das Write-Ahead-Log in regelmäßigen Abständen mit dem Datenbestand abgeglichen und wieder gelöscht, da es nicht mehr benötigt wird. Es kann aber auch für eine Datensicherung verwendet werden. Die Aufzeichnungen bestehen aus Segmenten, je 16MB groß und im Verzeichnis pg_xlog zu finden.
Um eine Datensicherung mit WAL zu betreiben, braucht man als erstes eine Basissicherung. Hierfür kann ein einfaches Shellscript verwendet werden:
#!/bin/sh
set -e
filename=/data/wal_archive/basebackup_`hostname`_$(date +'%Y-%m-%dT%H%M%S.%N%z').tar.gz
psql -U postgres -c "SELECT pg_start_backup('$filename');" > /dev/null
tar --force-local -C /data -c -z -f "$filename" --anchored --exclude=pg_xlog pgsql || [$? -eq 2]
psql -U postgres -c "SELECT pg_stop_backup();" > /dev/null
Mit den PostgreSQL Befehlen pg_start_backup() und pg_stop_backup() kann das komplette Datenbanksystem gesichert werden. Das erzeugte Tarball wird unter /data/wal_archive gespeichert. Die PostgreSQL Installation wird unter /data/pgsql erwartet.
Nachdem die Basissicherung erstellt wurde, kann PostgreSQL für WAL konfiguriert werden. PostgreSQL selber macht hier keine Vorschriften, wie die WAL Segmente archiviert werden sollen, es können beliebige Shell Befehle aufgerufen werden. Man hat z.B. die Möglichkeit die Segmente einfach mit cp zu kopieren, könnte sie aber auch mit rsync auf einen anderen Rechner schieben. Die Konfiguration wird in der Datei postgresql.conf vorgenommen:
archive_mode = on
archive_command = 'test ! -f /data/wal_archive/%f && cp %p /data/wal_archive/%f'
Es ist hier wichtig, dass keine vorhandenen Dateien überschrieben werden, deshalb wird vor dem kopieren getestet, ob die entsprechende Datei schon vorhanden ist. Der Platzhalter %f ist der Dateiname für die Zieldatei, %p ist die zu kopierende Datei mit vollständigem Pfad.
Nachdem PostgreSQL neu gestartet wurde, werden die WAL Dateien, sofern 16MB Daten geschrieben wurden nach /data/wal_archive kopiert. Es ist nicht möglich, kleinere Datei zu schreiben, deswegen besteht das Risiko max. 16MB an Daten zu verlieren, wenn der Server stirbt und die WAL Datei noch nicht geschrieben hat. Es gibt allerdings die Möglichkeit einen Timeout zu setzen, nach welchem auf jeden Fall das Segment geschrieben werden soll.
Hierdurch würden alle 60 Sekunden ein Segment geschrieben werden, auch wenn keine Schreiboperation durchgeführt würde! Das Segment ist dann trotzdem 16MB groß, und mit NULL Daten gefüllt. Es ist also abzuwägen ob und wie hoch der Timeout sein soll.
Grundsätzlich sichere ich die WAL Segmente großer Datenbank auf einen anderen Server, damit das Hauptsystem nicht durch das Backup bzw. den erhöhten Speicherbedarf belastet wird. Einerseits kann das Segment auf ein mit NFS eingehängtes Volumen gespeichert werden, oder es wird mit scp oder rsync kopiert. Der archive_command Aufruf für rsync könnte wie folgt ausehen:
archive_command = 'rsync --delay-updates --whole-file -ar -e ssh %p postgres@192.168.0.2:/data/wal_archive/%f </dev/null'
Die Segmente werden dann automatisch in das Verzeichnis /data/wal_archive auf dem Server 192.168.0.2 kopiert. Es sollte allerdings ein SSH-Key ohne Passwort auf dem Zielsystem für den Benutzer postgres hinterlegt sein.
Für die eigentliche Sicherung muss nur nach das Verzeichnis /data/wal_archive auf dem Server 192.168.0.2 eingetragen werden. Zugegeben, diese Art von Datensicherung verbraucht viel Speicherplatz, da die Festplattenpreise allerdings sehr niedrig sind und das Datenbanksystem kaum belastet wird, rechtfertigt sich der hohe Speicherbedarf durchaus.
|
Kommentar hinzufügen