Fundamentos de la replicación lógica
La replicación lógica decodifica WAL en cambios a nivel de fila y los aplica en un suscriptor. A diferencia del streaming físico, puede replicar tablas seleccionadas entre bases de datos o versiones principales.
Receta
Publicador en PostgreSQL 18.4 primario; suscriptor en la misma versión principal o una más nueva.
-- Publicador
ALTER SYSTEM SET wal_level = logical;
SELECT pg_reload_conf(); -- reiniciar si wal_level no era logical
CREATE PUBLICATION app_pub FOR TABLE orders, order_items;-- Suscriptor
CREATE SUBSCRIPTION app_sub
CONNECTION 'host=primary.db.internal dbname=appdb user=repl_user password=secret'
PUBLICATION app_pub
WITH (copy_data = true, create_slot = true);Cuándo usar esto: Actualizaciones de versión principal, sincronización selectiva de tablas o alimentación de almacenes de análisis sin clonar el clúster completo.
Ejemplo de trabajo
Replicación lógica de extremo a extremo con verificaciones de estado:
-- Publicador: asegúrese de tener una clave primaria o REPLICA IDENTITY en las tablas replicadas
ALTER TABLE orders REPLICA IDENTITY FULL; -- si no hay PK en una tabla heredada
CREATE PUBLICATION orders_pub FOR TABLE orders;-- Suscriptor
CREATE SUBSCRIPTION orders_sub
CONNECTION 'host=primary.db.internal port=5432 dbname=appdb user=repl_user password=secret sslmode=verify-full'
PUBLICATION orders_pub;-- Monitorizar en el publicador
SELECT subname, pid, received_lsn, latest_end_lsn, last_msg_receipt_time
FROM pg_stat_subscription; -- vacío en el publicador
SELECT slot_name, plugin, active,
pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) AS lag_bytes
FROM pg_replication_slots
WHERE slot_type = 'logical';
-- Monitorizar en el suscriptor
SELECT subname, pid, received_lsn, latest_end_lsn, last_msg_receipt_time
FROM pg_stat_subscription;Lo que esto demuestra:
wal_level = logicalhabilita la decodificación lógica en el publicador.- Las publicaciones definen qué tablas (y opcionalmente filas/columnas) se replican.
- Las suscripciones crean una ranura lógica en el publicador y aplican los cambios localmente.
Análisis en profundidad
Componentes
| Objeto | Se ejecuta en | Propósito |
|---|---|---|
| Publicación | Publicador | Filtro de tabla/columna/fila para cambios |
| Suscripción | Suscriptor | Conexión + trabajadores de aplicación |
| Ranura lógica | Publicador | Conserva WAL hasta que el suscriptor confirma |
| Trabajador de aplicación | Suscriptor | Inserta/actualiza/elimina filas |
Qué se replica
- DML en tablas publicadas:
INSERT,UPDATE,DELETE,TRUNCATE(PostgreSQL 18 admite TRUNCATE en publicaciones). - DDL no se replica automáticamente.
- Las secuencias requieren sincronización manual o las opciones de publicación de secuencias de PostgreSQL 18+.
Sincronización inicial
copy_data = true (predeterminado) ejecuta CREATE TABLE AS o copia paralela al suscribirse. Las tablas grandes necesitan una ventana de mantenimiento o copy_data = false con siembra manual.
Trampas
- Sin clave primaria y REPLICA IDENTITY predeterminado - Las actualizaciones/eliminaciones pueden no replicarse correctamente. Solución: Añadir PK o
REPLICA IDENTITY FULL(WAL más amplio). - DDL solo en el publicador - El esquema del suscriptor se desvía. Solución: Ampliar/contraer migraciones en ambos lados o usar herramientas de migración.
- Desbordamiento de ranura lógica cuando el suscriptor está caído - El disco del publicador se llena. Solución: Alerta sobre ranuras lógicas inactivas; establecer una política de retención.
- Cambio de
wal_levelsin reinicio - La decodificación lógica no está disponible. Solución: Reiniciar PostgreSQL después de aumentarwal_level. - Escrituras conflictivas en el suscriptor - El trabajador de aplicación se detiene ante un conflicto. Solución: Suscriptor de solo lectura para las mismas tablas, o usar manejadores de conflictos (dependiente de la versión).
Alternativas
| Alternativa | Usar cuándo | No usar cuándo |
|---|---|---|
| Streaming físico | HA de clúster completo, menor sobrecarga | Corte entre versiones principales |
| ETL / CDC (Debezium) | Transformar en tránsito | Un simple espejo de tabla es suficiente |
| Foreign Data Wrapper | Lecturas ocasionales entre bases de datos | Necesidad de sincronización continua casi en tiempo real |
Preguntas frecuentes
¿Se requiere la misma versión principal?
El suscriptor debe ser de la misma versión principal o una más nueva que el publicador para la replicación lógica.
¿Puede el suscriptor aceptar escrituras en otras tablas?
Sí, pero evite escrituras en tablas publicadas a menos que maneje los conflictos deliberadamente.
¿La replicación lógica reemplaza las copias de seguridad?
No. Refleja los cambios de fila; no reemplaza las copias de seguridad base y el archivo WAL para PITR.
¿Cuántas suscripciones por publicación?
Múltiples suscriptores pueden usar la misma publicación; cada uno crea su propia ranura lógica.
¿Patroni y replicación lógica?
Ejecute el publicador lógico en el primario de Patroni; después de la conmutación por error, las ranuras se mueven con el primario. Verifique la configuración de sincronización de ranuras en Patroni 3.x.
Relacionado
- Publicaciones y suscripciones - filtros y listas de columnas
- Lógica vs. Física - guía de decisión
- Actualizar con replicación lógica - actualización principal azul/verde
- Ranuras de replicación - riesgo de disco de ranura lógica
Versiones de la pila: Esta página se escribió para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x y PostGIS 3.5+.