2026 PostgreSQL 18: Wie wird die Primär-Standby-Replikation abgenommen? Checkliste für den Failover

Geeignet: Eine Abnahme der PostgreSQL-18-Primär-Standby-Replikation ist erst bestanden, wenn WAL-Empfang und -Wiedergabe, eine kontrollierte Hochstufung, die Wiederherstellung der Anwendungszugriffe und gegebenenfalls logische Replikationsslots geprüft wurden. Eine niedrige Replikationsverzögerung oder ein erreichbarer Standby allein reicht nicht aus. Bei asynchroner Replikation können Transaktionen fehlen, die den Standby noch nicht erreicht haben; Replikation ersetzt außerdem keine externe Sicherung.

Dieser Leitfaden ist für DBA gedacht, die den Betrieb einer PostgreSQL-18-Produktivdatenbank und ihres physischen Standbys freigeben.
Infrastrukturteams prüfen Serverressourcen, Netzwerkpfade und die Isolation der Knoten.
Anwendungs- und Bereitschaftsteams kontrollieren Wiederverbindung, Schreibverhalten und klare Freigabebedingungen.

Beginnen Sie mit einer Abnahmematrix statt mit einem einzelnen Verzögerungswert

Die PostgreSQL-Dokumentation unterscheidet beim physischen Streaming-Replikationspfad zwischen WAL, das gesendet, geschrieben, dauerhaft gespeichert und schließlich wiedergegeben wurde. Diese Positionen sind nicht austauschbar: Ein Standby kann Daten empfangen, die Wiedergabe kann aber noch zurückliegen. Die Überwachung sollte daher mehrere Zustände gemeinsam betrachten, statt ein einzelnes Feld als Freigabeentscheidung zu verwenden. Die PostgreSQL-Dokumentation zur Überwachung von Streaming-Replikation beschreibt die dafür relevanten Statusinformationen.

Die Dokumentation zu den Replikationsparametern von PostgreSQL 18 und die Verwaltungsfunktionen helfen dabei, Sender-, Empfänger- und Konfigurationszustände einzuordnen. Für die Abnahme sollte das Team außerdem festhalten, welche Instanz als Primärserver vorgesehen ist und wie es den Status des Standbys unabhängig von einem bloß erfolgreichen Netzwerkaufruf überprüft.

DBA: Prüfen Sie Empfang und Wiedergabe getrennt

Auf dem Primärserver liefert pg_stat_replication Informationen zu verbundenen Standbys und ihren WAL-Positionen. Auf dem Standby zeigt pg_stat_wal_receiver, ob ein WAL-Empfänger aktiv ist; ergänzend lassen sich mit Verwaltungsfunktionen die zuletzt empfangene und wiedergegebene WAL-Position sowie der Recovery-Zustand abfragen. Die Felder und Funktionen sollten gegen die offizielle PostgreSQL-18-Dokumentation zu Verwaltungsfunktionen und die Dokumentation zur Überwachung von Warm Standby geprüft werden.

Beispiel für eine Übersicht auf dem Primärserver:

SELECT application_name, state, sync_state,
       sent_lsn, write_lsn, flush_lsn, replay_lsn,
       write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

Auf dem Standby kann der Status des WAL-Empfängers separat geprüft werden:

SELECT status, written_lsn, flushed_lsn,
       latest_end_lsn, latest_end_time
FROM pg_stat_wal_receiver;

Die genaue Interpretation hängt vom Betriebszustand ab. Ein aktiver Empfänger zeigt eine Verbindung, nicht zwingend eine abgeschlossene Wiedergabe. Eine fortgeschriebene Empfangsposition zeigt, dass WAL ankommt; sie ist kein Beleg dafür, dass dieselbe Position bereits in der Datenbank angewendet wurde. Vergleichen Sie daher die Positionswerte auf beiden Seiten und protokollieren Sie den Recovery-Zustand des Standbys.

Für den LSN-Abstand kann eine Abfrage wie die folgende als Diagnose dienen:

SELECT pg_wal_lsn_diff(
  pg_last_wal_receive_lsn(),
  pg_last_wal_replay_lsn()
) AS empfangen_aber_nicht_wiedergegeben;

Das Ergebnis beschreibt einen Abstand zwischen Empfang und Wiedergabe, ist aber für sich genommen keine universelle Freigabegrenze. Ein akzeptabler Zustand muss sich aus dem vereinbarten Datenverlustziel, dem Schreibaufkommen und dem Zweck des Standbys ergeben. Bei asynchroner Replikation kann ein Primärserver Schreibvorgänge bestätigen, bevor der Standby das entsprechende WAL erhalten hat. Wird der Primärserver dann unbrauchbar, kann der Standby diese bestätigten Transaktionen nicht zwingend enthalten. Die PostgreSQL-Dokumentation zu Warm Standby und Streaming-Replikation erläutert die Betriebsbedingungen; die Abnahme muss die mögliche Datenlücke ausdrücklich als Restrisiko festhalten.

Prüfen Sie außerdem Slots und WAL-Aufbewahrung. Ein Slot kann WAL für einen Verbraucher zurückhalten, der nicht mehr nachkommt; dadurch steigt der Speicherbedarf auf dem Primärserver. Erfassen Sie deshalb Slot-Namen, Verbraucher, Aktivität und zurückgehaltene WAL-Menge und legen Sie fest, wer einen verwaisten Slot beurteilt. Die Feldbeschreibung der Ansicht pg_replication_slots gibt den passenden Referenzrahmen. Eine Statusabfrage sollte nicht nur zum Zeitpunkt der Freigabe erfolgen: Das Team braucht auch einen Alarm- und Zuständigkeitsweg für den Fall, dass ein Slot oder Standby später dauerhaft zurückfällt.

Infrastruktur: Ordnen Sie Server, Netzwerk und Isolation dem Fehlerbild zu

Ein Datenbank-Standby ist nur dann eine belastbare Ausweichmöglichkeit, wenn er den Primärserver im Fehlerfall tatsächlich erreichen, die relevanten WAL-Daten verarbeiten und anschließend von den vorgesehenen Anwendungen angesprochen werden kann. Prüfen Sie deshalb zuerst die reale Bereitstellung: verfügbare CPU- und Arbeitsspeicherressourcen, Datenträger, Betriebssystem, Zugriffswege und den konkret eingerichteten Netzwerkpfad. Übernehmen Sie keine Beispielkonfiguration als verbindliche Zusage für einen bestimmten Anbieter oder eine bestimmte Mietoption.

Für die Abnahme zählt nicht nur, ob beide Server laufen. Die Teams sollten nachvollziehen können, ob die Replikationsverbindung über den vorgesehenen Pfad funktioniert, welche Firewall- und Zugriffskontrollen gelten und wie ein fehlerhafter oder alter Primärserver von der Wiederaufnahme ausgeschlossen wird. Eine private VLAN-Verbindung, eine automatische Hochverfügbarkeitssteuerung oder ein Fernzugriff auf die Hardware darf nicht als vorhanden vorausgesetzt werden, solange die konkrete Leistungsbeschreibung und Einrichtung das nicht bestätigen.

Die folgende Gegenüberstellung hilft, unterschiedliche Abnahmeziele nicht miteinander zu vermischen:

Planen Sie die Kapazität anhand der tatsächlichen Last und der benötigten Datenbank- und Betriebssystemressourcen. Ein Produktvergleich sollte deshalb auf die für beide Knoten benötigten Komponenten eingehen, nicht allein auf die Bezeichnung „dedizierter Server“. Eine Produktübersicht von SFP Cloud kann zur Orientierung dienen; verbindlich sind die dort aktuell ausgewiesenen Optionen. Aus der Miete einer einzelnen Maschine folgt weder eine fertig eingerichtete Primär-Standby-Architektur noch ein automatischer Failover.

DBA: Legen Sie den geplanten Hochstufungstest fest

Die Frage, ob ein Standby hochgestuft werden kann, lässt sich nicht durch eine reine Erreichbarkeitsprüfung beantworten. Vor der Übung müssen die Verantwortlichen das Fehlerbild, den genehmigten Zeitpunkt, die betroffenen Anwendungen und die Abbruchbedingungen vereinbaren. Ein kontrollierter Test ist nicht dasselbe wie ein ungeplanter Notfall: Das Team sollte genau wissen, welche Instanz die Rolle des Primärservers übernehmen soll und wie verhindert wird, dass der alte Primärserver gleichzeitig weiter Schreibvorgänge annimmt.

Die PostgreSQL-Dokumentation zur Hochstufung eines Standbys und zum Failover beschreibt die relevanten Verfahren und Grenzen. Eine manuelle Hochstufung mit einer Verwaltungsfunktion wie pg_promote() ist eine gezielte Aktion; sie stellt allein keine automatische Failover-Steuerung bereit. Die entsprechende Funktion ist in der Referenz zu den Administrationsfunktionen dokumentiert. Der Ablauf muss zur eingesetzten Steuerung passen und vor dem Test anhand der offiziellen Dokumentation geprüft werden.

Checkliste für die geplante Übung:

• [ ] Verantwortliche für Datenbank, Infrastruktur, Anwendung und Freigabe sind benannt.
• [ ] Der erwartete Fehlerfall und die Abbruchkriterien sind schriftlich festgelegt.
• [ ] Vor dem Test sind Primär- und Standby-Rolle sowie ihre WAL-Positionen dokumentiert.
• [ ] Der Standby wird nur nach dem genehmigten Verfahren hochgestuft.
• [ ] Der neue Primärserver nimmt einen ausdrücklich vereinbarten, kontrollierbaren Schreibtest an.
• [ ] Die Rollenänderung und die relevanten Zeitpunkte werden in einem gemeinsamen Protokoll festgehalten.
• [ ] Vor einer Wiederaufnahme des alten Primärservers ist eine Split-Brain-Situation ausgeschlossen.
• [ ] Das Team hat einen Rückweg festgelegt, der zur inzwischen veränderten Datenlage passt.

Besonders wichtig ist der Umgang mit dem alten Primärserver. Nach einer Hochstufung darf er nicht ungeprüft wieder mit Schreibzugriffen in denselben Dienst gelangen: Er kann einen abweichenden Datenstand besitzen. Vor einem Wiedereintritt muss das Team den Zustand feststellen und einen geeigneten Wiederaufbau- oder Synchronisierungsweg wählen. Wenn die Isolation der alten Instanz nicht zuverlässig möglich ist, sollte die Übung nicht fortgesetzt werden. Eine erfolgreich ausgeführte Hochstufung ist kein Beleg dafür, dass die Fehlererkennung, die Netztrennung oder das Wiederanschließen automatisch sicher funktionieren.

Anwendungsteam: Prüfen Sie Wiederverbindung und Schreibresultat

Ein offener Datenbankport ist noch keine wiederhergestellte Anwendung. Nach einem Primärwechsel müssen die Anwendungsteams prüfen, ob Verbindungs-Pools alte Sitzungen verwerfen, wie Clients den neuen Endpunkt finden und ob Wiederholungsversuche zu doppelten Geschäftsvorgängen führen können. Der Test sollte aus dem vorgesehenen Anwendungspfad erfolgen, nicht nur von einer Administrationskonsole aus.

Prüfschritte für die Anwendung:

• [ ] Verbindungspools erkennen, dass eine bestehende Verbindung nicht mehr nutzbar ist, und behandeln sie entsprechend.
• [ ] Der konfigurierte Endpunkt führt nach dem Rollenwechsel zum vorgesehenen neuen Primärserver.
• [ ] Schreiboperationen schlagen nicht unbemerkt auf dem alten Primärserver fehl oder landen auf einem falschen Knoten.
• [ ] Das Ergebnis einer unterbrochenen Transaktion wird vor einer Wiederholung geprüft.
• [ ] Wiederholbare Anfragen sind so gestaltet, dass ein erneuter Versuch keine ungewollte doppelte Verarbeitung auslöst.
• [ ] Ein kontrollierter Testdatensatz lässt sich eindeutig auf den neuen Schreibpfad zurückführen.
• [ ] Bereitschafts- und Supportteams wissen, wie sie den aktuellen Primärserver erkennen.

Der Test muss Transaktionsergebnisse berücksichtigen, nicht nur Verbindungsfehler. Wenn eine Verbindung während eines Schreibvorgangs abbricht, kann die Anwendung unter Umständen nicht wissen, ob die Transaktion bereits festgeschrieben wurde. Die Abnahme sollte daher dokumentieren, wie die betreffende Geschäftsoperation geprüft und gegebenenfalls sicher wiederholt wird. Ebenso ist festzuhalten, wie ein Client einen veralteten Endpunkt erkennt und welche Komponente ihn auf den neuen Primärserver lenkt. Die konkrete Lösung hängt von der Anwendungsarchitektur ab; sie darf nicht aus dem Datenbankstatus allein abgeleitet werden.

Datenkonsumenten: Prüfen Sie logische Slots nach dem Rollenwechsel

Physische Streaming-Replikation und logische Replikation erfüllen unterschiedliche Aufgaben. Ein physischer Standby übernimmt WAL für die Wiederherstellung einer physischen Datenbankkopie. CDC, logische Abonnements und andere Verbraucher können dagegen auf logischen Replikationsslots angewiesen sein. Die Übersicht zur logischen Replikation in PostgreSQL 18 erläutert diese Trennung; das Team sollte deshalb zunächst alle tatsächlichen Verbraucher und ihre Abhängigkeiten inventarisieren.

Wenn keine logische Replikation oder CDC eingesetzt wird, wird dieser Prüfschritt als nicht anwendbar dokumentiert. Wenn logische Verbraucher vorhanden sind, genügt es nicht, nach dem Primärwechsel nur zu prüfen, ob die Datenbank wieder erreichbar ist. Das Team muss feststellen, ob die benötigten Slots auf dem neuen Primärserver verfügbar und für die Fortsetzung geeignet sind. Für PostgreSQL 18 sind die Bedingungen zur Weiterverwendung logischer Slots und zur Failover-Unterstützung in der Dokumentation zum Failover logischer Replikation beschrieben.

Kontrollieren Sie insbesondere, ob die erforderliche Slot-Synchronisierung und die zugehörige Konfiguration für den vorgesehenen Ablauf eingerichtet sind. Prüfen Sie den Slot-Zustand nach dem Rollenwechsel erneut und beobachten Sie, ob der jeweilige Verbraucher tatsächlich fortsetzt, statt nur einen erfolgreichen Verbindungsaufbau zu melden. Werden Slots nicht wie erwartet übertragen oder synchronisiert, muss der Datenkonsument nach dem dokumentierten Verfahren wiederhergestellt werden. Ein Team darf nicht annehmen, dass ein logischer Slot allein deshalb weiterbesteht, weil die physische Replikation des Standbys funktioniert.

Bereitschaft und Datenverantwortliche: Sichern Sie Freigabe und Rückweg ab

Eine produktive Freigabe sollte durch ein gemeinsames Protokoll gestützt sein: beobachteter Replikationszustand, Ergebnis des Hochstufungstests, Anwendungsprüfung, Status logischer Verbraucher und dokumentierte Rückfallgrenze. Für jeden offenen Punkt braucht es eine zuständige Person und eine klare Folgeentscheidung. Wenn der Standby nicht nachvollziehbar auf dem vorgesehenen Datenstand ist, die alte Instanz nicht sicher isoliert werden kann oder die Anwendung den neuen Schreibpfad nicht bestätigt, wird die Freigabe gestoppt.

Abschließende Freigabe- und Schutzliste:

• [ ] WAL-Empfang und WAL-Wiedergabe sind getrennt betrachtet und protokolliert.
• [ ] Das Risiko eines Datenverlusts bei asynchroner Replikation ist im Betriebsverfahren beschrieben.
• [ ] Hochstufung, Isolierung des alten Primärservers und Wiederaufnahme sind als getrennte Aktionen dokumentiert.
• [ ] Anwendungsteams haben Wiederverbindung, Transaktionsergebnis und mögliche Wiederholungen geprüft.
• [ ] Logische Replikation ist entweder geprüft oder ausdrücklich als nicht verwendet gekennzeichnet.
• [ ] Zuständigkeiten für Freigabe, Abbruch und Rückweg sind geklärt.
• [ ] Eine Sicherung außerhalb der replizierten Server ist vorhanden und ihre Wiederherstellbarkeit wurde geprüft.

Replikation hält einen Standby auf dem Laufenden, ist aber kein unabhängiger Schutz vor versehentlichem Löschen, fehlerhaften Änderungen oder dem Verlust beider Knoten. Planen Sie deshalb externe Sicherungen und Wiederherstellungstests separat. Die PostgreSQL-Dokumentation zu Sicherung und Wiederherstellung erläutert die dazugehörigen Verfahren. Auch Software-RAID oder eine zweite Replikatkopie ersetzt keine außerhalb der betroffenen Server abgelegte und wiederherstellbar getestete Sicherung.

Für den Infrastrukturteil sollte die Mietentscheidung zu den Anforderungen an CPU, Arbeitsspeicher, direkt angebundene Datenträger, Betriebssystem und Abrechnungszeitraum passen. Welche Optionen tatsächlich verfügbar sind, ist vor der Planung in der Preisseite von SFP Cloud zu prüfen. Eine einzelne dedizierte Maschine kann Ressourcen und Datenträgerzugriff bereitstellen, bildet aber nicht von selbst einen zweiten Knoten, eine private Netzwerkverbindung oder eine automatische Umschaltung ab.

Geteilte virtuelle Server können für geringe oder vorübergehende Lasten sinnvoll sein; bei dauerhaftem Datenbankbetrieb können jedoch gemeinsam genutzte CPU-Ressourcen, angebotsspezifische Grenzen bei Speicherleistung und eingeschränkte Kontrolle über die Datenträgerplanung die Abnahme erschweren. Eine dedizierte AMD-Physikmaschine von SFP Cloud kommt eher infrage, wenn dauerhaft zugewiesene Serverressourcen und die selbst geplante Datenbank- und Datenträgerarchitektur benötigt werden. Sie ist keine Abkürzung für Hochverfügbarkeit: Das Team muss beide Knoten, Netzwerkpfade, Replikation, Failover-Verfahren und externe Sicherungen selbst entwerfen und prüfen. Sind diese Bedingungen geklärt, sollte die Auswahl anhand der aktuellen Produktangaben erfolgen; andernfalls ist zunächst die Architektur zu schließen, bevor der Serverbetrieb freigegeben wird.