En entornos de alta disponibilidad, PostgreSQL permite implementar replicación mediante dos enfoques principales: envío de archivos WAL y replicación en streaming. A continuación se detalla la configuración para un clúster maestro‑esclavo con PostgreSQL 12 sobre CentOS 7, incluyendo el procedimiento de conmutación por error.

1. Envío de Archivos WAL (Log Shipping)

El método tradicional consiste en que el servidor maestro opera en modo de archivado continuo, generando segmentos WAL que son transferidos al esclavo. Este último permanece en modo de recuperación continua, aplicando los archivos rceibidos. La principal ventaja es que no requiere modificar las tablas y el impacto en el rendimiento del maestro es bajo.

• El ancho de banda necesario depende de la tasa de transacciones del maestro.
• El envío es asíncrono: los registros WAL se transfieren después de confirmar la transacción, por lo que existe una ventana de pérdida de datos si el maestro falla antes de la transferencia.
• Con archive_timeout se puede reducir la ventana a pocos segundos, aunque aumenta el uso de ancho de banda.

2. Replicación en Streaming

A partir de PostgreSQL 9.x se introdujo la replicación en streaming, donde el esclavo recibe los registros WAL a través de una conexión TCP a medida que se generan, sin esperar a que se complete un segmento completo.

• Por defecto es asíncrona, pero la latencia suele ser inferior a un segundo si el esclavo tiene capacidad suficietne.
• La ventana de pérdida de datos es menor que con el envío de archivos y no necesita archive_timeout para reducirla.
• Para cambiar de envío de archivos a streaming, basta con configurar primary_conninfo en recovery.conf (o postgresql.auto.conf) y ajustar listen_addresses y la autenticación.

Entorno

• Sistema operativo: CentOS 7
• Base de datos: PostgreSQL 12

Instalación de PostgreSQL 12

Se asume que PostgreSQL 12 ya está instalado en ambos servidores. Si no, utilizar el gestor de paquetes correspondiente (yum, dnf, etc.) o la instalación desde código fuente.

Configuración del Servidor Maestro

1. Crear un usuario con permisos de replicación: ``` CREATE ROLE replicador LOGIN REPLICATION ENCRYPTED PASSWORD 'ClaveDelRep';

2. Editar postgresql.conf (ubicación típica: /var/lib/pgsql/12/data/postgresql.conf): ``` listen_addresses = '*' archive_mode = on archive_command = 'test ! -f /var/lib/pgsql/12/data/archivo/%f && cp %p /var/lib/pgsql/12/data/archivo/%f' wal_level = replica max_wal_senders = 3 wal_keep_segments = 20 wal_sender_timeout = 60s max_connections = 100

3. Editar pg_hba.conf para permitir la conexión del esclavo: ``` host replication replicador IP_del_esclavo/32 md5

4. Reiniciar PostgreSQL: ``` pg_ctl -D /var/lib/pgsql/12/data -l logfile restart

Configuración del Servidor Esclavo

1. Verificar conectiviadd con el maestro: ``` psql -h IP_maestro -U postgres

2. Detener el servicio en el esclavo: ``` pg_ctl -D /var/lib/pgsql/12/data -l logfile stop

3. Limpiar el directorio de datos: ``` rm -rf /var/lib/pgsql/12/data/*

4. Realizar una copia de seguridad base desde el maestro: ``` pg_basebackup -h IP_maestro -p 5432 -U replicador -Fp -Xs -Pv -R -D /var/lib/pgsql/12/data

5. Verificar que se haya creado el archivo standby.signal (indica modo en espera). Si no, crearlo manualmente: ``` touch /var/lib/pgsql/12/data/standby.signal

6. Editar postgresql.conf en el esclavo: ``` primary_conninfo = 'host=IP_maestro port=5432 user=replicador password=ClaveDelRep' recovery_target_timeline = 'latest' max_connections = 120 hot_standby = on max_standby_streaming_delay = 30s wal_receiver_status_interval = 10s hot_standby_feedback = on

7. Iniciar el esclavo: ``` pg_ctl -D /var/lib/pgsql/12/data -l logfile start

Verificación del Estado de la Replicación

En el maestro, ejecutar:

SELECT client_addr, sync_state FROM pg_stat_replication;

Debería aparecer la IP del esclavo con estado async (replicación asíncrona).

Conmutación por Error (Failover)

Cuando el maestro falla, se puede promover el esclavo a maestro usando el comando pg_ctl promote.

1. Detener el maestro (si aún está funcionando, o simular la falla): ``` pg_ctl -D /var/lib/pgsql/12/data -l logfile stop

2. En el esclavo, ejecutar la promoción: ``` su - postgres -c "pg_ctl promote"

   
   La salida indicará `server promoting`.
   

3. Verificar los logs del esclavo para confirmar: ``` cat /var/lib/pgsql/12/data/pg_log/postgresql-*.log

Ahora el antiguo esclavo se ha convertido en el nuevo maestro, aceptando operaciones de escritura. Para reincorporar el antiguo maestro (cuando se recupere) como esclavo, será necesario repetir el proceso de configuración esclava.