# Der geplante Wechsel
Typ: Checkliste
Herkunft: database-administration-basics / replication-high-availability / database-replication-switchover-sequence
Version: database-replication-switchover-sequence-2026-09-12
Geprüft: 2026-09-12

ACHTUNG: Dieses Dokument ist ein Lernartefakt aus einer Schulungssequenz. Es ist kein produktives Runbook. Vor jeder Anwendung in einer realen Umgebung müssen die Schritte gegen lokale Dokumentation, Runbooks und Freigabestatus geprüft werden.

## Szenario
Zweimal jährlich soll planmäßig auf den Sekundärknoten gewechselt werden — als Wartungsfenster für den Primärknoten und als Test des Verfahrens.

## Schritte
1. Prüfen, dass der Sekundärknoten aufgeschlossen hat und als synchron geführt wird
2. Schreibzugriffe auf dem Primärknoten beenden und ihn geordnet stilllegen
3. Den Sekundärknoten zum Primärknoten befördern
4. Die Clients auf den neuen Primärknoten umlenken
5. Sicherstellen, dass der alte Primärknoten beim Hochfahren keine Schreibzugriffe mehr annimmt
6. Den alten Primärknoten als neuen Sekundärknoten wieder in den Verbund aufnehmen

## Begründung
Warum: Der Wechsel ist erst abgeschlossen, wenn der alte Knoten daran gehindert ist, sich erneut für den Primärknoten zu halten — und wenn der Verbund wieder zwei Knoten hat. Ein Wechsel, der nach dem Umlenken der Clients endet, hinterlässt einen ungeschützten Dienst und ein Split-Brain-Risiko.
Folgen: **+** Das Verfahren wird zweimal jährlich geübt, samt Zuständigkeiten und schriftlichen Abläufen — im Ernstfall ist es dann bekannt. **−** Es prüft den **angekündigten** Fall: Erkennung eines unangekündigten Ausfalls und das Verhalten bei halb erreichbarem Primärknoten bleiben ungeübt.

## Quellen
1. https://www.postgresql.org/docs/current/warm-standby-failover.html
2. https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups