PostgreSQL Failover vs. Switchover: Szenarien verstehen und umsetzen

Der Unterschied zwischen PostgreSQL Failover und Switchover ist nicht akademisch, wenn Sie die Person sind, die den Pager hält. Ein Switchover ist geplant: Sie haben noch einen gesunden Primary, Sie können Schreibvorgänge unterbrechen und den besten Zeitpunkt wählen, um die schreibbare Rolle auf einen Standby zu übertragen. Ein Failover ist das, was Sie tun, wenn der Primary ausgefallen, nicht erreichbar oder unsicher ist, um weiterhin Traffic zu bedienen.

Dieser eine Unterschied ändert alles. Während eines Switchovers ist Ihre Hauptaufgabe Geduld: Beweisen Sie, dass der Standby vor der Promotion aufgeholt hat. Während eines Failovers ist Ihre Hauptaufgabe Eindämmung: Stellen Sie sicher, dass der alte Primary nach der Promotion eines Standbys keine Schreibvorgänge mehr akzeptieren kann. Die meisten unangenehmen PostgreSQL-HA-Vorfälle entstehen durch überstürztes Handeln bei einer dieser beiden Aufgaben.

Replikationsgrundlagen: Die Basis für HA

PostgreSQL High Availability basiert auf Streaming-Replikation, bei der ein Server als Primary (oder Master) fungiert und ein oder mehrere Server als Standbys (oder Replicas) dienen. Der Primary streamt Write-Ahead-Log (WAL)-Datensätze an die Standbys, um sie synchron zu halten.

Um diese Rollen effektiv zu verwalten, sind auf Primary- und Replica-Knoten spezifische Konfigurationseinstellungen erforderlich:

Kritische Konfigurationseinstellungen

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

wal_level: Muss auf dem Primary auf replica oder höher gesetzt sein (idealerweise logical, wenn Tools verwendet werden, die logisches Decoding benötigen).
max_wal_senders: Definiert die maximale Anzahl gleichzeitiger WAL-Sender-Verbindungen. Dimensionieren Sie es für alle physischen Standbys, Basis-Backups und Replikationstools, die gleichzeitig verbunden sein könnten.
hot_standby: Muss in der postgresql.conf des Standby-Servers auf on gesetzt sein, um schreibgeschützte Abfragen während der Replikation zu ermöglichen.
synchronous_commit: Steuert, wann eine Transaktion bestätigt wird. Es bietet nur dann eine stärkere Haltbarkeit, wenn die synchrone Replikation korrekt konfiguriert ist; allein macht es keinen Standby aktuell.
primary_conninfo: Wird auf dem Standby gesetzt und enthält Verbindungsinformationen (Host, Port, Benutzer, Passwort) zum aktuellen Primary.

Best Practice: Setzen Sie einen stabilen Endpunkt vor PostgreSQL, wie HAProxy, PgBouncer hinter einer virtuellen IP, einen Service-Discovery-Eintrag oder die Service-Abstraktion Ihrer Plattform. Anwendungen sollten nicht wissen müssen, welcher Knoten heute der Primary ist.

Switchover: Der geplante Übergang

Ein Switchover ist ein kontrollierter, geordneter Prozess, bei dem der aktive Primary-Knoten absichtlich außer Betrieb genommen wird und ein designierter Standby an seine Stelle tritt. Dieses Verfahren wird typischerweise für geplante Wartungsarbeiten, Versionsupgrades oder Hardware-Austausch verwendet.

Schritte für einen kontrollierten Switchover

Das Ziel eines Switchovers ist es, Null Datenverlust zu gewährleisten, indem auf die Replikation aller laufenden Transaktionen vor der Promotion gewartet wird.

Schreibvorgänge auf dem aktuellen Primary stoppen: Der erste Schritt besteht darin, zu verhindern, dass neue Transaktionen auf dem aktuellen Primary festgeschrieben werden. Dies wird oft erreicht, indem default_transaction_read_only = on gesetzt wird oder Client-Verbindungen vorübergehend getrennt werden.
Auf Replikationsnachholung warten: Stellen Sie sicher, dass der designierte Standby alle verbleibenden WAL-Datensätze vom Primary empfangen und angewendet hat. Sie können die Replikationsverzögerung mit pg_stat_replication auf dem Primary oder durch Überprüfung des Wiederherstellungsstatus des Standbys überprüfen.
Standby-Promotion einleiten: Führen Sie den Befehl aus, um den ausgewählten Standby-Server in die Primary-Rolle zu versetzen. Der spezifische Befehl hängt vom verwendeten Verwaltungstool ab (z. B. pg_ctl promote oder ein Cluster-Manager-Befehl).
Alten Primary neu konfigurieren: Sobald der Standby erfolgreich promoviert wurde, muss der alte Primary neu konfiguriert werden, um dem neuen Primary als Standby zu folgen. Dies beinhaltet die Aktualisierung seiner primary_conninfo.
Anwendungen umleiten: Aktualisieren Sie den Load Balancer oder Connection Pooler, um den Traffic auf den neuen Primary-Server zu leiten.

Eine praktische Switchover-Checkliste sieht normalerweise eher alltäglich als dramatisch aus. Kündigen Sie eine kurze Schreibpause an, stoppen Sie Hintergrund-Worker, die weiter schreiben, versetzen Sie die Anwendung in den Wartungsmodus oder leeren Sie den Writer-Pool, und überprüfen Sie dann die Replikationsposition. Auf dem alten Primary zeigt pg_stat_replication, ob der Standby WAL empfangen und geflusht hat. Auf dem Standby helfen pg_last_wal_receive_lsn() und pg_last_wal_replay_lsn(), zu sehen, ob WAL nur angekommen oder tatsächlich abgespielt wurde.

Promoten Sie einen Standby nicht nur, weil er verbunden ist. Ein Standby kann verbunden sein und trotzdem Sekunden oder Minuten hinterherhinken, wenn er eine große Transaktion abspielt, auf Festplatten-I/O wartet oder sich nach einer Netzwerkunterbrechung erholt. Für einen geplanten Switchover möchten Sie, dass das Replay vor der Promotion aufgeholt hat. Wenn auf dem Standby schreibgeschützte Sitzungen laufen, überprüfen Sie auch, ob langlaufende Abfragen das WAL-Replay verzögern.

Testen Sie nach der Promotion die Rolle direkt:

SELECT pg_is_in_recovery();

Der promovierte Knoten sollte false zurückgeben. Der herabgestufte Knoten sollte nach dem Wiederaufbau oder der Umstellung als Standby true zurückgeben.

Die Anwendungsseite verdient die gleiche Sorgfalt. Wissen Sie vor dem Switchover, wie Clients den Writer finden. Wenn sie sich mit einem DNS-Namen verbinden, verstehen Sie den DNS-TTL und ob Clients Adressen länger als erwartet cachen. Wenn sie sich über PgBouncer verbinden, entscheiden Sie, ob Sie den Pool anhalten, neu laden oder neu starten müssen. Wenn Sie HAProxy verwenden, stellen Sie sicher, dass der Health Check den beschreibbaren Status testet, nicht nur, ob Port 5432 offen ist. Ein Standby mit laufendem PostgreSQL ist kein gültiges Schreibziel.

Ich notiere auch gerne den Rollback-Punkt. Vor der Promotion können Sie normalerweise anhalten, Schreibvorgänge auf dem alten Primary wieder öffnen und es später erneut versuchen. Nach der Promotion wird ein Rollback zu einem neuen Rollenwechsel, nicht zu einer einfachen Rückgängigmachung. Das bedeutet nicht, dass die Promotion gefährlich ist; es bedeutet, dass der Operator wissen sollte, auf welcher Seite der Linie er sich befindet.

Failover: Die Notfallreaktion

Failover ist ein sofortiges, reaktives Verfahren, das ausgelöst wird, wenn der aktuelle Primary-Server unerwartet ausfällt (z. B. Hardware-Absturz, Netzwerkpartition, Softwarefehler) und nicht schnell wieder online gebracht werden kann.

Failover birgt inhärent ein höheres Risiko von Datenverlust, da keine Garantie besteht, dass die letzten wenigen festgeschriebenen Transaktionen Zeit hatten, vor dem Ausfall zu den Standbys zu streamen.

Durchführung eines Notfall-Failovers

Failover-Verfahren sind auf Geschwindigkeit und Wiederherstellung ausgelegt und nutzen oft spezialisierte Tools, um die Promotion zu automatisieren.

Gesundheitszustand des alten Primaries bestimmen: Überprüfen Sie, ob der ursprüngliche Primary wirklich nicht verfügbar ist und nicht nur ein vorübergehendes Netzwerkproblem hat (dies verhindert gefährliche 'Split-Brain'-Szenarien).
Besten Standby auswählen: Wählen Sie den Standby mit der geringsten Replikationsverzögerung (denjenigen, der im WAL-Stream am weitesten voraus ist).
Standby promovieren: Promoten Sie den ausgewählten Standby sofort mit dem Promotion-Befehl (pg_ctl promote).
Datenverlust behandeln (falls erforderlich): Wenn der Cluster asynchrone Replikation verwendet, müssen die auf dem ausgefallenen Primary verlorenen Daten möglicherweise manuell abgeglichen oder einfach akzeptiert werden, je nach Toleranz der Anwendung.
Ehemaligen Primary neu konfigurieren: Sobald der ursprüngliche Primary wiederhergestellt ist, muss er bereinigt, neu initialisiert (oft mit einem Basis-Backup vom neuen Primary) und konfiguriert werden, um dem neuen Primary zu folgen.

Der schwierige Teil des Failovers ist nicht das Tippen von pg_ctl promote. Der schwierige Teil ist die Entscheidung, dass der alte Primary als unsicher behandelt werden muss, bis das Gegenteil bewiesen ist. Wenn der alte Primary noch läuft, aber von der Anwendung oder vom Standby getrennt ist, kann es zu Split-Brain kommen: zwei beschreibbare PostgreSQL-Server, die unterschiedliche Historien akzeptieren. Sobald das passiert, wird PostgreSQL die Historien nicht für Sie zusammenführen. Sie stehen vor einer manuellen Datenabstimmung oder der Wiederherstellung einer Seite aus dem Backup.

In einem echten Vorfall würde ich lieber eine zusätzliche Minute damit verbringen, den alten Primary abzuriegeln, als den nächsten Tag damit zu verbringen, zu erklären, warum zwei Bestelldatensätze nicht übereinstimmen. Abriegelung kann bedeuten, die alte VM auszuschalten, ihre Netzwerkschnittstelle zu trennen, den Writer-Endpunkt zu deaktivieren oder einen Cloud-/Provider-Mechanismus zu verwenden, der garantiert, dass der alte Host keine Schreibvorgänge empfangen kann. Die genaue Methode hängt von Ihrer Infrastruktur ab, aber die Anforderung ist einfach: Bevor Clients auf den neuen Primary schreiben, darf der alte Primary für diese Clients nicht beschreibbar sein.

Erwarten Sie nach einem Failover Aufräumarbeiten. Wenn der alte Primary zurückkommt, zeigen Sie ihn nicht einfach beiläufig auf den neuen Primary und hoffen, dass er aufholt. Er könnte WAL enthalten, das zur alten Timeline gehört. In vielen Umgebungen ist der sicherste Weg pg_rewind, wenn die Voraussetzungen erfüllt sind, oder ein frisches Basis-Backup vom neuen Primary, wenn nicht.

Ein Detail, das bei Notfallarbeiten oft übersehen wird, ist die Geschichte der Replikations-Slots. Wenn der alte Primary physische Replikations-Slots für Standbys verwendet hat, wechseln diese Slots nicht automatisch mit dem promovierten Standby, es sei denn, Ihr HA-Tooling verwaltet sie. Überprüfen Sie nach einem Failover, ob der neue Primary die Slots hat, die Ihre überlebenden Standbys benötigen, und ob ein verlassener Slot WAL für immer zurückhält. Ein vergessener Slot kann Stunden nach dem sichtbaren Ausfall eine Festplatte füllen.

Wenden Sie die gleiche Disziplin für Backups an. Sobald der Cluster einen neuen Primary hat, bestätigen Sie, dass Backups und WAL-Archivierung jetzt diesem Primary folgen. Ein Failover, das den Dienst wiederherstellt, aber Backups stillschweigend stoppt, ist nur eine halbe Wiederherstellung.

Tools für sichere Promotion: Repmgr vs. Patroni

Während die manuelle Promotion mit pg_ctl möglich ist, verlassen sich robuste HA-Umgebungen auf dedizierte Tools, um die komplexe Choreographie zu verwalten, die für Failover und Switchover erforderlich ist, und automatisch Konfigurationsänderungen und Cluster-Statusverwaltung zu handhaben.

Repmgr (Replication Manager)

repmgr ist ein leichtgewichtiges Tool, das hilft, Knoten zu registrieren, Replikation zu überwachen und kontrollierte Rollenwechsel durchzuführen. Die genauen Befehle hängen von der Version und dem Cluster-Layout ab, aber das übliche Muster ist:

Switchover: Führen Sie einen geplanten repmgr standby switchover von dem Standby aus, der Primary werden soll, nachdem Sie die Replikationsgesundheit bestätigt haben.
Failover: Lassen Sie repmgrd automatisches Failover nur durchführen, wenn Abriegelungs- und Witness-/Quorum-Verhalten verstanden und getestet wurden.

Patroni

Patroni verwendet verteilte Konsensspeicher (wie etcd, ZooKeeper oder Consul), um den Cluster-Status zu verwalten und bei Erkennung eines Ausfalls automatisch einen neuen Primary zu wählen. Patroni automatisiert sowohl Switchover als auch Failover weitgehend über API-Aufrufe oder Kubernetes-Operatoren, was manuelle Eingriffe drastisch reduziert.

Beispiel mit Patroni (Konzeptioneller Promotion-Befehl):

# Auslösen eines Switchovers über die REST-API von Patroni
curl -X POST http://patroni-api-endpoint/switchover -H "Content-Type: application/json" -d '{"target": "standby_node_name"}'

Warnung zu Split-Brain: Die größte Gefahr bei automatisiertem Failover ist das 'Split-Brain'-Szenario, bei dem zwei Knoten aufgrund einer Netzwerkpartition fälschlicherweise glauben, der Primary zu sein. Tools wie Patroni mildern dies mit Quorum-Mechanismen, während manuelle Setups strenge Abriegelungsmechanismen (wie Stromsteuerung) erfordern, um sicherzustellen, dass nur ein Primary existiert.

Zusammenfassung der Unterschiede

Merkmal	Switchover (Geplant)	Failover (Notfall)
Auslöser	Wartung, Upgrade, administrative Entscheidung	Primary-Ausfall (Absturz, Ausfall)
Datenverlustrisiko	Nahe Null (bei richtiger Zeitplanung)	Mittel bis Hoch (abhängig vom Replikationsmodus)
Erwartete Ausfallzeit	Kurze, kontrollierte Ausfallzeit	Sofortige, reaktive Ausfallzeit
Vorbereitung	Erfordert vorherige Koordination und WAL-Sync-Bestätigung	Erfordert sofortiges Handeln und Vertrauen in die Standby-Gesundheit

Ein kleines Runbook, das Sie anpassen können

Für einen geplanten Switchover könnte ein kompaktes Runbook so aussehen:

Bestätigen Sie, dass der ausgewählte Standby gesund ist und WAL abspielt.
Unterbrechen Sie Anwendungsschreibvorgänge und Hintergrundjobs.
Bestätigen Sie, dass das Replikations-Replay aufgeholt hat.
Promoten Sie den Standby über das HA-Tool.
Verschieben Sie den Writer-Endpunkt.
Bestätigen Sie, dass pg_is_in_recovery() auf dem neuen Primary false ist.
Bauen Sie den alten Primary als Standby wieder auf oder führen Sie ein Rewind durch.
Setzen Sie Schreibvorgänge fort und beobachten Sie Fehler, Replikation und Verbindungszahlen.

Für Failover ändert sich die Reihenfolge:

Bestätigen Sie, dass der Primary ausgefallen oder unsicher ist.
Riegeln Sie den alten Primary ab.
Wählen Sie den am weitesten fortgeschrittenen Standby.
Promoten Sie ihn über das HA-Tool.
Verschieben Sie den Writer-Endpunkt einmal.
Bestätigen Sie, dass Schreibvorgänge auf dem neuen Primary funktionieren.
Überprüfen Sie Replicas, Slots, Backups und WAL-Archivierung.
Führen Sie den alten Primary nur durch Rewind oder Wiederaufbau wieder ein.

Die Befehle variieren je nach Tooling, aber die Sicherheitseigenschaften nicht. Ein beschreibbarer Primary, bekannter Replikationsstatus, getestetes Client-Routing und ein sauberer Weg, ausgefallene Knoten zurückzubringen.

Bevor Sie einem HA-Design vertrauen, proben Sie beide Pfade in einer Nicht-Produktionsumgebung. Eine Switchover-Übung sollte beweisen, dass Anwendungen sauber neu verbinden, der alte Primary wieder ein Standby werden kann und das Monitoring der neuen Rolle folgt. Eine Failover-Übung sollte etwas Strengeres beweisen: Der ausgefallene Primary ist abgeriegelt, der für die Promotion ausgewählte Standby ist der bestmögliche Kandidat, der Anwendungs-Writer-Endpunkt bewegt sich einmal, und der alte Primary kann ohne Rewind oder Wiederaufbau nicht wieder beitreten.

Die sichersten PostgreSQL-HA-Teams behandeln Failover als einen getesteten operativen Workflow, nicht als einen heldenhaften Befehl, der während eines Ausfalls getippt wird.