Asynchrone Replikation in PostgreSQL 9

Asynchrone Replikation in PostgreSQL 9

Nachdem das PostgreSQL Core Team Replikation lange für eine Angelegenheit von Drittanbietern hielt, entschloss es sich im Jahr 2008, dem Wunsch vieler Anwender zu folgen und eine Replikationslösung zu integrieren, die schließlich in PostgreSQL 9 Teil der Datenbank wurde.

Wer von Datenreplikation spricht, meint zumeist mehrfach in verschiedenen Systemen oder sogar an verschiedenen Orten gespeicherte Daten, die sich auf definierte Weise synchronisieren lassen. Sobald man die Daten aber an mehr als einem Ort speichert, ergeben sich zwangsläufig auch Probleme wie: Welche Kopie darf der Anwender lesen? Wie aktuell sind die Daten der einzelnen Knoten? Wie und wo lassen sich Daten ändern?

Replikationsvarianten

Die Antworten hängen stark vom Replikationsverfahren ab, und davon gibt es mehrere. Die absolute Königsdisziplin ist eine synchrone Master-Master-Replikation – jeder Knoten im System ist hier komplett gleichwertig, man darf auf jedem Knoten schreiben, jede Änderung erscheint gleichzeitig auf allen anderen Knoten und macht Konfliktlösungsmechanismen überflüssig. Eine solche Master-Master-Replikation ist gleichzeitig auch die schwierigste Variante und etwas, das bisher nur wenige kommerzielle Datenbankhersteller zufriedenstellend umsetzen konnten. Deutlich leichter realisierbar ist eine andere Variante, die asynchrone Master-Slave-Replikation. Dabei gibt es einen designierten Master, der schreibende und lesende Statements verarbeiten kann und seinen Datenbestand asynchron an einen oder mehrere Slave-Knoten weiter verteilt. Die Slaves bekommen Änderungen vom Master in einem solchen Setup zumeist relativ zeitnah mit, es gibt allerdings keinerlei Garantie, dass die Daten des Slave nicht schon Sekunden, Stunden oder sogar Tage alt sind. Diese Unsicherheit kompensieren die meisten Umgebungen durch entsprechende Monitoringsysteme. Außerdem werden die Slaves für sensible Queries extra nicht herangezogen.

Schnittstellen

Auch bei den Schnittstellen, die bei einer Replikation zum Einsatz kommen, sind unterschiedliche Ansätze möglich. Neben fest in die Datenbanken eingebauten Interfaces gibt es auch die Variante, einen Daemon als MiddlewareLayer vor die Datenbank zu schalten. Diese Middleware verhält sich gegenüber dem Client wie eine vollwertige Datenbank, verfügt hat aber selbst nur über eine Liste an nachgeschalteten Datenbanken sowie über ein Regelwerk, anhand dessen sie die Anfragen weiterleitet. Sobald diese Middleware schreibende Statements an mehrere Knoten sendet, ergibt sich bereits eine einfache Replikation. Allerdings muss man bei diesen Systemen aufpassen, dass es keine Drift zwischen den Datenbeständen gibt und dass die Systeme frei von Seiteneffekten sind, die auf unterschiedlichen Knoten zu unterschiedlichen Ergebnissen führen. Ein einfaches Beispiel für Letzteres wäre ein Statement wie beispielsweise »INSERT INTO table (data) VALUES (random());«. Für Datenbanken mit einer stabilen Implementierung von Stored Procedures und Triggern bietet es sich deshalb eher an, die Replikationsschicht direkt in der Datenbank anzulegen: Alle Änderungen am Inhalt der Tabellen schreiben in diesem Fall Trigger automatisch in ein paralleles Log. Separate Daemons außerhalb der Datenbank kümmern sich um das Weiterverteilen dieser Logeinträge an die unterschiedlichen Datenbankknoten. Das ist allerdings mit Abstand der ineffizienteste Replikationsmechanismus, weil die ganze Logik in der SQL-Ebene der Datenbank realisiert ist und alle Änderungen beim Nachführen der Logs auf den einzelnen Knoten mehrfach geschrieben werden müssen. Außerdem bedürfen Änderungen am Datenbankschema ziemlicher Vorsicht. Auf der Plusseite sei vermerkt, dass Trigger-basierte Lösungen extrem flexibel sind und man damit sogar Daten zu Server anderer Datenbankhersteller replizieren kann.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023