PostgreSQL: Failover- vs. Switchover-Szenarien verstehen und ausführen

In modernen Datenbankarchitekturen ist die Sicherstellung des kontinuierlichen Betriebs durch Hochverfügbarkeit (HA) von größter Bedeutung. PostgreSQL, eine leistungsstarke relationale Open-Source-Datenbank, nutzt Streaming-Replikation, um die Datenkonsistenz über mehrere Knoten hinweg zu gewährleisten. Wenn der Primärserver jedoch auf ein Problem stößt oder Wartungsarbeiten erfordert, müssen Datenbankadministratoren präzise Verfahren ausführen, um den Dienst wiederherzustellen. Dieser Artikel unterscheidet klar zwischen zwei kritischen HA-Operationen – Failover und Switchover – und beschreibt die Schritte und Überlegungen zur sicheren Promotion einer Standby-Replik zum neuen Primärserver.

Das Verständnis des Unterschieds zwischen diesen Ereignissen ist entscheidend. Ein Switchover ist ein geplanter, kontrollierter Übergang, während ein Failover eine Notfallreaktion auf einen unerwarteten Ausfall ist. Die erfolgreiche Bewältigung beider Szenarien hängt stark von der richtigen Konfiguration, einem robusten Monitoring und der Vertrautheit mit den zur Replikationsverwaltung verwendeten Tools ab.

Grundlagen der Replikation: Das Fundament der HA

Die Hochverfügbarkeit von PostgreSQL basiert auf Streaming-Replikation, wobei ein Server als Primärserver (oder Master) und ein oder mehrere Server als Standbys (oder Replikate) fungieren. Der Primärserver streamt Write-Ahead-Log (WAL)-Einträge an die Standbys, um diese synchron zu halten.

Um diese Rollen effektiv zu verwalten, sind auf Primär- und Replikatknoten spezifische Konfigurationseinstellungen erforderlich:

Kritische Konfigurationseinstellungen

Diese Einstellungen regeln, wie die Replikation funktioniert und wie sich Knoten gegenseitig identifizieren:

• wal_level: Muss auf dem Primärserver auf replica oder höher (idealerweise logical, wenn Tools verwendet werden, die logische Dekodierung erfordern) eingestellt sein.
• max_wal_senders: Definiert die maximale Anzahl gleichzeitiger Verbindungen von Standbys. Muss vom Standardwert (normalerweise 10) erhöht werden, um alle Standbys aufzunehmen.
• hot_standby: Muss in der postgresql.conf des Standby-Servers auf on gesetzt sein, um während der Replikation schreibgeschützte Abfragen zu ermöglichen.
• synchronous_commit: Steuert die Transaktionsbestätigung. Für null Datenverlust während Switchovers wird dies oft auf on (oder remote_write für geringe Latenztoleranz) gesetzt.
• primary_conninfo: Wird auf dem Standby gesetzt und enthält detaillierte Verbindungsinformationen (Host, Port, Benutzer, Passwort) zum aktuellen Primärserver.

Best Practice: Für robuste HA sollten Connection-Pooling-Layer (wie PgBouncer oder dedizierte HA-Proxys wie Patroni oder Repmgr) verwendet werden, die die physischen Serveradressen abstrahieren und Failover und Switchover für Anwendungen nahtlos gestalten.

Switchover: Der geplante Übergang

Ein Switchover ist ein kontrollierter, reibungsloser Prozess, bei dem der aktive Primärknoten absichtlich außer Betrieb genommen und ein designierter Standby zu dessen Ersatz befördert wird. Dieses Verfahren wird typischerweise für geplante Wartungsarbeiten, Versions-Upgrades oder Hardwareaustausch verwendet.

Schritte für einen kontrollierten Switchover

Das Ziel eines Switchovers ist es, keinen Datenverlust zu gewährleisten, indem darauf gewartet wird, dass alle laufenden Transaktionen repliziert wurden, bevor die Promotion erfolgt.

1. Schreibzugriffe auf dem aktuellen Primärserver stoppen: Der erste Schritt besteht darin, zu verhindern, dass neue Transaktionen auf dem aktuellen Primärserver festgeschrieben werden. Dies wird oft durch Setzen von default_transaction_read_only = on oder durch vorübergehendes Beenden der Client-Verbindungen erreicht.
2. Auf Replikations-Catch-up warten: Stellen Sie sicher, dass der designierte Standby alle verbleibenden WAL-Einträge vom Primärserver empfangen und angewendet hat. Sie können die Replikationsverzögerung mithilfe von pg_stat_replication auf dem Primärserver überprüfen oder den Wiederherstellungsstatus des Standbys untersuchen.
3. Standby-Promotion initiieren: Führen Sie den Befehl aus, um den ausgewählten Standby-Server zur Primärrolle zu befördern. Der spezifische Befehl hängt vom verwendeten Verwaltungstool ab (z.B. pg_ctl promote oder ein Cluster-Manager-Befehl).
4. Alten Primärserver neu konfigurieren: Sobald der Standby erfolgreich befördert wurde, muss der alte Primärserver neu konfiguriert werden, um dem neuen Primärserver als Standby zu folgen. Dies beinhaltet die Aktualisierung seiner primary_conninfo.
5. Anwendungen umleiten: Aktualisieren Sie den Load Balancer oder Connection Pooler, um den Datenverkehr auf den neuen Primärserver umzuleiten.

Failover: Die Notfallreaktion

Ein Failover ist ein unmittelbares, reaktives Verfahren, das ausgelöst wird, wenn der aktuelle Primärserver unerwartet ausfällt (z.B. Hardware-Crash, Netzwerkpartitionierung, Softwarefehler) und nicht schnell wieder online gebracht werden kann.

Ein Failover birgt von Natur aus ein höheres Risiko für Datenverlust, da nicht garantiert ist, dass die letzten festgeschriebenen Transaktionen Zeit hatten, zu den Standbys gestreamt zu werden, bevor der Fehler auftrat.

Ausführen eines Notfall-Failovers

Failover-Verfahren sind auf Geschwindigkeit und Wiederherstellung ausgelegt und nutzen oft spezielle Tools zur Automatisierung der Promotion.

1. Den Zustand des alten Primärservers bestimmen: Überprüfen Sie, ob der ursprüngliche Primärserver wirklich nicht verfügbar ist und nicht nur ein temporäres Netzwerkproblem aufweist (dies verhindert gefährliche 'Split-Brain'-Szenarien).
2. Den besten Standby auswählen: Wählen Sie den Standby mit der geringsten Replikationsverzögerung (denjenigen, der im WAL-Stream am weitesten fortgeschritten ist).
3. Den Standby befördern: Befördern Sie den ausgewählten Standby sofort mit dem Promotion-Befehl (pg_ctl promote).
4. Datenverlust handhaben (falls erforderlich): Wenn der Cluster asynchrone Replikation verwendet, müssen die auf dem ausgefallenen Primärserver verlorenen Daten möglicherweise manuell abgeglichen oder einfach akzeptiert werden, abhängig von der Toleranz der Anwendung.
5. Ehemaligen Primärserver neu konfigurieren: Sobald der ursprüngliche Primärserver wiederhergestellt ist, muss er bereinigt, neu initialisiert (oftmals erfordert dies ein Base Backup vom neuen Primärserver) und so konfiguriert werden, dass er dem neuen Primärserver folgt.

Tools für sichere Promotion: Repmgr vs. Patroni

Obwohl eine manuelle Promotion mit pg_ctl möglich ist, verlassen sich robuste HA-Umgebungen auf dedizierte Tools, um die komplexe Choreografie für Failover und Switchover zu verwalten, indem sie Konfigurationsänderungen und das Cluster-Statusmanagement automatisch handhaben.

Repmgr (Replikations-Manager)

repmgr ist ein leistungsstarkes, leichtgewichtiges Tool, das die Replikation überwacht und manuelle oder automatische Failover erleichtert. Wichtige Befehle sind:

• Switchover: repmgr standby promote gefolgt von repmgr switchover --sibling-nodes-wait (um das Catch-up sicherzustellen).
• Failover: repmgr failover

Patroni

Patroni nutzt verteilte Konsensspeicher (wie etcd, ZooKeeper oder Consul), um den Cluster-Zustand zu verwalten und bei Fehlererkennung automatisch einen neuen Primärserver zu wählen. Patroni automatisiert Switchovers und Failovers weitgehend durch API-Aufrufe oder Kubernetes-Operatoren, wodurch manuelle Eingriffe drastisch reduziert werden.

Beispiel mit Patroni (konzeptioneller Promotion-Befehl):

# Triggering a switchover via Patroni's REST API
curl -X POST http://patroni-api-endpoint/switchover -H "Content-Type: application/json" -d '{"target": "standby_node_name"}'

Warnung vor Split-Brain: Die größte Gefahr während eines automatisierten Failovers ist das 'Split-Brain'-Szenario, bei dem zwei Knoten fälschlicherweise glauben, sie seien der Primärserver, aufgrund von Netzwerkpartitionierung. Tools wie Patroni mindern dies durch Quorum-Mechanismen, während manuelle Setups strenge Fencing-Mechanismen (wie Stromsteuerungen) erfordern, um sicherzustellen, dass nur ein Primärserver existiert.

Zusammenfassung der Unterschiede

Die Durchführung von PostgreSQL Failovern und Switchovern erfordert ein tiefes Verständnis des Cluster-Zustands und der Tools, die ihn verwalten. Während Switchovers durch Koordination keinen Datenverlust anstreben, priorisieren Failover eine schnelle Wiederherstellung des Dienstes, oft auf Kosten der allerletzten Transaktionen. Die richtige Einrichtung von Replikationsparametern und die Nutzung robuster Cluster-Management-Tools sind die Eckpfeiler einer zuverlässigen PostgreSQL-Hochverfügbarkeit.