Concepto clave

El failover y recovery son mecanismos críticos para mantener la disponibilidad de bases de datos PostgreSQL en entornos de alta concurrencia. Imagina un sistema bancario donde miles de transacciones ocurren simultáneamente: si el servidor principal falla, un servidor secundario debe tomar el control inmediatamente, como un piloto de reserva en una aerolínea que reemplaza al titular sin que los pasajeros noten la diferencia.

En PostgreSQL, esto se logra mediante replicación asíncrona o síncrona, donde los datos se copian desde el primary (nodo principal) a uno o más standby (nodos de respaldo). El failover es el proceso automático o manual de cambiar del primary al standby cuando el primero falla, mientras que el recovery implica restaurar el sistema a un estado consistente después de una falla, asegurando que no se pierdan transacciones comprometidas.

Cómo funciona en la práctica

En un escenario típico, configuras un cluster con un nodo primary y al menos un standby usando herramientas como pg_basebackup y recovery.conf (en versiones anteriores) o postgresql.auto.conf (en PostgreSQL 12+). Por ejemplo, para iniciar la replicación, en el standby ejecutas pg_basebackup para copiar los datos del primary, luego configuras la conexión de streaming. Cuando el primary falla, un sistema de monitoreo (como Patroni o repmgr) detecta la falla y promueve el standby a nuevo primary, actualizando los clientes para que se conecten al nuevo endpoint.

Paso a paso: 1) Configura la replicación física con WAL streaming, 2) Monitorea la salud con checks de conectividad, 3) Define triggers para failover automático basado en timeouts, 4) Ejecuta el comando de promoción en el standby, y 5) Reconfigura los clientes para apuntar al nuevo primary. Esto minimiza el tiempo de inactividad a segundos en lugar de horas.

Codigo en accion

Configuración básica de replicación en PostgreSQL 14. Primero, en el primary (nodo 1), habilita la replicación en postgresql.conf:

# En postgresql.conf del primary
wal_level = replica
max_wal_senders = 10
wal_keep_size = 1GB
listen_addresses = '*'

Luego, crea un usuario de replicación:

CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD 'securepass';

En el standby (nodo 2), usa pg_basebackup para copiar los datos y configura la replicación en postgresql.auto.conf:

# Ejecutar en el standby
pg_basebackup -h primary_ip -D /var/lib/postgresql/14/main -U replicator -P -R

# Contenido generado en postgresql.auto.conf
primary_conninfo = 'host=primary_ip port=5432 user=replicator password=securepass'

Para iniciar el failover manualmente, en el standby ejecuta:

pg_ctl promote -D /var/lib/postgresql/14/main

Antes del failover, los clientes se conectan al primary; después, deben actualizar su configuración para apuntar al nuevo primary (standby promovido).

Errores comunes

No configurar wal_keep_size adecuadamente: Si es muy bajo, el standby puede quedarse sin WALs y requerir un resync completo. Solución: Ajusta según el volumen de transacciones, por ejemplo, 2GB para cargas altas.
Usar failover automático sin timeouts apropiados: Puede causar split-brain (múltiples primaries). Evítalo configurando quórum y delays, como un timeout de 30 segundos antes de promover.
Ignorar la consistencia de datos durante el recovery: Al recuperar de un backup, asegúrate de aplicar todos los WALs hasta el punto de falla. Usa herramientas como pg_rewind para reintegrar nodos antiguos sin pérdida.
No probar el failover en staging: Conduce a sorpresas en producción. Realiza drills regulares para verificar que el standby puede tomar el control sin errores.
Olvidar actualizar los clientes post-failover: Los aplicativos siguen apuntando al primary caído. Implementa un service discovery o usa balanceadores de carga que redirijan automáticamente.

Checklist de dominio

¿Configuraste wal_level = replica y max_wal_senders en el primary?
¿Verificaste que el standby está en modo recovery y sincronizado via pg_stat_replication?
¿Definiste un plan de failover con triggers automáticos o manuales?
¿Probaste el proceso de promoción en un entorno no productivo?
¿Aseguraste la reconexión de clientes post-failover con timeouts de conexión?
¿Monitoreas lag de replicación y alertas sobre retrasos mayores a 1MB?
¿Documentaste los pasos de recovery para diferentes escenarios de falla?

Configuración de Failover Automático con repmgr

En este ejercicio, configurarás un cluster de PostgreSQL con failover automático usando repmgr, una herramienta popular para gestión de replicación. Sigue estos pasos:

Instala repmgr en dos nodos (nodo1 como primary, nodo2 como standby) usando apt-get install repmgr o desde fuente.
Configura la replicación física entre nodo1 y nodo2 como se mostró en la lección, asegurándote de que wal_level sea replica.

En cada nodo, crea un archivo de configuración repmgr.conf con detalles como node_id, conninfo, y data_directory. Ejemplo para nodo1:

node_id=1
node_name='nodo1'
conninfo='host=nodo1 dbname=postgres user=replicator password=securepass'
data_directory='/var/lib/postgresql/14/main'

Registra el primary con repmgr primary register y el standby con repmgr standby clone seguido de repmgr standby register.
Configura un daemon de repmgrd en ambos nodos para monitoreo automático, definiendo failover thresholds en repmgr.conf (e.g., failover=automatic).
Simula una falla deteniendo PostgreSQL en nodo1 y observa cómo repmgrd promueve nodo2 a primary automáticamente.
Verifica el estado con repmgr cluster show y prueba la conectividad desde un cliente.

Entrega un informe breve con los comandos usados y capturas de pantalla del estado del cluster antes y después del failover.

Pistas

Asegúrate de que el usuario replicator tenga permisos REPLICATION y que pg_hba.conf permita conexiones desde los nodos.
Usa repmgr --help para ver opciones de configuración; prueba primero en un entorno aislado para evitar afectar producción.
Si el failover no ocurre, revisa los logs de repmgrd en /var/log/postgresql/ para errores de conectividad.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Estrategias de Failover y Recovery