Diseñado para nunca quedarse a oscuras.
Cada componente funciona en caliente. Los nodos activo y standby de la BD se replican continuamente. Una IP virtual flota sobre el clúster — keepalived vigila al primario, y en cuanto deja de responder, el tráfico va al standby antes de que el espectador medio note un buffer. Esto no es un tutorial de Postgres añadido a un SaaS — es infraestructura de primera clase en la que tu operador nunca tiene que pensar.
Tres nodos, una verdad.
Un par de BD activo/standby se replica sobre una red privada. Un par de balanceadores nginx participa en VRRP por una IP virtual que flota entre ellos. El clúster de aplicación lee a través de un pool de conexiones que se vacía y reintenta cuando el primario se mueve. Cada enlace tiene doble ruta.
Qué ocurre, segundo a segundo.
Cuando un nodo primario falla, la recuperación ocurre en 4 pasos ordenados. Acción del operador: cero. Perturbación del lado del cliente: más corta que una retransmisión TCP.
Latido perdido
El keepalived del standby deja de recibir los anuncios VRRP del primario. Tras 3 balizas perdidas (~1.5s), el standby se promueve a sí mismo.
Promoción + STONITH
El nuevo primario aísla el nodo viejo — apagado vía API cloud — y acepta escrituras. La dirección de replicación se invierte; el nodo recuperado se reincorporará como standby.
Migra la IP virtual
La IP virtual VRRP se mueve a la NIC del nuevo primario. El pool de conexiones de la capa de aplicación se vacía; las consultas en vuelo se reintentan contra el nuevo endpoint.
Estado estable
El servicio se restaura. El nodo recuperado, cuando es alcanzable, sincroniza y se une como standby caliente. Se escriben entradas en el registro de auditoría. El operador recibe una sola notificación — después del hecho.