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.
Zwischen den beiden PostgreSQL-Servern kann Pgpool außerdem als synchroner Replikationsserver fungieren, d.h. alle Datenbankenanfragen werden an beide Postmaster geschickt. Dies ermöglicht eine einfache Replikation des Datenbestandes auf zwei verschiedene Rechner, die lediglich durch das Netzwerk miteinander verbunden sein müssen. Diese Methode schließt allerdings einige Operationen aus, die bspw. abhängig vom Server (Abfrage der OID, eines Zeitstempels oder ähnliches) oder eben nicht deterministisch (z.B. Zufallsgenerator) sind.
Pgpool lässt sich in NetBSD und auch anderen Systemen mit pkgsrc aus pkgsrc/databases/pgpool installieren. Einige Linux-Distributionen haben es ebenfalls im Angebot. Zur Konfiguration genügt es, /usr/pkg/share/examples/pgpool.conf.sample nach /usr/pkg/etc/pgpool.conf zu kopieren (unter Linux dürfte dies meist /etc/pgpool.conf sein) und anzupassen. Die Konfigurationsdatei ist wohldokumentiert und recht einfach zu verstehen. Wichtig sind folgende Optionen:
listen_addressesundport: zu benutzende Netzwerkadresse und Portbackend_host_nameundbackend_port: Netzadresse und Port des PostgreSQL-Serverssecondary_backend_host_nameundsecondary_backend_port: Netzadresse und Port des zweiten PostgreSQL-Servers (Slave)replication_mode: Einsatz als Replikationssystemreplication_strict: Wenn aktiviert, werden Deadlocks vermieden, was auf Kosten des Durchsatzes geht.replication_timeout: Wennreplication_strictdeaktiviert ist, könnten Deadlocks auftreten. Dieser Wert gibt den Timeout in µs an, nachdem die blockierte Transaktion abgebrochen wird.replication_stop_on_mismatch: Der Replikationsmodus soll bei inkonsistenten Daten zwischen Master und Slave abgebrochen werden.
listen_addresses = 'localhost' port = 9999 socket_dir = '/tmp' backend_host_name = '192.168.2.1' backend_port = 5432 backend_socket_dir = '/tmp' secondary_backend_host_name = '192.168.2.2' secondary_backend_port = 5432 replication_mode = true replication_strict = true replication_timeout = 5000 replication_stop_on_mismatch = false reset_query_list = 'ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT' print_http://net-tex.dnsalias.org/~stefan/nt/timestamp = true
Hat man Pgpool wie im Listing oben konfiguriert, kann man sich an localhost:9999 mit dem Datenbankterminal verbinden. Alle DML-Operationen werden dann auf beiden PostgreSQL-Servern ausgeführt.
Mit pgpool switch kann man die Server umschalten, bspw. mit pgpool -s master switch die Verbindung zum Master beenden und auf den Secondary Server umschalten.
Fazit
Es existieren verschiedene Möglichkeiten und Strategien, um PostgreSQL-Datenbestände zu sichern. Welche Variante am besten funktioniert, hängt vom Profil der Datenbank und den Daten ab. Wenn man einfache Datenstrukturen hat und gewisse Datenverluste bei einem Systemausfall verkraften kann, reicht eine regelmäßige Sicherung der Datenbankinhalte mit pg_dump/pg_dumpall beispielsweise via Cron aus.
Sind die Daten wichtiger und nur sehr geringe Verluste vertretbar, oder es besteht der Wunsch, Daten in einen vorigen Zustand versetzen zu können, bieten sich Point-in-Time-Recovery-Methoden an. Diese belasten allerdings unter Umständen die Hardware sehr stark und können Leistungsgrenzen ausreizen. Trotzdem kann man mit PiTR-Methoden nahezu alle Zustände der Datenbank sichern und wiederherstellen.
Nachteil der beiden erstgenannten Methoden ist fehlende »Hot-Standby«-Fähigkeit, d.h. ein Ersatzsystem muss erst mühsam mit den gesicherten Daten versorgt werden. Dies kann vor allem bei PiTR äußerst zeitaufwändig werden. Einzige Möglichkeit eines Hot-Standby-Systems ist die Replikation der Datenbestände auf ein oder mehrere angeschlossene Systeme, da dabei nur maximal die aktuelle offene Transaktion verloren gehen kann. Somit ist es möglich, beliebig viele Ersatzsysteme Gewehr bei Fuß zu halten und im Bedarfsfall sofort einzusetzen.
Trotzdem sollte man auch hier regelmäßig den Haupt-Datenbestand extern sichern, da Replikationen auch fehlschlagen können und die Datenbank-Cluster u. U. nicht mehr synchron sind. Dies muss dann vom Administrator von Hand korrigiert werden und lässt sich am einfachsten mit dem Einspielen einer Sicherung erledigen.
Der Autor
Stefan Schumacher beschäftigt sich in seiner Freizeit mit japanischen Kampfkünsten sowie mit NetBSD und PostgreSQL. Seine persönlichen Webseiten sind unter www.net-tex.de bzw. www.cryptomancer.de erreichbar. Seine PGP-Schlüssel-ID ist 0xB3FBAE33.
