Cómo configurar replicación en streaming en PostgreSQL
La replicación en streaming mantiene un servidor standby copiando el WAL del primario casi en tiempo real. Es la base de la alta disponibilidad y de tener una réplica de solo lectura.
- 1
Prepara el primario para replicar
Define wal_level en replica y suficientes slots. Reinicia para aplicar los cambios de postgresql.conf.
-- postgresql.conf wal_level = replica max_wal_senders = 10 max_replication_slots = 10 - 2
Crea un rol de replicación y permite su conexión
El standby se conecta con un rol con atributo REPLICATION. Agrega la regla correspondiente en pg_hba.conf.
CREATE ROLE replicador WITH REPLICATION LOGIN PASSWORD 'cambia_esto'; -- pg_hba.conf: -- host replication replicador <ip_standby>/32 scram-sha-256 - 3
Clona el primario en el standby con pg_basebackup
Ejecutado en el servidor standby (con su directorio de datos vacío), copia todo el clúster y genera la configuración de standby con -R.
pg_basebackup -h <ip_primario> -U replicador -D /var/lib/postgresql/16/main -Fp -Xs -P -R - 4
Arranca el standby y verifica el lag
Inicia el standby y consulta el retraso de replicación desde el primario. Un lag bajo y estable indica que la réplica va al día.
SELECT client_addr, state, replay_lag FROM pg_stat_replication;
// el error común
Un slot de replicación abandonado (cuando el standby se cae y no vuelve) hace que el primario retenga WAL indefinidamente y llene el disco. Monitorea los slots y elimina los que ya no usas.
// cuándo conviene un experto
La alta disponibilidad real necesita más que un standby: failover automático, monitoreo de lag, pruebas de conmutación y un plan de retorno al primario. En dba.mx montamos HA con Patroni o repmgr y lo probamos antes de que el primario falle de verdad.
Agenda un Escaneo — desde USD $550Esta guía es orientativa y usa comandos de referencia. En producción, adapta a tu versión y prueba en un ambiente seguro primero.