Login
Newsletter
Werbung

So, 15. Juli 2007, 00:00

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.

Sicherung eines PostgreSQL-Servers

Daten vorzuhalten ist die wichtigste Aufgabe eines Datenbankservers. Ebenso wichtig ist, die Integrität der Daten sicherzustellen. Hierzu gehören neben verschiedenen Datenbanktechnologien auch die Möglichkeiten, die Daten zu sichern. Besonders problematisch ist dabei meist die Komplexität der Daten und Metadaten, so dass verschiedene Ansätze zur Sicherung existieren. Dies wäre zum Beispiel die Sicherung der Datenverzeichnisse eines Servers sowie ein logisches Backup, in dem einfach nur die Daten und ggf. Metadaten der Datenbank in eine Textdatei geschrieben werden. Weiterhin unterstützt PostgreSQL sogenannte Write-Ahead-Logs, in denen alle Transaktionen mitgeloggt werden, und den Einsatz von Replikationstechniken, die den Datenbestand auf mehrere Systeme verteilen können.

Den Datenbankcluster sichern

PostgreSQL legt alle Daten - auch die Metadaten - im sogenannten Cluster, also einem bestimmten Verzeichnis, ab. Es ist möglich, dieses Verzeichnis wie normale Dateien zu sichern, nach der Wiederherstellung des Servers zurückzuspielen und PostgreSQL dann mit diesem Cluster zu starten. Damit befindet sich das neue System wieder in exakt demselben Zustand wie das gesicherte, inklusive Rollen-Namen, Passwörter und Zugriffsrechten.

Problematisch bei der Sicherung ist die Konsistenz des Dateisystems, da im Cluster die Schreibaktivität entsprechend hoch ist. Abhilfe schaffen hier Dateisystem-Snapshots (unter NetBSD ist dies fss(4), unter Linux kann man u.a. mit LVM Snapshots machen), die einen konsistenten Zustand des Dateisystems als Pseudogerät einbinden, das anschließend gesichert werden kann. Allerdings wird so nur die Integrität des Dateisystems sichergestellt, nicht jedoch die Integrität der Datenbank. Denn es kann sein, das der Dateisystem-Snapshot zur Laufzeit einer Transaktion erstellt wird. Der so gesicherte Cluster ist inkonsistent und daher nicht brauchbar. Die Datenbanken-Konsistenz kann nur sichergestellt werden, wenn keine Transaktionen laufen, die Datenbank also komplett inaktiv ist - was im Normalfall heißt, dass sie abgeschaltet ist. Es besteht jedoch die Möglichkeit, einen so gesicherten Cluster mit ebenfalls gesicherten Write-Ahead-Logs wieder brauchbar zu machen. Dies wird im Abschnitt »Point-in-Time-Recovery« beschrieben.

Ein gesicherter PostgreSQL-Cluster kann allerdings nur mit genau derselben PostgreSQL-Version gelesen werden, mit der er erzeugt wurde. Dies bedeutet, dass nach einem Totalausfall des Systems wieder die alte PostgreSQL-Version installiert werden muss.

Es empfiehlt sich, den PostgreSQL-Cluster auf eigenen Partitionen, oder besser noch, eigenen Festplatten abzulegen. Dies verringert den Administrationsaufwand und kann den Datendurchsatz des Servers erhöhen.

Seit Version 8.0 unterstützt PostgreSQL sog. Table-Spaces, d.h. dass komplette Datenbanken, aber auch einzelne Tabellen, Indizes oder Schemata auf beliebige Verzeichnisse verteilt werden können. Dies ermöglicht den Einsatz mehrerer Festplatten, was Kapazität und Durchsatz erhöhen kann. Allerdings sollte beim Sichern des PostgreSQL-Clusters dann auch bedacht werden, alle eingesetzten Table-Spaces mitzusichern.

Das folgende Listing zeigt, wie man PostgreSQLs Cluster sichert und wieder zurückspielt. Dabei wird mit fssconfig(8) ein Dateisystem-Snapshot erstellt und mit dump(8) gesichert. Der zweite Teil zeigt die Rücksicherung mit restore(8) und die Konfiguration des neuen Clusters sowie den Start des Servers.

Sichern

NetBSD

fssconfig -x -c fss0 /pgcluster0
dump -0a -f /mnt/nfs/back/pcluster0.0 /dev/fss0
fssconfig -u fss0

Linux

modprobe dm-snapshot
lvcreate --size 2G --snapshot --name snap /dev/vg00/lvol1
dump -0a -f /mnt/nfs/back/pcluster0.0 /dev/mapper/snap
lvremove /dev/vg00/snap

Wiederherstellen

restore -r -f /mnt/nfs/back/pcluster0.0
chown pgsql.pgsql /pgcluster0
su -m pgsql -c 'pg_ctl -D /pgcluster0 -l /pgcluster0/logfile start&'

Point-in-Time-Recovery

Der Einsatz von Point-in-Time-Recovery-Mechanismen (PiTR) ermöglicht das Zurücksetzen der Datenbank in einen konsistenten Zustand, der an einem beliebigen Zeitpunkt vorgelegen hat. Dazu werden in PostgreSQL ab Version 8.0 die sogenannten Write Ahead Logs (WAL) gesichert und somit jede Änderung am Datenbestand mitgeschnitten. Muss das System zurückgesetzt werden, können die Änderungen seit dem letzten Checkpoint abgespielt werden, um einen konsistenten Zustand zu erreichen. Befindet sich ein wie im vorigen Kapitel gesicherter Cluster in einem inkonsistenten Zustand, wird durch Einspielen der WALs ein konsistenter Zustand hergestellt.

Die WALs werden ähnlich einem Journal fortlaufend weitergeschrieben. So werden alle Transaktionen (PostgreSQL behandelt jede DML-Aktion als ACID-konforme Transaktion) protokolliert und können bei Bedarf neu eingespielt werden. Innerhalb einer bestimmten Zeit werden die Transaktionen dann auf den eigentlichen Datenbestand im Cluster übernommen. Dies erhöht sogar den Datendurchsatz, da es einfacher ist, Daten erst einmal einfach an eine Datei anzuhängen, als ständig im Datenbestand der Datenbank hin- und herzuspringen. Datenbestand und Logdateien werden dann ressourcenschonend synchronisiert.

Da alle Transaktionen im Log sequentiell fortgeschrieben werden, würden die Protokolle unaufhörlich wachsen und irgendwann das Dateisystem überlaufen lassen. Daher werden die Logs einfach rotiert, d. h. man definiert einfach, wieviele Dateien es geben soll, und wenn diese Zahl erreicht ist, wird wieder in die erste Datei geschrieben. (Standardmäßig existieren in pg_xlog drei WAL-Dateien mit je 16 MB Größe. Diese Größe kann beim Kompilieren des Servers angegeben werden, die Anzahl in postgresql.conf.) Um die Logdateien zu sichern, muss man daher die Logs vor der Rotation auf einen anderen Datenträger koperien. Dies geschieht, indem man in der Datei postgresql.conf die Option archive_command setzt, so dass die Logdateien vor dem Überschreiben in ein anderes Verzeichnis kopiert werden:

Kommentare (Insgesamt: 0 )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung