Comment rendez-vous une base de données relationnelle managée hautement disponible ?

Exécutez-la en multi zone de disponibilité, avec un standby synchrone dans une autre zone et un basculement automatique, en général en une minute ou deux. Les réplicas en lecture servent à la mise à l'échelle des lectures, pas à la disponibilité, parce que la réplication est asynchrone et peut prendre du retard. Complétez avec des sauvegardes automatiques et une restauration à un instant précis, connectez-vous via l'endpoint du cluster ou un proxy pour que le basculement soit géré, et testez vraiment le basculement au lieu de lui faire confiance.

Le multi zone de disponibilité est le coeur du sujet : un standby synchrone dans une deuxième zone, et le service managé le promeut si le primaire tombe, en général en moins d'une minute ou deux. La distinction que je rends toujours explicite, c'est qu'un réplica en lecture n'est pas une cible de basculement : il est asynchrone, donc en promouvoir un peut signifier perdre des écritures récentes ; il est là pour la mise à l'échelle des lectures. La durabilité est encore un autre sujet, donc sauvegardes automatiques plus restauration à un instant précis, et je les copie dans une autre région parce qu'une base hautement disponible qui n'existe que dans une région reste à une mauvaise journée de disparaître. Ce que les gens oublient, c'est l'application. Le basculement change l'hôte vers lequel pointe l'endpoint, donc un pool de connexions qui garde des connexions périmées ou un runtime qui met le DNS en cache pour toujours continuera d'échouer alors que la base est de nouveau saine. Donc je me connecte via l'endpoint du cluster ou un proxy, je règle une validation de pool sensée, et je m'assure que les nouvelles tentatives sont sûres. Et je le teste, en déclenchant un basculement sur un environnement inférieur et en chronométrant la reprise de l'application, parce que ce chiffre est toujours pire que celui annoncé.