Replicación lógica en PostgreSQL: publicaciones, suscripciones y en qué se diferencia de la replicación en streaming

Qué es

La replicación física (en streaming) envía registros del write-ahead log a un standby que los reproduce bloque a bloque; la documentación del standby establece que la arquitectura de hardware debe ser la misma y que, en general, no es posible enviar el log entre versiones mayores distintas. La replicación lógica, según el capítulo citado, replica objetos de datos y sus cambios en función de su identidad de replicación (normalmente una clave primaria) en un modelo de publicación y suscripción: un publicador define una publicación sobre tablas (opcionalmente limitada a INSERT, UPDATE, DELETE o TRUNCATE, con filtros de fila y listas de columnas), un suscriptor crea una suscripción, una instantánea inicial copia las filas existentes, y los cambios posteriores se aplican en el orden de los commits, lo que la documentación llama replicación transaccional. Cada suscripción consume los cambios a través de un slot de replicación en el publicador.

Por qué importa

Un standby en streaming es una copia completa para conmutación por error y escalado de lecturas; no admite escritura y no puede ser selectivo. La replicación lógica lleva un subconjunto de tablas a una base de datos que puede tener una versión mayor distinta, una plataforma distinta, ser un destino de consolidación para análisis, o ser un suscriptor que también mantiene sus propias tablas. La lista de casos de uso del capítulo incluye la replicación entre versiones mayores, lo que hace posible una actualización con una conmutación de segundos.

Cómo aplicarlo

• Dar a cada tabla publicada una clave primaria; una tabla sin una clave adecuada necesita REPLICA IDENTITY FULL, que la documentación describe como una alternativa con búsquedas de fila ineficientes en el suscriptor.
• Copiar antes el esquema a mano (pg_dump --schema-only): la página de restricciones indica que el esquema de la base de datos y los comandos DDL no se replican, y recomienda aplicar primero al suscriptor los cambios de esquema que sean aditivos.
• Planificar las secuencias: los datos de las secuencias no se replican, así que, antes de una conmutación, hay que fijar las secuencias del suscriptor por encima de los valores actuales del publicador.
• Vigilar el slot. Un suscriptor caído conserva su slot, y el slot retiene WAL en el publicador hasta que se llena el disco; max_slot_wal_keep_size acota esa retención al precio de invalidar un slot que se quede demasiado atrás.
• Tratar las tablas replicadas como de solo lectura en el suscriptor. La página de conflictos indica que los cambios entrantes se aplican incluso si la fila se modificó localmente, y que los datos entrantes que violan una restricción (por ejemplo, una fila local con la misma clave única) detienen la replicación hasta que se resuelva manualmente.

Trampas

Los objetos grandes no se replican, y las vistas, las vistas materializadas y las tablas foráneas no pueden publicarse. Un cambio de esquema en el publicador que la tabla del suscriptor no puede aceptar detiene la replicación hasta que se corrige el suscriptor. La replicación lógica no es una copia de seguridad: un DELETE o un TRUNCATE en el publicador se aplica fielmente.