Mejores Prácticas de Replicación Lógica

Cuidado con las limitaciones de DDL; los cambios de esquema son difíciles. Estas reglas mantienen la replicación lógica estable a través de actualizaciones y evolución del esquema.

Cómo Usar Esta Lista

• Revise antes de añadir tablas a una publicación.
• Úsela como una lista de verificación durante los cambios de versión principales de tipo blue/green.
• Empareje con alertas sobre los bytes de retraso de las ranuras lógicas.
• Comparta con los equipos de aplicaciones que gestionan las migraciones de DDL.

A - Esquema e Identidad

• Cada tabla publicada tiene una clave primaria o REPLICA IDENTITY explícita. Las actualizaciones y eliminaciones se replican de forma fiable.
• Prefiera REPLICA IDENTITY DEFAULT (PK) sobre FULL cuando sea posible. FULL aumenta el volumen de WAL.
• Cree el esquema del suscriptor antes de CREATE SUBSCRIPTION. Las tablas, tipos e índices deben existir en el suscriptor.
• Trate el DDL como una migración coordinada en ambos lados. La replicación lógica no aplica ALTER TABLE automáticamente.
• Use expandir-contraer para cambios de columna. Añada la columna primero en el suscriptor, luego en el publicador, y luego rellene los datos.

B - Publicaciones y Suscripciones

• Prefiera listas de tablas explícitas sobre FOR ALL TABLES en producción. Evite la replicación accidental de tablas sensibles.
• Ejecute ALTER SUBSCRIPTION ... REFRESH PUBLICATION después de ADD TABLE. De lo contrario, las nuevas tablas no se copiarán.
• Documente los filtros de filas como predicados inmutables. Las funciones volátiles rompen las definiciones de publicación.
• Una ranura lógica por suscripción; nombre las ranuras claramente. Las ranuras huérfanas llenan el disco del publicador.
• Elimine las suscripciones con DROP SUBSCRIPTION para limpiar las ranuras del publicador. Elimine ranuras manualmente si la conexión está bloqueada.

C - Operaciones y Retraso

• Alerta sobre el retraso en bytes de confirmed_flush_lsn de la ranura lógica. Mismo riesgo de disco que las ranuras físicas.
• Pausa las suscripciones (enabled = false) durante el mantenimiento del suscriptor. Reanude con una verificación de retraso.
• Mantenga las tablas del suscriptor de solo lectura para los datos publicados. Los conflictos detienen los trabajadores de aplicación.
• Sincronice las secuencias antes del cambio de versión en actualizaciones importantes. Evite errores de clave duplicada en PG 18.4 verde.
• No enrute las suscripciones a través del pool de transacciones de PgBouncer. Use conexiones directas a PostgreSQL.

D - Topología y HA

• No reemplace la HA física con lógica solo para tier-0. Mantenga el standby físico de Patroni para la conmutación por error.
• Ajuste max_replication_slots y max_wal_senders para consumidores lógicos + físicos. Carga combinada en el primario.
• Verifique la sincronización de ranuras de Patroni 3.x después de la conmutación por error. Las ranuras lógicas deben existir en el nuevo primario.
• Pruebe la ruta de actualización principal en staging trimestralmente. Mida la ventana de congelación y la sincronización de secuencias.

E - Seguridad y Cumplimiento

• TLS en la cadena de CONNECTION de la suscripción (sslmode=verify-full). Cifre la replicación entre redes.
• Usuario de replicación dedicado por suscriptor. Mínimo privilegio en el publicador.
• Listas de columnas para minimizar PII en el downstream. Los filtros de filas no sustituyen la autorización en el suscriptor.
• Audite quién puede CREATE PUBLICATION. Las publicaciones exponen flujos de cambios.

Preguntas Frecuentes

Relacionado

• Conceptos Básicos de Replicación Lógica - configuración
• Publicaciones y Suscripciones - filtros
• Actualizar con Replicación Lógica - cambio de versión principal
• Ranuras de Replicación - monitorización de ranuras

Versiones de la pila: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.