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.

Fortgeschritten · ~45 Min · 10 Abschnitte Einführung · 9 Übungen (davon 3 Missionen)

Modul starten →

Fortschritt wird gespeichert — du kannst das Modul später jederzeit fortsetzen.

Nur den Lehrtext lesen →

Das kannst du danach

✓Du trennst, wogegen Replikation schützt und wogegen nur eine Sicherung hilft, und vertrittst beide Kosten getrennt.
✓Du wählst die Übertragungsart über die zugesagte Verlustgrenze und prüfst das Gegenstück, ohne das die Einstellung wirkungslos bleibt.
✓Du benennst Entscheidungsweg und Umschaltmechanismus, kennst den entarteten Zustand nach einem Failover und den Split-Brain-Fall samt seiner Unumkehrbarkeit.

Übungen

1. EntscheidungWie reagierst du?
2. EntscheidungWas gilt tatsächlich?
3. EntscheidungWie ordnest du das ein?
4. MissionDie synchrone Replikation, die keine ist
5. EntscheidungWelche Zusage gilt jetzt?
6. ReihenfolgeDer geplante Wechsel
7. EntscheidungWas ist die Lage?
8. EntscheidungWie bewertest du den Vorschlag?
9. MissionWogegen schützt der zweite Knoten?

Arbeitsartefakte

↓
Der geplante Wechseldatabase-replication-switchover-sequence-2026-09-12 · geprüft: 2026-09-12

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

Verfasst von Julian Zentgraf