PostgreSQL
Replicación física y lógica
Replicación física y lógica, streaming, slots, publicaciones y suscripciones para alta disponibilidad, lectura y distribución selectiva de cambios.
- Última actualización
- Actualizada
- Nivel
- Profundización
PostgreSQL
Replicación física y lógica, streaming, slots, publicaciones y suscripciones para alta disponibilidad, lectura y distribución selectiva de cambios.
Replicar no significa que todas las lecturas sean actuales ni que el sistema pueda promoverse sin pérdida. Debes entender qué se copia, con qué retraso y quién decide el failover.
Transmite WAL y reproduce cambios a nivel de cluster:
primary → WAL → standbyReplica todas las databases y objetos del cluster. El standby es binariamente compatible y normalmente read-only.
Decodifica cambios de tablas publicadas:
publisher → logical decoding → subscriberPermite seleccionar tablas y cruzar major versions en escenarios compatibles, pero no replica automáticamente todo el DDL, sequences ni objetos.
Componentes:
wal_level compatible.primary_conninfo.Standby aplica WAL continuamente.
COMMIT no espera réplica. Menor latencia, pero un failover puede perder WAL no recibido/aplicado.
synchronous_standby_names y synchronous_commit pueden exigir confirmación de standby. Reduce RPO, aumenta latencia y dependencia de disponibilidad.
Modos pueden esperar recepción, flush o apply según configuración. Define exactamente qué garantía necesita el negocio.
No es una sola métrica:
Una réplica puede haber recibido WAL pero todavía no aplicarlo.
Problema read-after-write:
request escribe en primary
→ siguiente request lee replica retrasada
→ parece que el dato no existeEstrategias:
No ocultes el lag como bug aleatorio.
Queries largas en réplica pueden entrar en conflicto con WAL que necesita eliminar versiones o aplicar DDL. PostgreSQL puede cancelar la query para continuar recovery.
hot_standby_feedback reduce cancelaciones, pero puede aumentar bloat en primary al retener versiones. Es un trade-off operativo.
Un slot evita reciclar WAL que el consumidor necesita.
Beneficio: consumidor puede desconectarse sin perder continuidad.
Riesgo: si se detiene, pg_wal crece hasta llenar disco.
Monitorea:
restart_lsn.confirmed_flush_lsn.active.Nunca borres un slot sin entender si el consumidor puede reconstruirse.
Promover:
SELECT pg_promote();Pero un sistema completo necesita:
La promoción manual sin fencing puede crear dos writers.
Cada promoción crea una nueva timeline. WAL y recovery deben seguir la historia correcta. Esto importa en PITR y reintegración.
CREATE PUBLICATION app_pub
FOR TABLE customers, orders;Subscriber:
CREATE SUBSCRIPTION app_sub
CONNECTION '...'
PUBLICATION app_pub;Normalmente realiza initial table sync y después aplica cambios.
Principalmente INSERT, UPDATE, DELETE y TRUNCATE de tablas publicadas. Necesita replica identity para localizar filas actualizadas/eliminadas.
ALTER TABLE events REPLICA IDENTITY FULL;FULL aumenta WAL y coste; una PK/unique adecuada es mejor.
Debes preparar subscriber y coordinar migrations.
La replicación lógica estándar asume normalmente un solo writer por fila/conjunto. Si el subscriber también escribe, pueden aparecer unique violations o divergencia. Multi-master necesita arquitectura especializada.
El apply worker usa replication role/context; triggers ordinarios pueden no ejecutarse según configuración. No dependas de triggers para reconstruir efectos sin probar el comportamiento exacto.
La replicación lógica puede reducir downtime entre major versions:
Necesitas estrategia para DDL durante coexistencia y rollback.
Physical:
pg_stat_replication.Logical:
pg_stat_subscription.Alta disponibilidad y disaster recovery convierte réplicas, backups y decisiones humanas en un sistema recuperable.