Votre base de données principale bascule à 3h du matin et les écritures se mettent à échouer. Quels sont vos premiers gestes ?

Confirmez que la nouvelle primaire est bien promue et accepte les écritures, puis vérifiez si les applications se sont reconnectées. Des pools de connexions périmés et un DNS en cache sont la raison habituelle pour laquelle les erreurs continuent après une bascule pourtant saine. Vérifiez le retard de réplication et si des écritures validées ont été perdues au regard de votre RPO. Rétablissez le trafic d'écriture, écartez le split brain en vous assurant que l'ancienne primaire est fencée, puis gardez pour le post mortem la question de savoir pourquoi la bascule n'a pas été transparente.

Étape un, confirmer la réalité : me connecter directement à la nouvelle primaire et vérifier qu'elle est sortie de récupération et accepte les écritures. Si la base est saine et que les applications échouent encore, le problème est de notre côté, et d'expérience c'est en général là qu'il se trouve. Les pools de connexions gardent des sockets vers une adresse qui ne sert plus les écritures, ou la JVM a mis l'entrée DNS en cache pour toujours, donc le correctif est un redémarrage progressif ou un pool avec une vraie validation. On a eu un cas où le driver respectait un TTL de 30 secondes mais où le pool ne revalidait jamais les connexions inactives, donc la reprise a pris vingt minutes de plus qu'elle n'aurait dû. Ensuite je vérifie le retard de réplication au moment de la promotion pour voir si on a perdu des écritures validées, parce que ça change qui je dois prévenir. Je veux aussi la confirmation que l'ancienne primaire est fencée et ne peut pas accepter d'écriture si elle revient. Une fois les écritures rétablies, la question du post mortem est de savoir pourquoi ça n'a pas été automatique.