Comprensión y Ejecución de Escenarios de Failover vs. Switchover en PostgreSQL

En la arquitectura moderna de bases de datos, asegurar la operación continua a través de Alta Disponibilidad (HA) es primordial. PostgreSQL, una potente base de datos relacional de código abierto, se basa en la replicación de streaming para mantener la consistencia de los datos en múltiples nodos. Sin embargo, cuando el servidor primario encuentra un problema o requiere mantenimiento, los administradores de bases de datos deben ejecutar procedimientos precisos para restaurar el servicio. Este artículo diferencia claramente entre dos operaciones críticas de HA —Failover y Switchover— y detalla los pasos y consideraciones para promover de forma segura una réplica de respaldo a convertirse en el nuevo primario.

Comprender la distinción entre estos eventos es vital. Un switchover es una transición controlada y planificada, mientras que un failover es una respuesta de emergencia a una interrupción inesperada. Navegar con éxito en cualquiera de los escenarios depende en gran medida de una configuración adecuada, una monitorización robusta y familiaridad con las herramientas utilizadas para gestionar la replicación.

Fundamentos de la Replicación: La Base de la HA

La Alta Disponibilidad de PostgreSQL se basa en la replicación de streaming, donde un servidor actúa como Primario (o Maestro) y uno o más servidores actúan como Respaldos (o Réplicas). El Primario transmite registros del write-ahead log (WAL) a los Respaldos para mantenerlos sincronizados.

Para gestionar eficazmente estos roles, son necesarias configuraciones específicas tanto en los nodos primarios como en los de respaldo:

Configuraciones Críticas

Estas configuraciones rigen cómo opera la replicación y cómo los nodos se identifican entre sí:

wal_level: Debe establecerse en replica o superior (idealmente logical si se utilizan herramientas que requieren decodificación lógica) en el Primario.
max_wal_senders: Define el número máximo de conexiones concurrentes desde los respaldos. Debe aumentarse desde el valor predeterminado (generalmente 10) para acomodar a todos los respaldos.
hot_standby: Debe establecerse en on en el archivo postgresql.conf del servidor de respaldo para permitir consultas de solo lectura durante la replicación.
synchronous_commit: Controla el acuse de recibo de transacciones. Para cero pérdida de datos durante los switchovers, a menudo se establece en on (o remote_write para una tolerancia a latencia menor).
primary_conninfo: Establecido en el respaldo, detalla la información de conexión (host, puerto, usuario, contraseña) para conectarse al Primario actual.

Mejor Práctica: Para una HA robusta, utilice capas de agrupación de conexiones (como PgBouncer o proxies de HA dedicados como Patroni o Repmgr) que abstraigan las direcciones físicas de los servidores, haciendo que los failovers y switchovers sean fluidos para las aplicaciones.

Switchover: La Transición Planificada

Un Switchover es un proceso controlado y gradual en el que el nodo Primario activo se desmantela intencionadamente y un Respaldo designado se promueve para ocupar su lugar. Este procedimiento se utiliza típicamente para mantenimiento planificado, actualizaciones de versión o reemplazos de hardware.

Pasos para un Switchover Controlado

El objetivo de un switchover es garantizar cero pérdida de datos esperando que todas las transacciones en curso se repliquen antes de la promoción.

Detener las Escrituras en el Primario Actual: El primer paso es evitar que se confirmen nuevas transacciones en el Primario actual. Esto a menudo se logra estableciendo default_transaction_read_only = on o apagando temporalmente las conexiones de los clientes.
Esperar a que la Replicación se Ponga al Día: Asegúrese de que el Respaldo designado haya recibido y aplicado todos los registros WAL restantes del Primario. Puede verificar el retardo de replicación utilizando pg_stat_replication en el Primario o examinando el estado de recuperación del respaldo.
Iniciar la Promoción del Respaldo: Ejecute el comando para promover el servidor Respaldo elegido al rol de Primario. El comando específico depende de la herramienta de gestión utilizada (por ejemplo, pg_ctl promote o un comando del gestor de clúster).
Reconfigurar el Antiguo Primario: Una vez que el Respaldo se ha promovido con éxito, el antiguo Primario debe ser reconfigurado para seguir al nuevo Primario como un Respaldo. Esto implica actualizar su primary_conninfo.
Redireccionar Aplicaciones: Actualice el balanceador de carga o el agrupador de conexiones para dirigir el tráfico al nuevo servidor Primario.

Failover: La Respuesta de Emergencia

Un Failover es un procedimiento inmediato y reactivo activado cuando el servidor Primario actual falla inesperadamente (por ejemplo, fallo de hardware, partición de red, error de software) y no puede volver a estar en línea rápidamente.

El Failover inherentemente conlleva un mayor riesgo de pérdida de datos porque no hay garantía de que las últimas transacciones confirmadas hayan tenido tiempo de transmitirse a los Respaldos antes de que ocurriera la falla.

Ejecución de un Failover de Emergencia

Los procedimientos de Failover están diseñados para la velocidad y la recuperación, a menudo utilizando herramientas especializadas para automatizar la promoción.

Determinar el Estado del Antiguo Primario: Verifique que el Primario original realmente no esté disponible y no esté experimentando solo un problema de red transitorio (esto evita peligrosos escenarios de 'split-brain').
Seleccionar el Mejor Respaldo: Elija el Respaldo con el menor retardo de replicación (el que esté más avanzado en el flujo WAL).
Promover el Respaldo: Promueva inmediatamente el Respaldo seleccionado utilizando el comando de promoción (pg_ctl promote).
Manejar Pérdida de Datos (Si es Necesario): Si el clúster utiliza replicación asíncrona, la pérdida de datos en el Primario fallido podría necesitar ser reconciliada manualmente o simplemente aceptada, dependiendo de la tolerancia de la aplicación.
Reconfigurar el Antiguo Primario: Una vez que el Primario original se recupera, debe ser limpiado, reinicializado (a menudo requiriendo una copia de seguridad base del nuevo Primario) y configurado para seguir al nuevo Primario.

Herramientas para una Promoción Segura: Repmgr vs. Patroni

Si bien la promoción manual usando pg_ctl es posible, los entornos de HA robustos dependen de herramientas dedicadas para gestionar la compleja coreografía requerida para failovers y switchovers, manejando automáticamente los cambios de configuración y la gestión del estado del clúster.

Repmgr (Replication Manager)

repmgr es una herramienta potente y ligera que monitoriza la replicación y facilita el failover manual o automático. Los comandos clave incluyen:

Switchover: repmgr standby promote seguido de repmgr switchover --sibling-nodes-wait (para asegurar la sincronización).
Failover: repmgr failover

Patroni

Patroni utiliza Almacenes de Consenso Distribuido (como etcd, ZooKeeper o Consul) para gestionar el estado del clúster, eligiendo automáticamente un nuevo Primario tras la detección de un fallo. Patroni automatiza en gran medida tanto los switchovers como los failovers a través de llamadas API u operadores de Kubernetes, reduciendo drásticamente la intervención manual.

Ejemplo usando Patroni (Comando de Promoción Conceptual):

# Disparando un switchover a través de la API REST de Patroni
curl -X POST http://patroni-api-endpoint/switchover -H "Content-Type: application/json" -d '{"target": "standby_node_name"}'

Advertencia sobre Split-Brain: El mayor peligro durante un failover automatizado es el escenario de 'split-brain' (cerebro dividido), donde dos nodos creen erróneamente que son el Primario debido a una partición de red. Herramientas como Patroni lo mitigan usando mecanismos de quórum, mientras que las configuraciones manuales requieren estrictos mecanismos de aislamiento (como controles de alimentación) para asegurar que solo exista un Primario.

Resumen de Diferencias

Característica	Switchover (Planificado)	Failover (Emergencia)
Disparador	Mantenimiento, actualización, elección administrativa	Fallo del Primario (fallo, interrupción)
Riesgo de Pérdida de Datos	Casi Cero (si se programa adecuadamente)	Medio a Alto (depende del modo de replicación)
Expectativa de Tiempo de Inactividad	Tiempo de inactividad corto y controlado	Tiempo de inactividad inmediato y reactivo
Preparación	Requiere coordinación previa y confirmación de sincronización WAL	Requiere acción inmediata y dependencia del estado del Respaldo

Ejecutar failovers y switchovers de PostgreSQL requiere una profunda comprensión del estado del clúster y las herramientas que lo gestionan. Mientras que los switchovers apuntan a cero pérdida de datos a través de la coordinación, los failovers priorizan la restauración rápida del servicio, a menudo a expensas de las transacciones más recientes. La configuración adecuada de los parámetros de replicación y la utilización de herramientas de gestión de clústeres robustas son las piedras angulares de una Alta Disponibilidad fiable de PostgreSQL.