In einem praktischen Experiment stoppte ein Entwickler absichtlich die primäre Datenbank in einer Lese-Schreib-Trennungsumgebung, um das Clusterverhalten zu beobachten. Entgegen den Erwartungen erfolgte kein sauberer Failover; stattdessen traten Latenzspitzen, partielle Schreibfehler und inkonsistente Zustandsweitergabe auf. Der Beitrag beschreibt die genaue Ereignisabfolge, einschließlich wie die Replik den Übergang bewältigte (oder nicht). Wichtige Erkenntnisse umfassen die Notwendigkeit angemessener Health-Check-Intervalle, Connection-Pool-Timeouts und anwendungseigener Wiederholungslogik. Dieser reale Test unterstreicht, dass Hochverfügbarkeitskonfigurationen eine strenge Validierung über Dokumentationsannahmen hinaus erfordern. Für Teams, die auf MySQL oder ähnliche Architekturen setzen, ist dies eine warnende Geschichte, die es wert ist, studiert zu werden.
Ein Ingenieur testet die Hochverfügbarkeit durch Stoppen der primären Datenbank und entdeckt unerwartetes Clusterverhalten.