Conceptos básicos de HA

Alta disponibilidad para PostgreSQL significa sobrevivir a la pérdida del primario con un tiempo de recuperación definido (RTO) y una ventana de pérdida de datos aceptable (RPO). Las aplicaciones deben reconectarse y reintentar durante la ventana de failover.

Receta

Objetivo OLTP de Nivel 0: 99.95% de tiempo de actividad, RTO < 60s, RPO < 30s con standby físico asíncrono + Patroni 3.x.

-- Verificar que el standby está listo para la promoción
SELECT pg_is_in_recovery(), pg_last_wal_replay_lsn(), now() - pg_last_xact_replay_timestamp() AS replay_delay;

# Cadena de conexión de la aplicación: apuntar al primario a través de un proxy, no a la IP desnuda del nodo
# postgresql://app:***@pg-primary.internal:5432/appdb?connect_timeout=5&application_name=checkout

Cuándo usar esto: Cualquier base de datos de producción donde minutos de inactividad de escritura afecten directamente a los ingresos o a los créditos del SLA.

Ejemplo funcional

Definir SLOs, medir el presupuesto de failover, configurar el reintento del cliente:

-- En el standby: frescura de la reproducción antes del simulacro
SELECT CASE
  WHEN pg_last_xact_replay_timestamp() IS NULL THEN 'aún no hay reproducción'
  ELSE (now() - pg_last_xact_replay_timestamp())::text
END AS replay_age;

# Patroni 3.x: verificar el líder del clúster (desde el host de operaciones)
curl -s http://patroni-node1:8008/cluster | jq '.members[] | {name, role, state}'

# Patrón de reintento de aplicación (psycopg) - simplificado
import time
import psycopg
 
for attempt in range(5):
    try:
        with psycopg.connect(conninfo, connect_timeout=5) as conn:
            conn.execute("SELECT 1")
            break
    except psycopg.OperationalError:
        time.sleep(2 ** attempt)

Lo que esto demuestra:

• La HA es una propiedad del sistema: PostgreSQL + standby + orquestación + proxy + reintentos de la aplicación.
• El retraso de reproducción en el standby limita el RPO asíncrono antes de la promoción.
• Los clientes deben usar tiempos de espera y backoff exponencial durante el cambio de DNS/proxy.

Profundización

Métricas principales

Capas de la pila de HA

Matemáticas del tiempo de actividad

99.9% permite ~43 minutos de inactividad por mes. 99.95% permite ~22 minutos. Los simulacros de failover deben demostrar que te mantienes dentro del presupuesto, incluido el arranque en frío de la aplicación.

Trampas

• IP del primario codificada en las aplicaciones - El failover tiene éxito pero las aplicaciones permanecen caídas. Solución: Nombre de host del proxy o descubrimiento de servicios.
• Sin reintento de la aplicación en 57P01 / reinicio de conexión - Un breve parpadeo se convierte en una interrupción visible para el usuario. Solución: Reintentar errores transitorios para lecturas idempotentes y escrituras seguras.
• PgBouncer sin tiempo de vida del servidor - Conexiones obsoletas al primario muerto. Solución: server_lifetime + comprobaciones de estado; pausar/reanudar durante el failover.
• Standby demasiado atrasado - Promoción con RPO grande. Solución: Alertas de retraso de bytes antes de declarar la HA lista.
• HA sin runbook probado - Solo tiempo de actividad teórico. Solución: Juego de guerra trimestral de failover de Patroni.

Alternativas

Preguntas frecuentes

Relacionados

• Patroni y etcd/Consul - failover automático
• Proxies de conexión - enrutamiento durante el failover
• Pruebas de HA - simulacros de juego de guerra
• Conceptos básicos de DR - niveles de RPO/RTO

Versiones de la pila: Esta página se escribió para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x y PostGIS 3.5+.