Warm Stand-by

Da die Datenbank beim Wiederherstellen nach dem Log Shipping-Verfahren die komplette Transaktionshistorie abspielen muss, eignet sich dieser Mechanismus nicht für zeitkritische Umgebungen. Wenn das letzte Base Backup mehrere Tage alt ist und seitdem mehrere hundert MByte an WAL-Logs angefallen sind, kann das Recovery bis zum aktuellen Zeitpunkt schlimmstenfalls Stunden dauern. Um im Hochverfügbarkeitsbereich Datenbanken ohne verteilte Dateisysteme (NFS oder Cluster-Dateisysteme) beziehungsweise geteilte Blockdevices (SAN, DRBD und so weiter) anbieten zu können, wurde bereits PostgreSQL 8.2 um den Warm Stand-by-Server erweitert. Der Mechanismus ist auf der Master-Seite identisch mit dem Log Shipping, PostgreSQL speichert alle abgeschlossenen WAL-Segmente an eine definierte Stelle. Neu hinzugekommen ist ein Restore-Kommando, das als Gegenstück zum »archive command« regelmäßig kontrolliert, ob es neue WAL-Segmente gibt und sie gegebenenfalls sofort einspielt.

Im Warm Stand-by-Modus verwendet PostgreSQL denselben Recovery-Mechanismus, den es auch bei einem unsauberen Shutdown der Datenbank einsetzt. Da dieser Modus sich um einen konsistenten Zustand der Datenbank kümmern soll, kann man in der Zeit, in der die Datenbank Änderungen vom Master übernimmt, keine Anfragen bearbeiten lassen. Dafür muss der Recovery-Prozess erst beendet sein und die Datenbank wieder im Normalbetrieb laufen.

Um die Sache noch mehr zu verkomplizieren, musste man bisher auch in Kauf nehmen, dass eine einmal wiederhergestellte Datenbank, selbst wenn sie anschließend nur gelesen wurde, mit einfachen Mitteln nicht wieder in den Replikationsmodus zurückversetzt werden konnte. Denn nach Wiederaufnahme des Online-Betriebs hätte PostgreSQL keine Datenintegrität mehr garantieren können, weil selbst reine Lese-Zugriffe Daten verändern konnten. Deshalb verweigerte PostgreSQL die Fortsetzung der Replikation.

Um dieses Problem handhabbar zu machen wurden auf Warm Stand-by Datenbanken zumeist Snapshots auf Dateisystem- oder Blockdevice-Ebene erstellt, wenn die Datenbank kurzfristig für Abfragen benötigt wurde. Für den HA-Einsatz war diese Variante jedoch nicht ohne zusätzliche Skripte geeignet. Da der SlaveServer immer nur das letzte abgeschlossene WAL-Segment des Masters zur Verfügung hatte, konnte bei einem Komplettverlust des Masters durchaus eine relevante Datenmenge verloren gehen. All diese Probleme behebt PostgreSQL 9. Es beseitigt die größten Unannehmlichkeiten für Log Shipping mit Stand-by Servern. Die Verbesserungen fußen auf zwei wesentlichen Neuerungen: Hot Standby und Streaming Replication.

Neu: Hot Stand-by

Bisher gab es für Warm Stand-by-Server nur die Möglichkeit, entweder im Recovery-Modus Änderungen vom Master Server einzuspielen, oder online zu arbeiten und Anfragen zu beantworten. Nach dem Online-Betrieb ließ sich der Recovery-Modus nur mit einigem Aufwand wieder reaktivieren.

Mit PostgreSQL 9 wurde der neue Betriebsmodus Hot Stand-by eingeführt, der es Slave-Servern erlaubt, lesende Anfragen im Recovery-Modus zu beantworten. Außerdem erweitert nun die so genannte Streaming Replication den bisherigen WALTransfermechanismus um eine zusätzliche Variante (neben Archive- und Restore-Kommando). Damit ist es möglich, eine direkte TCP-Verbindung zwischen Master & Slave einzurichten, über die der Slave-Server bereits abgeschlossene WAL-Segmente nachladen kann. Zusätzlich werden alle Transaktionen aus dem derzeit aktivem WAL-Segment automatisch und zeitnah zum Slave weitergeleitet. Mit Hot Stand-by & Streaming Replication ist es jetzt möglich, nur mit PostgreSQL-Bordmitteln ein Replikationssetup zu betreiben, das sich mit bekannten Varianten in der Datenbanklandschaft gut messen 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