Puntos Clave de HA y Failover
La alta disponibilidad para PostgreSQL no es un interruptor único que se activa, es un sistema ensamblado a partir de replicación, un orquestador que detecta fallos y elige un nuevo líder, y un enrutamiento que redirige a los clientes al nodo que sea actualmente primario.
El failover es lo que sucede cuando ese sistema decide que el primario se ha ido y promueve un standby en su lugar, y la velocidad y seguridad de esa decisión es lo que separa un breve parpadeo de una interrupción real.
Esta página construye el modelo mental detrás de ese sistema antes de que las páginas más procedimentales de esta sección detallen la configuración de Patroni, la configuración del proxy y el fencing.
Resumen
- La HA combina un standby replicado, un orquestador basado en consenso y un enrutamiento orientado al cliente para que un fallo del primario resulte en una promoción automática y segura en lugar de una intervención manual.
- Por Qué Importa: Sin las tres capas trabajando juntas, un standby saludable todavía significa una recuperación manual, propensa a errores y lenta.
- Conceptos Clave: DCS (almacén de configuración distribuido), quorum, elección de líder, fencing, STONITH, RTO/RPO.
- Cuándo Usar: Cualquier base de datos de producción donde una interrupción del primario de más de unos pocos minutos tenga un costo real para el negocio.
- Limitaciones / Compensaciones: El failover automático intercambia cierto riesgo de una promoción incorrecta o prematura por una gran reducción en el tiempo medio de recuperación.
- Temas Relacionados: replicación en streaming, Patroni y etcd/Consul, prevención de split-brain, proxies de conexión.
Fundamentos
Alta disponibilidad en este contexto significa que el sistema continúa sirviendo lecturas y escrituras dentro de una ventana de recuperación acordada, incluso después de que el nodo primario de PostgreSQL falle.
Esa ventana tiene dos nombres que vale la pena conocer con precisión: RTO, el objetivo de tiempo de recuperación o cuánto tiempo se permite que dure una interrupción, y RPO, el objetivo de punto de recuperación o cuánta pérdida de datos recientes es aceptable.
Un standby por sí solo no proporciona HA, ya que un standby que requiere que un humano note la interrupción, verifique que el standby esté actualizado y lo promueva manualmente puede tardar más en recuperarse que el RTO que un negocio realmente necesita.
El failover automatiza esa llamada de juicio: un orquestador observa continuamente la salud del primario, y cuando decide que el primario se ha ido realmente, promueve el standby más actualizado y saludable sin esperar a una persona.
Un switchover es el primo planificado del failover, un cambio de líder deliberado y orquestado utilizado para mantenimiento, donde el primario saliente coopera en la entrega en lugar de simplemente desaparecer.
Las decisiones del orquestador deben ser confiables bajo particiones de red, razón por la cual la HA de PostgreSQL en producción depende de un almacén de configuración distribuido (DCS) como etcd o Consul en lugar de que el orquestador decida solo.
Una analogía útil es un grupo de bomberos que acuerdan por votación por radio quién lidera una operación, en lugar de que cada uno decida independientemente que está a cargo, ya que un solo nodo que adivina "el primario debe estar caído" desde su propia vista limitada es exactamente cómo terminan dos primarios activos a la vez.
Mecánicas e Interacciones
El DCS proporciona quorum, un mecanismo de votación donde la mayoría de los nodos del DCS deben estar de acuerdo antes de que una decisión de liderazgo, como promover un nuevo primario, se considere válida.
Un orquestador como Patroni 3.x mantiene un contrato con tiempo limitado en el DCS que representa "Soy el líder actual", y debe renovar continuamente ese contrato o perder el liderazgo automáticamente.
Si la instancia de Patroni del primario no puede alcanzar el DCS, su contrato expira, y cualquier réplica alcanzable por el quorum sobreviviente del DCS puede ser elegida como el nuevo líder, todo sin intervención humana.
Aquí es donde el split-brain, dos nodos creyendo cada uno que son el primario, se convierte en un riesgo real en lugar de uno teórico, ya que un primario que está simplemente aislado de la red del DCS aún puede estar en ejecución y aceptando escrituras mientras se elige un nuevo líder en otro lugar.
El fencing es el conjunto de técnicas que garantizan que el antiguo primario deje de aceptar escrituras genuinamente antes o inmediatamente después de que uno nuevo tome el control, desde un watchdog de software que mata el proceso local de PostgreSQL hasta STONITH a nivel de hardware que apaga o aísla completamente el nodo de la red.
-- Cualquier nodo promovido debe responder false; un antiguo primario persistente que responda
-- false también es la señal de split-brain que los operadores vigilan durante los simulacros
SELECT pg_is_in_recovery();Una vez que se elige un nuevo líder, el enrutamiento tiene que ponerse al día: las aplicaciones deben dejar de enviar escrituras al antiguo primario y comenzar a enviarlas al nuevo, que es el trabajo de una capa de proxy como HAProxy o una verificación de salud consciente de Patroni, en lugar de la base de datos en sí.
Los pools de conexión añaden su propia complicación aquí, ya que un pooler como PgBouncer que mantiene conexiones abiertas a un nodo ahora degradado seguirá enrutando tráfico allí hasta que sus propias verificaciones de salud o una reconexión forzada se pongan al día con la nueva topología.
Los clientes se sientan al final de esta cadena, e incluso un failover perfectamente ejecutado produce una breve ventana de reinicios de conexión, razón por la cual la reintentos a nivel de aplicación con backoff se trata como parte del diseño de HA en lugar de una ocurrencia tardía.
Consideraciones Avanzadas y Aplicaciones
La lección operativa más profunda en HA de PostgreSQL es que un sistema con componentes excelentes aún puede fallar en su conjunto si esos componentes nunca se probaron juntos bajo condiciones de fallo realistas.
El tamaño del DCS es lo primero que hay que hacer bien, ya que la matemática del quorum significa que un DCS de N nodos tolera la pérdida de floor(N/2) nodos, razón por la cual un clúster etcd de 2 nodos no proporciona protección real y 3 o 5 nodos son el mínimo práctico para producción.
Colocar el DCS en los mismos hosts que PostgreSQL es una trampa sutil, ya que un fallo de un solo host o rack puede entonces eliminar tanto el nodo de la base de datos como suficientes votos del DCS para perder el quorum al mismo tiempo.
Existen guardas como maximum_lag_on_failover porque un sistema automatizado promoverá felizmente un standby que está técnicamente saludable pero lo suficientemente atrasado como para violar el RPO, por lo que los orquestadores exponen un límite de retraso en bytes por debajo del cual se niega la promoción.
Los simulacros de día de juego, que activan deliberadamente el failover de manera controlada, son el único método confiable para descubrir si las suposiciones de RTO se mantienen una vez que se incluyen los tiempos de reconexión del proxy, el comportamiento del pooler y la lógica de reintento de la aplicación en la medición, no solo la promoción de la base de datos en sí.
Las ofertas administradas en la nube, como las implementaciones Multi-AZ, implementan las mismas capas conceptuales, consenso equivalente al DCS, fencing y enrutamiento, pero las ocultan detrás de un plano de control administrado, lo que intercambia el control operativo por una superficie más pequeña para configurar incorrectamente.
| Topología | Orquestación | Fencing | Mejor ajuste |
|---|---|---|---|
| Patroni + etcd | Autogestionado, amigable con Kubernetes | Watchdog + STONITH opcional | Equipos que desean control total y portabilidad |
| Patroni + Consul | Autogestionado, amigable con la pila HashiCorp | Watchdog + STONITH opcional | Entornos ya estandarizados en Consul/service mesh |
| Multi-AZ administrado en la nube | Completamente administrado por el proveedor | Administrado internamente, opaco para el operador | Equipos de operaciones pequeños que priorizan la simplicidad sobre la personalización |
| Disco compartido heredado / Pacemaker | Gestor de recursos de clúster | SAN fencing | Inversiones existentes on-prem, raramente elegidas en proyectos nuevos |
El patrón que separa la HA en papel de la HA en la práctica es tratar el DCS, el fencing y el enrutamiento como partes de primera clase del diseño, y luego probar el RTO y el RPO con simulacros en lugar de confiar solo en las matemáticas teóricas de tiempo de actividad.
Conceptos Erróneos Comunes
- "Tener un standby replicado es lo mismo que tener alta disponibilidad." Un standby sin un orquestador y una capa de enrutamiento todavía requiere detección y promoción manual, que es exactamente el proceso lento y propenso a errores que el failover automático existe para eliminar.
- "Failover y switchover son la misma operación." El failover reacciona a una pérdida imprevista del primario, mientras que el switchover es una entrega planificada y cooperativa para mantenimiento, y los dos conllevan perfiles de riesgo muy diferentes.
- "Dos nodos son suficientes para el failover automático." Un DCS de 2 nodos no puede formar una mayoría después de perder un nodo, lo que hace que 3 o más nodos sean el mínimo práctico para decisiones seguras basadas en quorum.
- "El fencing es opcional si la red es generalmente confiable." El split-brain solo necesita ocurrir una vez para causar una divergencia de datos real, y las redes "generalmente confiables" todavía se particionan con suficiente frecuencia como para que los clústeres de producción traten el fencing como obligatorio.
- "Los porcentajes de tiempo de actividad más altos siempre se pueden lograr agregando más standbys." Más standbys mejoran la capacidad de lectura y los candidatos a failover, pero el RTO está limitado por el tiempo de detección, el tiempo de promoción y el enrutamiento, no solo por el recuento de standbys.
Preguntas Frecuentes
¿Tener un standby replicado es lo mismo que tener alta disponibilidad?
No, un standby es una capa necesaria, pero la HA también requiere un orquestador para detectar fallos y promover automáticamente, además de enrutamiento para que los clientes encuentren el nuevo primario.
¿Cuál es la diferencia entre RTO y RPO?
RTO es cuánto tiempo se permite que dure una interrupción, mientras que RPO es cuánta pérdida de datos recientes es aceptable, y ambas son decisiones de negocio expresadas como configuración técnica.
¿Por qué el failover automático necesita un almacén de configuración distribuido?
Un solo nodo que decide por sí mismo que el primario está caído no se puede confiar bajo particiones de red, por lo que un DCS proporciona un voto basado en quorum que todos los nodos acuerdan honrar.
¿Qué es el split brain y por qué es peligroso?
Es el estado en el que dos nodos creen que son el primario y ambos aceptan escrituras, lo que provoca que los datos diverjan de maneras que son dolorosas o imposibles de reconciliar después.
¿Cómo previene el fencing el split brain?
El fencing garantiza que el antiguo primario deje de aceptar escrituras genuinamente, ya sea a través de un watchdog de software que mata el proceso local de PostgreSQL o mediante el aislamiento del nodo a nivel de hardware.
¿Cuál es la diferencia práctica entre failover y switchover?
El failover responde a un fallo imprevisto del primario y ocurre sin la cooperación del antiguo primario, mientras que el switchover es un cambio de líder deliberado y coordinado utilizado para mantenimiento planificado.
¿Por qué un DCS de 2 nodos no puede proporcionar un failover automático seguro?
El quorum requiere una mayoría, y un clúster de 2 nodos no puede formar una mayoría después de perder incluso un nodo, lo que elimina la propiedad de seguridad de la que depende todo el mecanismo.
¿Promover un standby corrige automáticamente el enrutamiento de la aplicación?
No, el enrutamiento es una capa separada, típicamente un proxy o un balanceador de carga consciente de la salud, que debe detectar el nuevo primario y redirigir el tráfico hacia él.
¿Qué papel juega un pooler de conexión durante el failover?
Un pooler como PgBouncer puede seguir enrutando tráfico a un nodo ahora degradado hasta que sus propias verificaciones de salud o una reconexión forzada se pongan al día con la nueva topología.
¿Por qué los equipos ejecutan días de juego de failover en lugar de confiar en el diseño en papel?
El RTO real depende del tiempo de detección, el tiempo de promoción, el comportamiento de reconexión del proxy y la lógica de reintento de la aplicación en conjunto, y solo un simulacro en vivo mide todos estos combinados.
¿Está una base de datos Multi-AZ administrada en la nube exenta de estos conceptos de HA?
No, implementa las mismas capas, consenso, fencing y enrutamiento, pero los oculta detrás de un plano de control administrado en lugar de requerir que usted configure cada uno.
¿Agregar más standbys siempre mejora el tiempo de recuperación?
No directamente, ya que el RTO está limitado principalmente por el tiempo de detección, promoción y propagación del enrutamiento, y los standbys adicionales principalmente añaden candidatos a failover y capacidad de lectura en lugar de acelerar esos pasos.
Relacionados
- Fundamentos de HA - Objetivos RTO/RPO y la pila de HA en la práctica
- Patroni y etcd/Consul - configuración de la elección de líder basada en quorum
- Prevención de Split-Brain - fencing, matemáticas de quorum y STONITH
- Proxies de Conexión - enrutamiento de clientes al primario actual
- Pruebas de HA - ejecución de días de juego de failover
- Replicación en Streaming Explicada - la capa de replicación sobre la que se construye la HA
Versiones de la pila: Esta página fue escrita para PostgreSQL 18.4 (línea principal estable 18, línea de mantenimiento 17 también soportada) y Patroni 3.x.