Dans une expérience pratique, un développeur a délibérément arrêté la base de données primaire dans une configuration de séparation lecture-écriture pour observer le comportement du cluster. Contrairement aux attentes, le système n'a pas basculé proprement ; il a plutôt présenté des pics de latence, des échecs d'écriture partiels et une propagation d'état incohérente. L'article détaille la séquence exacte des événements, y compris la façon dont la réplique a géré (ou n'a pas géré) la transition. Les principaux enseignements incluent la nécessité d'intervalles de vérification de santé appropriés, de délais d'attente de pool de connexions et de logique de réessai au niveau de l'application. Ce test réel souligne que les configurations haute disponibilité nécessitent une validation rigoureuse au-delà des hypothèses documentaires. Pour les équipes utilisant MySQL ou des architectures similaires, c'est une histoire édifiante qui mérite d'être étudiée.
Un ingénieur teste la haute disponibilité en arrêtant la base de données primaire et découvre un comportement inattendu du cluster.