Conçu pour ne jamais s'éteindre.
Chaque composant fonctionne à chaud. Les nœuds DB actif et standby se répliquent en continu. Une IP virtuelle flotte au-dessus du cluster — keepalived surveille le primaire, et dès qu'il cesse de répondre, le trafic bascule sur le standby avant que le spectateur moyen ne remarque un buffer. Ce n'est pas un tutoriel Postgres greffé sur un SaaS — c'est une infrastructure de première classe à laquelle votre opérateur n'a jamais à penser.
Trois nœuds, une vérité.
Une paire DB actif/standby se réplique sur un réseau privé. Une paire de load-balancers nginx participe à VRRP pour une IP virtuelle qui flotte entre eux. Le cluster d'application lit via un pool de connexions qui se vide et réessaie quand le primaire se déplace. Chaque lien est à double chemin.
Ce qui se passe, seconde par seconde.
Quand un nœud primaire échoue, la récupération se fait en 4 étapes ordonnées. Action opérateur : zéro. Perturbation côté client : plus courte qu'une retransmission TCP.
Battement perdu
Le keepalived du standby cesse de recevoir les annonces VRRP du primaire. Après 3 balises manquées (~1.5s), le standby se promeut.
Promotion + STONITH
Le nouveau primaire isole l'ancien nœud — extinction via API cloud — et accepte les écritures. Le sens de réplication s'inverse ; le nœud récupéré rejoindra comme standby.
Migration de l'IP virtuelle
L'IP virtuelle VRRP migre vers la NIC du nouveau primaire. Le pool de connexions de l'application se vide ; les requêtes en vol sont réessayées sur le nouveau point de terminaison.
État stable
Le service est restauré. Le nœud récupéré, quand il est joignable, se synchronise et rejoint comme standby chaud. Les entrées du journal d'audit sont écrites. L'opérateur reçoit une seule notification, après coup.