Costruito per non spegnersi mai.
Ogni componente funziona a caldo. I nodi DB attivo e standby si replicano continuamente. Un IP virtuale fluttua sopra il cluster — keepalived sorveglia il primario, e non appena smette di rispondere, il traffico passa allo standby prima che lo spettatore medio noti un buffer. Questo non è un tutorial di Postgres incollato su un SaaS — è infrastruttura di prima classe a cui il tuo operatore non deve mai pensare.
Tre nodi, una verità.
Una coppia DB attivo/standby si replica su una rete privata. Una coppia di load-balancer nginx partecipa a VRRP per un IP virtuale che fluttua tra di loro. Il cluster applicativo legge tramite un pool di connessioni che si svuota e ritenta quando il primario si sposta. Ogni link è a doppio percorso.
Cosa accade, secondo per secondo.
Quando un nodo primario fallisce, il recupero avviene in 4 passaggi ordinati. Azione operatore: zero. Disturbo lato cliente: più breve di una ritrasmissione TCP.
Heartbeat perso
Il keepalived dello standby smette di ricevere gli annunci VRRP del primario. Dopo 3 beacon mancati (~1.5s), lo standby si promuove.
Promozione + STONITH
Il nuovo primario isola il vecchio nodo — spegnimento via API cloud — e accetta scritture. La direzione di replica si inverte; il nodo recuperato si riunirà come standby.
L'IP virtuale migra
L'IP virtuale VRRP si sposta sulla NIC del nuovo primario. Il pool di connessioni del livello applicativo si svuota; le query in volo vengono riprovate contro il nuovo endpoint.
Stato stabile
Il servizio è ripristinato. Il nodo recuperato, quando raggiungibile, sincronizza e si unisce come standby caldo. Le voci dell'audit log vengono scritte. L'operatore riceve una singola notifica — a posteriori.