PostgreSQL: Alta Disponibilidad con Streaming Replication (2026)

Cuando un servidor de base de datos PostgreSQL primario se detiene, el tiempo se detiene para toda la organización. Recuerdo una noche, a las 03:15, una alerta crítica: la base de datos primaria estaba caída. La réplica no se había configurado correctamente, y la restauración desde la copia de seguridad nos llevó 4 horas, con la pérdida de 6 horas de datos. Un desastre evitable. Este escenario, lamentablemente común, subraya la importancia vital de una configuración robusta para la alta disponibilidad. La PostgreSQL Streaming Replication no es solo una funcionalidad avanzada, sino un requisito fundamental para cualquier entorno de producción con SLAs estrictos. Permite mantener una copia actualizada de la base de datos en un servidor en espera (standby), lista para asumir el rol en caso de fallo del primario, reduciendo drásticamente los tiempos de inactividad y minimizando la pérdida de datos. En esta guía completa, exploraremos paso a paso cómo configurar la PostgreSQL Streaming Replication, desde la arquitectura básica hasta la promoción del standby, proporcionando todos los comandos necesarios para una implementación eficaz y segura. Prepárate para hacer que tu base de datos PostgreSQL sea resiliente contra los imprevistos.

Requisitos Previos / Entorno de Prueba

Para seguir esta guía, necesitarás dos servidores Linux (por ejemplo, Ubuntu 24.04 o CentOS Stream 9) con PostgreSQL 16 instalado en ambos. Supondremos que los servidores tienen direcciones IP primary_ip y standby_ip. Todos los comandos se ejecutarán como usuario postgres o root donde se especifique.

Arquitectura Primario-Standby

La arquitectura primario-standby es el corazón de la PostgreSQL Streaming Replication. Un servidor, el primario, gestiona todas las operaciones de escritura (INSERT, UPDATE, DELETE) y de lectura. El otro servidor, el standby, recibe un flujo continuo de modificaciones (los archivos WAL, Write-Ahead Log) del primario y aplica estas modificaciones para mantener una copia exacta y actualizada de la base de datos. Este flujo es unidireccional. En caso de fallo del primario, el standby puede ser promovido a nuevo primario, garantizando la continuidad operativa. Existen diferentes modos de réplica (síncrona, asíncrona), pero para la mayoría de los escenarios, la réplica asíncrona ofrece un buen compromiso entre rendimiento y resiliencia.

Configurar el Servidor Primario

La primera fase consiste en preparar el servidor primario para enviar los archivos WAL al standby. Esto se logra modificando los archivos postgresql.conf y pg_hba.conf.

1. Modificar postgresql.conf: Abre el archivo de configuración (/etc/postgresql/16/main/postgresql.conf en Debian/Ubuntu o /var/lib/pgsql/16/data/postgresql.conf en CentOS/RHEL) y modifica los siguientes parámetros:

    # postgresql.conf (primary)
    wal_level = replica
    max_wal_senders = 3 # Número de conexiones de réplica simultáneas. Aumenta si tienes más standbys.
    archive_mode = on
    archive_command = 'cp %p /var/lib/postgresql/archive/%f' # Opcional, para archivo WAL manual o con herramientas externas
    listen_addresses = '*' # Permite conexiones desde cualquier IP, o especifica 'primary_ip'

wal_level = replica es fundamental para habilitar el envío de los archivos WAL. max_wal_senders define cuántas conexiones de réplica el primario puede gestionar simultáneamente. Un valor de 3 es un buen punto de partida para un solo standby. El archivo WAL es recomendado para el objetivo de punto de recuperación (RPO) y para la recuperación a un punto en el tiempo (PITR).

1. Modificar pg_hba.conf: Este archivo controla la autenticación de los clientes. Debemos permitir que el servidor standby se conecte al primario para la réplica. Agrega la siguiente línea al final del archivo (/etc/postgresql/16/main/pg_hba.conf):

    # pg_hba.conf: host replication replicator standby_ip/32 md5
    host    replication     replicator      standby_ip/32            md5

Esta línea permite al usuario replicator (que crearemos en breve) conectarse para fines de replication desde la dirección IP del standby_ip. El método md5 requiere una contraseña cifrada.

1. Reiniciar PostgreSQL en el primario: Para aplicar los cambios, reinicia el servicio PostgreSQL.

    sudo systemctl restart postgresql

Crear el Usuario de Réplica

Por motivos de seguridad y gestión, es buena práctica crear un usuario dedicado con los mínimos privilegios necesarios para la réplica. Este usuario solo tendrá permiso para leer los archivos WAL.

Conéctate a la base de datos PostgreSQL en el servidor primario como usuario postgres:

psql -U postgres

Luego, ejecuta el comando SQL para crear el usuario replicator (sustituye 'pwd' por una contraseña segura):

CREATE USER replicator REPLICATION LOGIN ENCRYPTED PASSWORD 'pwd';

Este usuario ya está listo para ser utilizado por el servidor standby para conectarse al primario e iniciar el flujo de réplica. El uso de un usuario dedicado mejora la auditabilidad y la gestión de permisos, un principio clave de la ciberseguridad, como recomiendan estándares como ISO 27001:2022.

Configurar el Servidor Standby

En el servidor standby, no es necesario instalar un clúster PostgreSQL vacío. Utilizaremos pg_basebackup para copiar todo el clúster de datos del primario.

1. Detener PostgreSQL en el standby: Si PostgreSQL está en ejecución en el standby, debe detenerse para poder copiar los datos.

    sudo systemctl stop postgresql

1. Eliminar el clúster de datos antiguo (si existe): Si tienes una instalación PostgreSQL existente en el standby, es aconsejable eliminar los datos preexistentes para evitar conflictos.

    sudo rm -rf /var/lib/postgresql/16/main # O la ruta correcta para tu distribución

1. Crear una copia base del primario: Utiliza pg_basebackup para clonar el clúster de datos del primario al standby. Asegúrate de que el usuario postgres tenga permisos de escritura en el directorio de destino.

    # Ejecutar como usuario postgres
    pg_basebackup -h primary_ip -U replicator -D /var/lib/postgresql/16/main -P -R -W

• -h primary_ip: dirección IP del servidor primario.
• -U replicator: usuario de réplica creado anteriormente.
• -D /var/lib/postgresql/16/main: directorio de destino para los datos del clúster en el standby.
• -P: muestra el progreso de la copia.
• -R: crea automáticamente el archivo standby.signal y postgresql.conf con las configuraciones de recuperación, configurando el standby para la réplica. Esta es una novedad de la versión 12 y posteriores, simplificando significativamente la configuración.
• -W: solicita la contraseña del usuario replicator (la que configuraste antes).

Este comando copiará todos los datos y creará los archivos de configuración necesarios para iniciar el standby en modo de recuperación.

Iniciar la Réplica

Después de preparar el standby con pg_basebackup, puedes iniciar el servicio PostgreSQL en el standby.

sudo systemctl start postgresql

El standby se iniciará en modo de recuperación y comenzará a conectarse al primario para recibir los archivos WAL. Revisa los logs de PostgreSQL (/var/log/postgresql/postgresql-16-main.log o similares) en el standby para verificar que la conexión de réplica se ha establecido correctamente. Deberías ver mensajes como starting replication WAL receiver.

Verificar el Estado de la Réplica

Para asegurarte de que la réplica funciona correctamente, puedes ejecutar una consulta en el servidor primario. Conéctate al primario con psql y usa la vista pg_stat_replication:

SELECT * FROM pg_stat_replication;

La salida de esta consulta mostrará una fila por cada conexión de réplica activa. Deberías ver tu servidor standby listado con un estado streaming. Presta atención a las columnas sync_state (debería ser async para la réplica asíncrona y sync para la síncrona) y write_lag, flush_lag, replay_lag que indican el retraso en bytes y tiempo entre primario y standby. Un lag elevado es una señal de alarma y requiere una investigación inmediata.

Promoción del Standby (Failover Manual)

En caso de fallo del servidor primario, deberás promover manualmente el standby a nuevo primario. Este proceso es crítico y debe ejecutarse con cautela para evitar escenarios de split-brain.

1. Verifica que el primario esté realmente caído: Asegúrate de que el primario no esté solo temporalmente inaccesible, sino completamente fuera de servicio. Un doble chequeo es esencial.

1. Promover el standby: En el servidor standby, ejecuta el comando pg_ctl promote o crea el archivo trigger_file.

    sudo pg_ctlcluster 16 main promote # Para Debian/Ubuntu
    # O más genérico:
    # touch /var/lib/postgresql/16/main/trigger_file

Después de la promoción, el standby se convertirá en un servidor primario independiente, aceptando tanto escrituras como lecturas. Todos los demás standbys (si los hay) deberán reconfigurarse para replicar desde este nuevo primario. Esta operación marca un punto de no retorno para el standby, transformándolo en una instancia completamente operativa.

Monitorear el Lag de Réplica

El monitoreo del lag de réplica es crucial para garantizar que tu RPO (Recovery Point Objective) sea respetado. Un lag excesivo significa que, en caso de failover, podrías perder más datos de lo esperado. Además de pg_stat_replication, puedes utilizar herramientas de monitoreo como Prometheus y Grafana para visualizar el lag a lo largo del tiempo. Puedes consultar la documentación oficial de PostgreSQL para más detalles sobre pg_stat_replication: https://www.postgresql.org/docs/current/monitoring-stats.html#PG-STAT-REPLICATION-VIEW.

Métricas clave a monitorear:

• pg_stat_replication.write_lag: tiempo entre la escritura del WAL en el primario y su recepción en el standby.
• pg_stat_replication.flush_lag: tiempo entre la escritura del WAL en el primario y su vaciado a disco en el standby.
• pg_stat_replication.replay_lag: tiempo entre la escritura del WAL en el primario y su aplicación en el standby.

Un valor de lag inferior siempre es preferible. Si el lag aumenta constantemente, podría indicar problemas de red, I/O en el standby o carga excesiva en el primario.

Errores Comunes y Resolución de Problemas

• Conexión rechazada: Revisa pg_hba.conf en el primario y el firewall. Asegúrate de que primary_ip y standby_ip sean correctos y que el puerto PostgreSQL (5432) esté abierto.
• Usuario de réplica no autorizado: Verifica que el usuario replicator haya sido creado con el permiso REPLICATION y que la contraseña sea correcta.
• wal_level no configurado a replica: En el primario, asegúrate de que wal_level esté configurado correctamente y que el servicio PostgreSQL haya sido reiniciado.
• Lag de réplica elevado: Investiga el rendimiento de la red entre el primario y el standby, las capacidades de I/O del standby o la carga del primario. Un disco lento en el standby puede causar un lag significativo.
• Archivo standby.signal faltante: Si no usaste -R con pg_basebackup (o estás configurando versiones más antiguas de PostgreSQL), es posible que debas crear manualmente el archivo standby.signal en el directorio de datos del standby.

Conclusiones con Puntos Clave Operativos

Configurar la PostgreSQL Streaming Replication es una inversión crucial para la resiliencia de tu infraestructura de base de datos. No esperes a que una base de datos crítica se caiga para descubrir la importancia de la alta disponibilidad. Con una planificación cuidadosa y siguiendo los pasos descritos, puedes implementar un sistema robusto que protege tus datos y asegura la continuidad operativa. Recuerda siempre probar tu proceso de failover y monitorear constantemente el lag de réplica. Una base de datos bien replicada es una base de datos segura.

Lee también: PostgreSQL 17: Ajustes Enterprise para Máximo Rendimiento