Construído para nunca ficar no escuro.
Cada componente funciona quente. Os nós ativo e standby do BD replicam continuamente. Um IP virtual flutua sobre o cluster — keepalived vigia o primário, e assim que ele deixa de responder, o tráfego vai para o standby antes que o espectador médio perceba um buffer. Isso não é um tutorial de Postgres pregado num SaaS — é infraestrutura de primeira classe na qual seu operador nunca precisa pensar.
Três nós, uma verdade.
Um par de BD ativo/standby replica sobre uma rede privada. Um par de load-balancers nginx participa de VRRP para um IP virtual que flutua entre eles. O cluster de aplicação lê através de um pool de conexões que esvazia e tenta novamente quando o primário se move. Cada link é de caminho duplo.
O que acontece, segundo a segundo.
Quando um nó primário falha, a recuperação acontece em 4 passos ordenados. Ação do operador: zero. Interrupção do lado do cliente: mais curta que uma retransmissão TCP.
Batimento perdido
O keepalived do standby deixa de receber os anúncios VRRP do primário. Após 3 balizas perdidas (~1.5s), o standby se promove.
Promoção + STONITH
O novo primário isola o nó antigo — desligamento via API cloud — e aceita gravações. A direção da replicação inverte; o nó recuperado se reunirá como standby.
O IP virtual migra
O IP virtual VRRP se move para a NIC do novo primário. O pool de conexões da camada de aplicação esvazia; consultas em voo são repetidas contra o novo endpoint.
Estado estável
O serviço é restaurado. O nó recuperado, quando alcançável, sincroniza e se junta como standby quente. Entradas do log de auditoria são gravadas. O operador recebe uma única notificação — após o fato.