Replikation und Hochverfügbarkeit: Zusage, Umschaltung und Split-Brain

In der Konfiguration steht die strengste Replikationsstufe, das Audit vermerkt „synchrone Replikation“ — und der Test mit hartem Ausschalten verliert trotzdem die letzten Buchungen. Der Grund steht eine Zeile tiefer: Ohne gefüllte Liste synchroner Sekundärknoten ist die Stufe wirkungslos, und der Server meldet das nicht. Dieses Modul klärt, worauf ein COMMIT tatsächlich wartet, wer im Ernstfall umschaltet — und warum ein DROP TABLE auf beiden Knoten ankommt.

Lehrtext · 10 Abschnitte · zuletzt geprüft: 2026-09-12

Replikation ist kein Backup

Der häufigste Satz, der zu einem Datenverlust führt, lautet: „Wir haben doch eine Replikation.“ Beides schützt gegen völlig verschiedene Ereignisse, und wer sie verwechselt, hat genau eine Sorte Schutz doppelt und die andere gar nicht.

Replikation schützt gegen: Ausfall von Hardware, Host oder Standort. Der zweite Knoten hat denselben Stand und kann übernehmen.
Sicherung schützt gegen: Fehler im Inhalt: ein falsches UPDATE, ein DROP TABLE, eine fehlerhafte Auslieferung, eine Verschlüsselung durch einen Angreifer.

Warum die Replikation hier nichts nütztSie tut genau das, wofür sie gebaut ist: Sie überträgt die Änderung. Ein DROP TABLE auf dem Primärknoten ist Sekunden später auf jedem Sekundärknoten ebenfalls ausgeführt. Je besser die Replikation funktioniert, desto schneller ist der Fehler überall. Der Weg zurück führt über die Protokollkette aus dem Modul über Backup und Recovery — nicht über den zweiten Knoten.

Beide zusammen ergeben erst ein Konzept: Die Replikation senkt die Wiederanlaufzeit bei einem Infrastrukturausfall, die Sicherung begrenzt den Datenverlust bei einem Inhaltsfehler. Keine ersetzt die andere, und die Kosten fallen doppelt an.

Was „bestätigt“ genau bedeutet

Die zentrale Stellschraube jeder Replikation ist die Frage, worauf ein COMMIT wartet, bevor der Client eine Erfolgsmeldung bekommt. PostgreSQL beantwortet das über synchronous_commit, und die Dokumentation staffelt fünf Stufen.

remote_apply: Wartet, bis der Sekundärknoten den Commit-Satz empfangen, angewandt und dauerhaft gespeichert hat — er ist dort also auch für Abfragen sichtbar. Verursacht laut Dokumentation deutlich größere Commit-Verzögerungen als die anderen Stufen.
on (Voreinstellung): Wartet, bis der Sekundärknoten den Commit-Satz empfangen und auf dauerhaften Speicher geschrieben hat. Die Transaktion geht nur verloren, wenn Primär- und alle synchronen Sekundärknoten gleichzeitig Speicherkorruption erleiden.
remote_write: Wartet, bis der Sekundärknoten den Satz in sein Dateisystem geschrieben hat. Schützt gegen den Absturz des Datenbankprozesses dort — aber nicht gegen einen Absturz des Betriebssystems, weil die Daten dauerhaften Speicher noch nicht erreicht haben müssen.
local: Wartet nur auf das lokale Schreiben auf Platte, nicht auf die Replikation. Laut Dokumentation bei synchroner Replikation üblicherweise nicht wünschenswert, aber der Vollständigkeit halber vorhanden.
off: Wartet gar nicht. Zwischen Erfolgsmeldung und tatsächlicher Absturzsicherheit liegt eine Verzögerung von höchstens dem Dreifachen von wal_writer_delay.

Der wichtige Unterschied zwischen „verlieren“ und „kaputt“Die Dokumentation stellt ausdrücklich klar, dass synchronous_commit = off — anders als das Abschalten von fsync — kein Risiko für eine inkonsistente Datenbank erzeugt. Ein Absturz kann einige zuletzt scheinbar bestätigte Transaktionen kosten, aber der Datenbankzustand ist danach genau so, als wären diese Transaktionen sauber abgebrochen worden. Das ist eine Abwägung zwischen Leistung und Gewissheit — keine zwischen Leistung und Unversehrtheit.

Und die Stufe ist pro Transaktion wählbarDer Wert lässt sich laut Dokumentation jederzeit ändern; maßgeblich ist der Stand zum Zeitpunkt des COMMIT. Es ist also ausdrücklich möglich und nützlich, einzelne Transaktionen synchron und andere asynchron zu bestätigen — etwa mit SET LOCAL synchronous_commit TO OFF für einen unkritischen Massenimport, während Buchungen auf der strengen Voreinstellung bleiben.

Die Einstellung, die ohne ihr Gegenstück nichts tut

Hier liegt der Fehler, der sich am leichtesten macht und am schwersten bemerken lässt. Die fünf Stufen oben beschreiben, worauf gewartet wird — aber nur, wenn es überhaupt jemanden gibt, auf den gewartet werden soll.

Wörtlich aus der DokumentationIst synchronous_standby_names leer, sind die einzigen bedeutsamen Einstellungen on und off. remote_apply, remote_write und local liefern dann alle dieselbe lokale Synchronisationsstufe wie `on`.

Wer also synchronous_commit = remote_apply setzt, um die strengste Zusage zu bekommen, und dabei synchronous_standby_names leer lässt, hat nichts eingerichtet. Der Server nimmt den Wert an, meldet keinen Fehler, und die Konfiguration liest sich in jeder Prüfung wie eine synchrone Replikation. Tatsächlich wartet keine einzige Transaktion auf einen zweiten Knoten.

Das Muster dahinterEs ist dasselbe wie beim READ UNCOMMITTED im Transaktionsmodul und beim archive_mode ohne funktionierendes Archivkommando: Eine Einstellung wird angenommen und bewirkt nicht, was ihr Name verspricht. Solche Stellen lassen sich nicht durch Lesen der Konfiguration prüfen, sondern nur durch eine Messung — hier: nachsehen, ob überhaupt ein Sekundärknoten als synchron geführt wird.

SQL Server: die Einstellung des Primärknotens gewinnt

Always-On-Verfügbarkeitsgruppen kennen dieselbe Abwägung, verteilen sie aber auf beide Seiten — und daraus folgt eine Regel, die genauso leicht zu übersehen ist wie die leere Namensliste bei PostgreSQL.

Asynchroner Commit: Der Primärknoten wartet nicht darauf, dass ein Sekundärknoten die Protokollsätze dauerhaft schreibt. Minimale Latenz, gedacht als Katastrophenvorsorge über große Entfernungen. Unterstützt laut Dokumentation nur erzwungenes manuelles Failover — also eines mit möglichem Datenverlust.
Synchroner Commit: Der Primärknoten wartet auf die Bestätigung. Betont laut Dokumentation Hochverfügbarkeit vor Leistung, zum Preis erhöhter Transaktionslatenz. Unterstützt manuelles und optional automatisches Failover.
Nur-Konfiguration: Enthält keine Nutzdaten, sondern nur die Konfigurationsdaten der Verfügbarkeitsgruppe — das Gegenstück zum Zeugenserver.

Die Regel, die Absichten zunichtemachtDamit synchroner Commit überhaupt stattfindet, müssen laut Dokumentation beide Seiten dafür eingestellt sein — Primär- und Sekundärknoten. Und weiter: Ist der aktuelle Primärknoten auf asynchronen Commit eingestellt, bestätigt er für alle Sekundärknoten asynchron, unabhängig von deren eigener Einstellung. Ein sorgfältig auf synchron gestellter Sekundärknoten schützt also nicht, wenn der Primärknoten asynchron läuft. Dasselbe gilt für automatisches Failover: Auch dafür müssen beide Knoten eingerichtet sein.

Eine zweite Feinheit betrifft den Betriebsalltag. Überschreitet ein synchroner Sekundärknoten die Sitzungs-Zeitgrenze des Primärknotens — voreingestellt zehn Sekunden —, markiert dieser vorübergehend jede Datenbank dort als nicht synchronisierend und die Replik als nicht fehlerfrei. Verbindet sich der Knoten wieder, nehmen beide den synchronen Betrieb wieder auf. Eine kurze Netzstörung kann also die synchrone Zusage zeitweise aussetzen, ohne dass jemand etwas umgestellt hätte.

Lesekopien und die Verzögerung, die niemand meldet

Der zweite übliche Zweck einer Replikation ist die Entlastung der Leseseite. Auswertungen laufen auf dem Sekundärknoten, Buchungen auf dem Primärknoten. Das funktioniert gut — und hat eine Eigenschaft, die die Fachlichkeit regelmäßig überrascht.

Ein Sekundärknoten hinkt hinterher. Wie weit, hängt an der gewählten Stufe. Der Unterschied zwischen on und remote_apply ist genau dieser Punkt: Bei on wartet der Commit, bis der Satz auf dem Sekundärknoten dauerhaft gespeichert ist — bei remote_apply zusätzlich, bis er dort angewandt und damit für Abfragen sichtbar ist.

Die Lücke, die daraus entstehtAuf der Voreinstellung on kann eine Transaktion also bereits verlustsicher auf dem Sekundärknoten liegen und dort trotzdem noch nicht sichtbar sein. Wer unmittelbar nach einer Buchung auf der Lesekopie nachsieht, kann sie verfehlen. Das ist kein Fehler der Replikation, sondern die dokumentierte Abstufung — und der Grund, warum „Lesen nach eigenem Schreiben“ auf einer Lesekopie eine eigene Entwurfsentscheidung ist.

Die Buchung, die es angeblich nicht gibt

Szenario

Ein Sachbearbeiter bucht und ruft direkt danach eine Auswertung auf. Die Auswertung läuft auf der Lesekopie und zeigt die Buchung nicht. Zehn Sekunden später ist sie da.

Anforderungen

Replikation auf on, nicht auf remote_apply
Auswertungen sind auf die Lesekopie umgeleitet
Kein Fehler in Protokoll oder Überwachung

Schritte

Kein Defekt: Der Commit hat gewartet, bis der Satz auf dem Sekundärknoten dauerhaft lag — nicht, bis er dort angewandt war.
Auf remote_apply zu wechseln beseitigt die Lücke, verteuert aber jeden Commit im ganzen System, auch die, die niemand sofort wieder liest.
Die übliche Alternative ist ein Entwurfsschritt in der Anwendung: Abfragen unmittelbar nach einem eigenen Schreibvorgang auf den Primärknoten lenken, alle übrigen auf die Lesekopie.
Beides sind vertretbare Wege — unvertretbar ist nur, die Lücke als Störung zu behandeln und danach zu suchen.

Merksatz: Verzögerung auf einer Lesekopie ist eine Eigenschaft, kein Defekt. Die Entscheidung ist, ob man sie global bezahlt oder gezielt umgeht.

Failover: die Software liefert PostgreSQL nicht mit

Hier ist eine Erwartung besonders verbreitet und besonders falsch. Eine eingerichtete Replikation bedeutet nicht, dass bei einem Ausfall automatisch umgeschaltet wird.

Wörtlich aus der DokumentationPostgreSQL stellt die Systemsoftware nicht bereit, die nötig ist, um einen Ausfall des Primärknotens zu erkennen und den Sekundärknoten zu benachrichtigen. Es gibt viele solcher Werkzeuge, und sie sind gut in die Betriebssystemfunktionen eingebunden, die für ein erfolgreiches Failover nötig sind — etwa die Migration der IP-Adresse.

Wer also „eine Replikation eingerichtet“ hat, hat einen Sekundärknoten mit aktuellem Stand. Er hat damit die halbe Antwort auf einen Ausfall: Die Daten sind da. Was fehlt, ist alles andere — die Erkennung des Ausfalls, die Entscheidung umzuschalten, die Beförderung des Sekundärknotens und die Umlenkung der Clients.

Bei SQL Server sieht das anders aus: Dort ist automatisches Failover Teil des Produkts — aber nur unter Bedingungen. Es setzt synchronen Commit voraus, und es muss laut Dokumentation auf beiden beteiligten Knoten eingerichtet sein. Ein asynchron laufender Primärknoten schließt es aus.

Die ehrliche Frage an ein bestehendes KonzeptSie lautet nicht „haben wir eine Replikation“, sondern: Wer entscheidet, dass umgeschaltet wird, woran erkennt er es, und wie lange dauert es von der Entscheidung bis zum benutzbaren Dienst? Wenn die Antwort „der Bereitschaftskollege, nach einer Meldung, in etwa einer Stunde“ lautet, ist das ein gültiges Konzept — nur eben eines mit einer Stunde Wiederanlaufzeit, nicht mit null.

Split-Brain: wenn beide sich für den Primärknoten halten

Der gefährlichste Zustand eines Replikationsverbunds ist nicht der Ausfall eines Knotens, sondern die Situation, in der beide Knoten glauben, sie seien der Primärknoten. Dann nehmen beide Schreibvorgänge an, und die beiden Datenbestände laufen auseinander.

Was die Dokumentation dazu sagtFällt der Primärknoten aus, wird der Sekundärknoten zum neuen Primärknoten, und startet der alte Primärknoten danach wieder, muss ein Mechanismus existieren, der ihm mitteilt, dass er nicht mehr der Primärknoten ist. Das wird manchmal STONITH genannt — und es ist nötig, um Situationen zu vermeiden, in denen beide Systeme sich für den Primärknoten halten, was zu Verwirrung und letztlich zu Datenverlust führt.

Der Punkt, der dabei oft untergeht: Der Schaden entsteht nicht während des Split-Brain, sondern danach. Zwei auseinandergelaufene Bestände lassen sich nicht zusammenführen — es gibt keine Regel, die entscheidet, welche der beiden Buchungen auf dieselbe Zeile gilt. Am Ende muss jemand einen der beiden Bestände verwerfen, und damit sind echte, bestätigte Transaktionen verloren.

Zur Abwehr nennt die Dokumentation zwei Bauformen. Viele Failover-Systeme nutzen nur zwei Systeme mit einem Herzschlag-Mechanismus dazwischen. Es ist auch möglich, ein drittes System — einen Zeugenserver — einzusetzen, um manche Fälle unangebrachten Failovers zu verhindern. Die Dokumentation dämpft die Erwartung aber ausdrücklich: Die zusätzliche Komplexität lohnt sich möglicherweise nicht, sofern sie nicht mit hinreichender Sorgfalt und gründlichen Tests eingerichtet wird.

Kurzcheck

Warum ist ein Zeugenserver kein reiner Gewinn?

Er erhöht die Komplexität und muss selbst gründlich getestet werden
Er muss dieselbe Datenmenge vorhalten wie die beiden anderen Knoten
Er verhindert automatisches Failover, weil er mitentscheiden muss

Treffer. Richtig. Die Dokumentation nennt genau das: Der Mehraufwand lohnt sich möglicherweise nicht, wenn er nicht mit hinreichender Sorgfalt und gründlichen Tests eingerichtet wird. Ein ungetesteter dritter Knoten kann selbst zur Ausfallursache werden.

Nach dem Failover ist der Verbund kein Verbund mehr

Ein gelungenes Failover ist nicht das Ende des Vorfalls, sondern sein Anfang zweiter Teil. Die Dokumentation benennt den Zustand danach ausdrücklich.

Der entartete ZustandNach einem Failover ist nur ein einziger Server in Betrieb — die Dokumentation nennt das einen entarteten Zustand. Der frühere Sekundärknoten ist jetzt der Primärknoten, der frühere Primärknoten ist aus und bleibt es möglicherweise. Um zum Normalbetrieb zurückzukehren, muss ein Sekundärknoten neu erstellt werden — auf dem alten System, wenn es wiederkommt, oder auf einem dritten.

Das heißt praktisch: In der Nacht nach dem Failover läuft der Dienst, aber ohne jeden Schutz gegen den nächsten Ausfall. Die Wiederherstellung des Verbunds ist eine eigene, oft mehrstündige Arbeit — bei großen Beständen lässt sie sich laut Dokumentation mit pg_rewind beschleunigen, aber nicht überspringen. Wer nach einem Failover die Lage für bereinigt erklärt, erklärt die Hälfte für bereinigt.

Der Zwischenschritt, den die Dokumentation nennt — und gleich relativiertManche Betriebe setzen einen dritten Server ein, um den neuen Primärknoten abzusichern, bis der neue Sekundärknoten wiederhergestellt ist. Die Dokumentation nennt diesen Weg ausdrücklich und schränkt ihn im selben Satz ein: Er verkompliziert Systemkonfiguration und Betriebsabläufe erkennbar. Das ist die wiederkehrende Abwägung dieses Moduls in kleiner Form — jeder zusätzliche Knoten schließt eine Lücke und öffnet eine neue Stelle, an der etwas falsch eingerichtet sein kann. Und ein Knoten, den niemand regelmäßig testet, ist im Ernstfall keine Reserve, sondern eine Annahme.

Dazu kommt eine Falle aus dem Grundlagenmodul: Ein Cluster kann laut Dokumentation nicht auf eine inkompatible Version der Kollations-Bibliothek wechseln — und sie nennt die binäre Streaming-Replikation ausdrücklich als einen der Wege, auf denen das passieren kann. Zwei Knoten mit unterschiedlichem Betriebssystemstand sind deshalb kein reiner Betriebsdetail, sondern ein Risiko für die Sortierordnung in den Indizes.

Der geplante Wechsel ist der einzige echte Test

Ein Failover-Verfahren, das nie ausgeführt wurde, ist eine Vermutung. Die Dokumentation empfiehlt deshalb etwas, das viele Betriebe für ein unnötiges Risiko halten.

Aus der DokumentationEin regelmäßiger Wechsel vom Primär- zum Sekundärknoten ist nützlich, weil er regelmäßige Ausfallzeiten auf jedem System für Wartungsarbeiten ermöglicht. Er dient außerdem als Test des Failover-Mechanismus, um sicherzustellen, dass er wirklich funktioniert, wenn man ihn braucht. Schriftlich festgehaltene Administrationsverfahren werden empfohlen.

Der geplante Wechsel hat gegenüber dem Ernstfall drei Vorteile: Er findet zu einer gewählten Zeit statt, der alte Primärknoten ist erreichbar und kann geordnet stillgelegt werden, und es geht keine Transaktion verloren. Genau deshalb ist er auch kein vollständiger Test — die Erkennung eines unangekündigten Ausfalls und das Verhalten bei halb erreichbarem Primärknoten prüft er nicht.

Preis der Ehrlichkeit an dieser StelleEin geplanter Wechsel kostet ein Wartungsfenster, bringt kurzzeitige Nichtverfügbarkeit und erzeugt danach den entarteten Zustand, bis der Verbund wiederhergestellt ist. Wer ihn zweimal jährlich durchführt, bezahlt das mit vier geübten Störungen statt einer ungeübten — und bekommt dafür die Gewissheit, dass das Verfahren, die Dokumentation und die Zuständigkeiten stimmen.

Die Reihenfolge, die das zusammenhält

Klären, gegen welches Ereignis geschützt werden soll→Zusage festlegen: wie viel Verlust, wie viel Wiederanlaufzeit→Übertragungsart danach wählen — und ihr Gegenstück prüfen→Entscheidungsweg und Umschaltmechanismus benennen→Geplanten Wechsel üben, bevor der Ernstfall ihn verlangt

Ereignis vor Technik

Der dritte Schritt enthält die Warnung dieses Moduls in einem Halbsatz. Eine Übertragungsart ist nie allein wirksam: Bei PostgreSQL braucht sie eine nicht leere Liste synchroner Sekundärknoten, bei SQL Server die passende Einstellung auf beiden Seiten. Wer nur eine Hälfte setzt, hat eine Konfiguration, die sich gut liest und nichts tut.

AbgrenzungWie ein Dienst nach einem Totalausfall geordnet wieder anläuft — Reihenfolge über mehrere Dienste, Priorisierung, Führung der Lage — steht im Track backup-disaster-recovery. Wie die Protokollkette entsteht, auf der jede Replikation aufsetzt, steht im Modul über Backup und Recovery. Hier ging es um die Frage, was der zweite Knoten zusagt — und was er ausdrücklich nicht zusagt.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität6 Primärquellen · zuletzt geprüft: 2026-09-12