PostgreSQL Replikation

Replikation - Lösungen für PostgreSQL

In der PostgreSQL Distribution ist kein Replikationsverfahren enthalten. Die Entwickler von PostgreSQL sehen ihre Aufgabe in erster Linie darin, ein Datenbanksystem zu entwickeln. Obwohl PostgreSQL einige Leistungsmerkmale auf diesem Gebiet enthält, Point in Time Recovery und Warm Standby Datenbanken, sind sie der Ansicht, daß eine umfassende Replikationslösung auf PostgreSQL aufsetzen sollte, anstatt eingebettet zu sein.

Es gibt mehrere Replikations- und Clustering-Lösungen für PostgreSQL, mit unterschiedlichen Architekturen, Replikationsverfahren und Eigenschaften, die im Folgenden kurz beschrieben werden.

• Point in time Recovery
• Warm Standby Datenbank
• Slony
• Mammoth
• High Availability PostgreSQL
• pgpool
• Daffodil replicator
• PGCluster
• Sequoia
• SkyTools
• Postgres-R

Seit der Version 8.0 unterstützt PostgreSQL Point in time Recovery. Auch vor der Version 8 war es schon möglich, eine PostgreSQL Datenbank nach einem Absturz wieder in einen konsistenten Zustand zu bringen. Die Technik dahinter heisst Write Ahead Logging (WAL), bei der alle Transaktionen ab einem konsistenten Zustand (einem sogenannten Checkpoint) in Logfiles gespeichert werden. Nach einem Absturz und dem Neustart des Datenbankservers setzt dieser auf dem letzten Checkpoint auf, liest die Transaktionslogs und führt alle dort protokollierten Transaktionen aus. Damit ist das System wieder in dem Zustand, in dem es vor dem Absturz war.

Neu in PostgreSQL 8.0 ist, dass diese Transaktionslogs archiviert und in einem beliebigen Dateisystem gespeichert werden können. Die Datenbank kann aus dieser fortlaufenden Folge von Transaktionen rekonstruiert werden. Voraussetzung ist ein physikalisches Backup der Datenbank in dem Zustand, in dem die Archivierung der Logfiles begonnen wurde. Dieses Backup repräsentiert den Startzustand der Datenbank für die Wiederherstellung, auf dem die Transaktionslogs der Reihe nach wieder eingelesen werden. Wenn Zeit bei der Rekonstruktion einer Datenbank eine untergeordnete Rolle spielt ist dies eine einfache Alternative, die ohne zusätzliche Downloads und Installationen auskommt. Allerdings werden mit dieser Technologie alle Transaktionen protokolliert, so dass keine Tabellen explizit zur Replikation ausgewählt werden können.

Die fortlaufendende Archivierung der Transaktionslogs (falls Point in Time Recovery aktiviert wurde) ermöglicht die Einrichtung und Konfiguration von Hochverfügbarkeitslösungen für PostgreSQL mit einem oder mehreren Standby-Servern. Bei einem Ausfall des Hauptservers kann auf einem dieser Standby-Servern weitergearbeitet werden. Bekannt ist dieses Verfahren als Warm Standby Log Shipping. Beide Server müssen dieselbe PostgreSQL-Version installiert haben und sollten so ähnlich wie möglich konfiguriert sein.

Der primäre PostgreSQl-Server protokolliert und archiviert alle seine Transaktionen, während der sekundäre Server in einem Recovery-Modus arbeitet. (Auf den Server, der im Recovery-Modus arbeitet, kann nicht zugegriffen werden.) Das bedeutet, dass er ständig die Transaktionslogs des primären Servers liest und dann seinerseits die dort verzeichneten Transaktionen ausführt.

Änderungen in der Struktur einer PostgreSQL Datenbank oder in Tabellen sind zum Betrieb einer Warm-Standby-Datenbank nicht notwendig, so dass der Einrichtungs- und Wartungasaufwand im Vergleich zu anderen Replikationslösungen sehr gering ist. Ausserdem wirkt sich diese Methode kaum auf die Leistung des primären Servers aus.

Die Auslieferung der Transaktionslogs geschieht in PostgreSQL so, dass der Sekundärserver eine Log-Datei nach der anderen, asynchron, vom Primärserver liest, wobei die räumliche Distanz zwischen den Servern keine Rolle spielt. Die benötigte Bandbreite für diese Datenübertragung hängt von der Anzahl der Transaktionen des primären Servers ab.

Der Überschneidungspunkt, an dem die Server verknüpft sind, ist das Archiv, in dem der primäre PostgreSQL-Server seine Transaktionslogs speichert und auf das alle beteiligten Server Zugriff haben. Der Primärserver schreibt in dieses Verzeichnis und die Sekundärserver lesen daraus die Transaktionslogs.

Ein Sekundärserver wartet dabei auf das nächste WAL-Archiv und übernimmt es mit seiner restore-Routine (restore_command in der recovery.conf). Fällt der Primärserver aus, muss der Sekundärserver den Recovery-Modus beenden und die normale Arbeit aufnehmen. Diese Routinen müssen vom Anwender implementiert werden.

http://www.slony.info

• Open Source
• kostenlos
• asynchron
• Single Master to multiple Slaves, Slaves können kaskadiert werden, um die Last auf mehrere Slaves zu verteilen.
• benutzt Trigger
• Replikation auf Tabellenebene
• keine exklusiven Locks notwendig
• kann Schemaänderungen replizieren
• alle Tabellen müssen einen Primärschlüssel haben
• alle Knoten im Netzwerk müssen immer erreichbar sein
• kann keine Large Objects replizieren
• kein automatischer Failover

Tabellen, die repliziert werden sollen, können zu verschiedenen Gruppen zusammengefasst werden und Änderungen in diesen Gruppen müssen nicht gleichermaßen (im Gießkannenprinzip) auf alle Slaves verteilt werden. Jede dieser Gruppen hat einen ausgezeichneten Knoten, dessen Daten von Anwendungen modifiziert werden dürfen. Slaves müssen sich bei diesem Knoten für die Gruppe anmelden, deren Daten sie duplizieren möchten.

Jedem Knoten ist ein slon-Prozess zugeordnet, der, ereignisgesteuert, die Replikation für diesen Knoten ausführt. Mehrere Transaktionen (Änderungen beim Master) werden gruppiert und mit einem SYNC-Ereignis auf die Slaves repliziert.

Seit der Version 1.1 besteht auch die Möglichkeit, Änderungen zu serialisieren und in Logdateien zu schreiben, die dann zu den Slaves transferiert werden.

Jeder Knoten im Netz kann zum Master werden und synchronisiert sich danach eigenständig mit dem Knoten, der den aktuellsten Datenbestand hat. Dieser Switch Over erfolgt nicht automatisch, sondern muss vom Administrator initiiert werden.

Mehr Informationen unter:
http://main.slony.info/
http://linuxfinances.info/info/slony.html
http://www.varlena.com/varlena/GeneralBits/63.php

http://www.commandprompt.com/products/mammothreplicator/

• kommerziell
• asynchron
• Single Master to multiple Slaves (bis zu 50 Slaves)
• Replikation auf Tabellen- und Schemaebene
• arbeitet ohne Trigger oder cron und ohne exklusive Locks, sondern liefert Log-Dateien an die Slaves aus
• unterstützt mehrere Replikationsmodi: Batch-Modus und Continuous-Modus
• unterstützt SSL
• alle Tabellen müssen Primärschlüssel (auch über mehrere Spalten) haben
• Tabellen dürfen keine Vererbung nutzen
• kein automatischer Failover
• verfügbar für Linux, FreeBSD, Solaris, Win32
• kann mit Heartbeat oder anderer Failover-Software kombiniert werden

Mammoth Replicator wird als PostgreSQL-Server ausgeliefert, in den Replikationsmodule einkompiliert sind, zusammen mit einer Anwendung namens mcp-Server (Mammoth command Processor). Mammoth überwacht die Änderungen in den zur Replikation ausgewählten Tabellen auf dem Master und speichert alle Änderungen in einer Log-Datei, die auf der Slave-Seite von einem Restore-Modul restauriert werden. Diese Änderungen können entweder kontinuierlich oder im Batch-Modus an die Slaves weitergereicht werden. Der Datenaustausch zwischen dem Master und den Slaves wird vom mcp-Server gesteuert, der ein globales TransaktionsLog verwaltet,das mit den Änderungen vom Mster aktualisiert wird. Über diesen Server können Master und Slave miteinander kommunizieren und die Aktualisierungen vom Master zum Slave ausführen.

http://www.taygeta.com/ha-postgresql.html

• asynchron
• ein Master, ein Slave
• automatischer Failover

Das HA-PostgreSQL-System umfasst zwei Server, auf denen heartbeat (http://linux-ha.org/) installiert ist. Der Master ruft in periodischen Abständen rsync auf, um den Slave zu synchronisieren. Bei einem Ausfall des Masters übernimmt der Slave automatisch. Alle Änderungen, die zwischen der letzten Synchronisation und der Übernahme durch den Slave durchgeführt wurden, gehen verloren.

http://pgpool.projects.postgresql.org/

pgpool ist ein Connection-pool-Server für PostgreSQL, der zwischen Clients und Datenbankservern sitzt ist und auch zur Replikation benutzt werden kann.

• Open Source, BSD-license
• kostenlos
• synchron
• automatischer Failover gegenwärtig für zwei PostgreSQL Datenbankserver
• arbeitet auf Basis von Anfragen
• unterstützt Load Balancing
• zeitgesteuerter Switch Over

pgpool ist ein Connection-Pool-Server für PostgreSQL, der als Proxy zwischen Clients und Datenbankservern sitzt und auch zur Replikation benutzt werden kann. In diesem Modus werden alle Datenbankabfragen synchron an beide Datenbankserver gesendet, wodurch beide Datenbanken immer synchronisiert sind. Wenn ein Server ausfällt, löst pgpool diese Verbindung und arbeitet mit dem verbleibenden Server weiter.

Nach einem Ausfall eines Servers müssen beide Datenbanken synchronisiert werden, bevor pgpool wieder zur Replikation eingesetzt werden kann. Die empfohlene Methode ist, den überlebenden Server herunterzufahren, ein Backup zu erstellen und dieses auf dem anderen Server einzulesen. Danach können beide Datenbankserver und pgpool wieder gestartet werden.

http://enterprise.replicator.daffodilsw.com/

• Open Source (GPL)
• asynchron
• Master to multiple Slaves
• Replikation auf Tabellenebene
• unterstützt bidirektionale Synchronisation der Daten
• Snapshot-Modus und Merge-Modus
• setzt keine Locks
• kann auch in heterogenen Architekturen eingesetzt werden
• Plattformunabhängig

Dieser Replikator arbeitet nach dem "Publish and Subscribe"-Modell. Änderungen, die entweder vom Publisher oder vom Subscriber in den zur Replikation ausgewählten Tabellen gemacht wurden, werden überwacht. Sowohl Publisher als auch Subscriber werden dann, entweder in periodischen Abständen, oder auf Anforderung eines Subscribers, synchronisiert. Da es dabei zu konkurrierenden Zugriffen kommen kann, wurden Algorithmen zur Auflösung von Konflikten Implementiert.

http://pgcluster.projects.postgresql.org/1_3/index.html

• Open Source (BSD-license)
• kostenlos
• synchron
• Replikation auf Tabellenebene
• Multi Master, zwei oder mehrere Datenbankserver können simultan Anfragen von Clients erhalten.
• Replikation basiert auf Anfragen, diese werden innerhalb einer Gruppe von Datenbankservern von Server zu Server gesendet.
• kann Sequenzen replizieren, Daten vom Typ serial werden synchronisiert.
• kann Large Objects replizieren

PGCluster kann entweder zur Lastverteilung oder zur Replikation eingesetzt werden. In diesem Fall werden drei Komponenten gebraucht: ein Load-Balancer, ein Cluster-DB-Server und ein Replikator. Der Cluster-DB-Server kann auf drei oder mehr Maschinen installiert werden.

Anfragen von Clients kommen beim Load-Balancer an und werden von dort an den Datenbankderver weitergeleitet, der die geringste Last hat. Der Replikator sendet diese Abfrage an jede Datenbank weiter. Um die Reihenfolge der Abfragen einzuhalten, benutzt er dazu eine Queue. Fällt eine dieser Datenbanken aus, lösen Load-Balancer und Replikator ihre Verbindungen zu ihm und arbeiten mit den verbleibenden Datenbankservern weiter. Es ist auch möglich, mehrere Replikationsserver zu installieren. Fällt der primäre Replikationsserver aus, verbinden sich die Cluster-DB-Server automatisch mit dem sekundären Replikationsserver. Fallen alle Replikationsserver aus, kann PGCluster in einem standalone-Modus weiterarbeiten.

Fügt man den vorher getrennten Datenbankserver oder auch einen neuen Server in den Cluster ein, übernimmt der Replikator deren Synchronisation.

Der grösste Nachteil von PGCluster ist, dass es nicht mit einer vorhandenen Datenbankinstallation zusammenarbeiten kann, sondern eine modifizierte Version von PostgreSQL verwendet. Diese ist nicht immer auf dem neuesten Stand ist.

http://sequoia.continuent.org/HomePage
ist eine Weiterentwicklung von:
http://c-jdbc.objectweb.org/

• Open Source
• Plattformübergreifend, da in Java geschrieben. (JRE 1.4 oder höher ist erforderlich.)
• Bestehende Datenbanken oder Anwendungen müssen nicht verändert werden.
• Integrierte JMX-basierte Administration und Monitoring
• Load-Balancing, Failover und Result-Caching

Sequoia ist eine Middleware zum Aufbau von Datenbank-Clustern, zur Lastverteilung und Failover. Datenbanken können auf mehrere Server verteilt und repliziert werden und Abfragen können auf diese verschiedenen Knoten verteilt werden. Netzwerkfehler oder Serverausfälle werden erkannt und ein Failover angestossen.

https://developer.skype.com/SkypeGarage/DbProjects/SkyTools und
http://pgfoundry.org/projects/skytools/

SkyTools ist eine Sammlung von Tools, mit denen Skype seine Datenbankcluster verwaltet. Darin enthalten ist Londiste, eine einfache, in Python geschriebene Replication Engine. Ein HowTo zu Londiste finden Sie unter http://pgsql.tapoueh.org/londiste.html. Ein weiteres Tool ist WalMgr, ein ebenfalls in Python geschriebenes Skript für Hot Failover. https://developer.skype.com/SkypeGarage/DbProjects/SkyTools/WalMgr enthält eine Dokumentation zum WalMgr.

http://www.postgres-r.org/

• synchron
• Postgres-R kann Lesezugriffe auf beliebige Server verteilen.

Postgres-R ist eine Erweiterung für PostgreSQL, mit der Datenbankcluster schnell und effizient repliziert werden können. Load Balancing und Hochverfügbarkeit von Datenbanksystemen sind die Hauptaufgaben von Postgres-R. Dank seiner flexiblen Architektur kann der Replikationsprozess einfach erweitert oder angepasst werden.

Daten können auf mehrere Server repliziert werden und neue Server können im laufenden Syswtem einfach eingefügt oder wieder entfernt werden. Serverausfälle werden automatisch erkannt und aus dem Verbund entfernt, so dass sie das laufende Datenbanksystem nicht beeinträchtigen.

Die Dokumentation finden Sie unter http://www.postgres-r.org/documentation/

Unter einem Failover ist der ungeplante Wechsel von einem Primärserver zu einem zweiten Standby-System zu verstehen. Unternehmenskritische Anwendungen wie SAP, Datenbank, Webserver oder Mail können auf diese Weise auch bei einem Ausfall eines Rechners weiter zur Verfügung gestellt werden, da das Zweitsystem im Fehlerfall die Aufgaben des Primärsystems übernimmt.

Unter einem Switchover ist in der Informationstechnik ein Wechsel von einem Primärsystem zu einem Standby-System zu verstehen. Anders als bei einem Failover, mit dem ein ungeplanter Wechsel zum Standby-System bezeichnet wird und zum Beispiel aufgrund des Ausfalls des Primärsystems oder des Netzwerks zum Primärsystem auftritt, wird unter einem Switchover ein geplanter Wechsel verstanden, der gezielt von einem Systemadministrator initiiert wird.