El Modelo de Replicación Lógica

La replicación lógica toma el mismo registro de escritura anticipada (WAL) que la replicación de streaming física envía byte por byte y, en cambio, lo decodifica en un flujo de cambios a nivel de fila: inserciones, actualizaciones y eliminaciones en tablas específicas.

Ese único cambio, de bytes a filas, es lo que permite a la replicación lógica hacer cosas que la replicación física estructuralmente no puede, como replicar un subconjunto de tablas o mover datos entre diferentes versiones principales de PostgreSQL.

Esta página construye el modelo mental detrás de las publicaciones, suscripciones y decodificación lógica para que las páginas más procedurales de esta sección tengan sentido como aplicaciones de una idea subyacente en lugar de una lista de características no relacionadas.

Resumen

• La replicación lógica decodifica WAL en cambios a nivel de fila y los aplica en un suscriptor, en lugar de replicar la base de datos byte por byte.
• Por Qué Importa: Permite la sincronización selectiva de tablas, actualizaciones entre versiones y la alimentación de sistemas posteriores sin clonar un clúster completo.
• Conceptos Clave: decodificación lógica, publicación, suscripción, identidad de réplica, slot de replicación lógica, worker de aplicación.
• Cuándo Usar: Actualizaciones de versión principal, replicación de un subconjunto de tablas, alimentación de sistemas de análisis o búsqueda, y consolidación de bases de datos múltiples.
• Limitaciones / Compensaciones: DDL no se replica automáticamente, y el modelo agrega una sobrecarga de decodificación ausente en el streaming físico.
• Temas Relacionados: replicación lógica vs física, publicaciones y suscripciones, actualización con replicación lógica.

Fundamentos

El registro de escritura anticipada (WAL) de PostgreSQL registra cambios a un nivel bajo, cerca del diseño de la página física, que es exactamente lo que la replicación física quiere, pero no es directamente utilizable como "la fila X cambió a este valor".

La decodificación lógica es el proceso que lee ese WAL de bajo nivel y lo reconstruye en un flujo legible de cambios lógicos, utilizando un plugin de decodificación para traducir el WAL físico de nuevo a operaciones a nivel de fila.

Una publicación, creada en la base de datos de origen, nombra el conjunto de tablas cuyos cambios deben exponerse a través de este proceso de decodificación, actuando como un filtro sobre lo que el resto del mecanismo verá.

Una suscripción, creada en la base de datos de destino, apunta a una publicación, abre una conexión de replicación y aplica continuamente los cambios que recibe a través de un proceso dedicado de worker de aplicación.

Piense en la replicación física como fotocopiar cada página de un libro de contabilidad, mientras que la replicación lógica lee el libro de contabilidad en voz alta y dicta solo las transacciones que alguien eligió escuchar.

Ese modelo de dictado es la razón por la cual la replicación lógica puede conectar bases de datos que no son idénticas, ya que el suscriptor solo necesita tablas y columnas coincidentes para lo que se suscribe, no un clúster idéntico.

Poner en marcha una suscripción por primera vez también requiere una sincronización inicial, una copia masiva de las filas existentes antes de que comiencen a aplicarse los cambios continuos, para que un nuevo suscriptor no comience desde una tabla vacía y solo vea los cambios a partir de ese momento.

-- Publicador: expone dos tablas a cualquier suscriptor que se conecte
CREATE PUBLICATION app_pub FOR TABLE orders, order_items;

Esa única declaración es el modelo mental completo en miniatura: nombrar las tablas, y todo lo que está aguas abajo se trata de quién escucha y cómo se ponen al día.

Mecánica e Interacciones

El paso de decodificación depende de la identidad de réplica, una configuración por tabla que le dice a PostgreSQL qué columnas incluir en el WAL para actualizaciones y eliminaciones, para que el suscriptor pueda encontrar la fila correcta.

Por defecto, la identidad de réplica utiliza la clave primaria de la tabla, que es suficiente información para identificar una fila única en el lado del suscriptor sin enviar cada columna en cada cambio.

Una tabla sin clave primaria necesita REPLICA IDENTITY FULL en su lugar, que incluye toda la fila antigua en el WAL para que las eliminaciones y actualizaciones aún puedan coincidir, a costa de un volumen de WAL significativamente mayor para esa tabla.

Cada suscripción activa está respaldada por un slot de replicación lógica en el publicador, conceptualmente similar a los slots físicos que utiliza el streaming de replicación, reteniendo el WAL hasta que el suscriptor confirma que ha aplicado un punto determinado.

Esa retención tiene el mismo doble filo que los slots físicos: protege a un suscriptor temporalmente desconectado de perder cambios, y también puede crecer de forma ilimitada en el publicador si un suscriptor desaparece y nadie se da cuenta.

El borde más afilado de todo el modelo es que DDL no se replica, lo que significa que un cambio de CREATE TABLE, ALTER TABLE o índice realizado en el publicador no tiene una contraparte automática en el suscriptor.

Esta es una elección de diseño deliberada en lugar de un descuido, ya que aplicar automáticamente cambios de esquema arbitrarios en un suscriptor que podría tener un esquema, extensiones o consumidores posteriores diferentes sería mucho más peligroso que requerir un paso explícito.

En la práctica, los equipos manejan esto con la disciplina de migración de expansión-contracción: aplican cambios de esquema compatibles en ambos lados de manera coordinada, utilizando herramientas en lugar de depender de la replicación para propagar la estructura.

Los conflictos son la otra mecánica que vale la pena internalizar, ya que un worker de aplicación que encuentra una violación de restricción, como una clave duplicada de una fila que ya existe en el suscriptor, simplemente deja de aplicar cambios hasta que el conflicto sea resuelto por un operador.

Ese comportamiento de fallo-parada es intencional: omitir o sobrescribir silenciosamente datos en conflicto haría que la replicación lógica fuera impredecible, por lo que PostgreSQL expone el problema ruidosamente y se detiene.

Consideraciones Avanzadas y Aplicaciones

A escala, la granularidad a nivel de fila de la replicación lógica se convierte tanto en su mayor activo como en su mayor superficie operativa, ya que cada tabla que agregas a una publicación es una tabla cuya identidad de réplica, costo de sincronización inicial y comportamiento de conflicto ahora posees.

Las actualizaciones de versión principal son el caso de uso distintivo del modelo, ya que un suscriptor lógico puede ejecutar una versión principal de PostgreSQL más nueva que su publicador, lo que convierte lo que solía requerir tiempo de inactividad en un corte azul-verde: configurar un suscriptor en la nueva versión, dejar que se ponga al día, y luego redirigir el tráfico.

La replicación selectiva también permite patrones arquitectónicos que la replicación física no puede, como consolidar varias bases de datos de origen en un único almacén de datos analíticos, o distribuir una única fuente a varios consumidores posteriores con subconjuntos de tablas diferentes.

Las herramientas de captura de datos de cambios como Debezium ocupan un territorio adyacente, leyendo el mismo flujo de decodificación lógica pero transformándolo y enrutándolo a destinos no PostgreSQL como Kafka, lo que las convierte en una extensión natural de este modelo en lugar de una competencia.

Las secuencias siguen siendo una brecha persistente en el modelo, ya que los valores de las secuencias no forman parte del DML a nivel de fila y, históricamente, requerían sincronización manual después de un corte, un área donde las versiones recientes de PostgreSQL han agregado soporte específico.

El patrón que se mantiene en producción es tratar la replicación lógica como una primitiva de sincronización precisa y con ámbito de tabla, recurriendo al streaming físico cuando el objetivo es un standby de clúster completo y reservando la replicación lógica para cuando la selectividad o la flexibilidad de versión sean el requisito real.

Conceptos Erróneos Comunes

• "La replicación lógica es solo una versión más lenta de la replicación de streaming." Resuelve un problema completamente diferente, intercambiando la fidelidad del clúster completo por selectividad a nivel de tabla y compatibilidad entre versiones que la replicación física no puede proporcionar.
• "Los cambios de esquema se propagan automáticamente como los cambios de datos." DDL está deliberadamente excluido del modelo, y los cambios de esquema deben aplicarse al publicador y suscriptor a través de un proceso explícito y coordinado.
• "Una suscripción es una copia de seguridad." Es un mecanismo de sincronización en vivo vulnerable a las mismas eliminaciones accidentales y corrupción que la fuente, y no reemplaza la recuperación a punto en el tiempo de los archivos WAL.
• "Cualquier tabla se puede publicar sin cambios." Una tabla sin clave primaria necesita REPLICA IDENTITY FULL antes de que las actualizaciones y eliminaciones se repliquen correctamente, y omitir este paso rompe silenciosamente esas operaciones.
• "Los conflictos se resuelven solos." Un worker de aplicación se detiene ante un conflicto en lugar de adivinar la resolución, lo que significa que las suscripciones no supervisadas pueden dejar de aplicar cambios silenciosamente durante largos períodos.

Preguntas Frecuentes

Relacionados

• Fundamentos de la Replicación Lógica - configuración práctica de publicación y suscripción
• Publicaciones y Suscripciones - filtrado de tablas, filas y columnas
• Lógica vs Física - una guía práctica de decisión entre los dos modelos
• Actualización con Replicación Lógica - cortes de versión principal azul-verde
• Explicación de la Replicación de Streaming - el modelo de replicación física con el que contrasta

Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (versión principal estable 18, línea de mantenimiento 17 también soportada).