Entrevista de datos: ¿Cómo continúa PostgreSQL 18 la replicación lógica después de una conmutación por error?

Planteamiento y caso de uso

Un nodo primario de PostgreSQL 18 envía cambios mediante replicación lógica a un clúster de analítica y a suscriptores externos. El nodo primario puede conmutar por error a un standby físico. Diseñe los slots, las configuraciones, las comprobaciones de suscriptores y el orden de transición para que la replicación lógica se reanude desde la posición correcta sin confundir "standby sincronizado" con "suscriptor al día".

Qué evalúa el entrevistador

• Si distingue entre slots lógicos, slots físicos, retención de WAL y posiciones confirmadas por el suscriptor.
• Si comprende que la sincronización de los slots de conmutación por error es asíncrona y debe demostrarse que está lista antes de la transición.
• Si puede utilizar pg_replication_slots, LSNs y el estado de la suscripción para demostrar un cambio seguro.
• Si gestiona slots inválidos, suscriptores rezagados, transiciones planificadas y fallos inesperados.

Preguntas para aclarar antes de responder

• ¿Son los suscriptores PostgreSQL o sistemas externos, y pueden reconectarse al nuevo nodo primario?
• ¿El RPO permitido es cero, una brecha acotada de LSN o una instantánea de suscripción reconstruible?
• ¿Están configurados los slots de replicación física y las restricciones de standby síncrono entre el primario y el standby?
• ¿La transición es automatizada o manual, y quién congela las escrituras y actualiza el enrutamiento de conexiones?

Estructura de respuesta en 30 segundos

Habilitaría failover para cada slot lógico que deba sobrevivir a un cambio, de modo que su estado se sincronice con el hot standby. También configuraría restricciones de sincronización física para que un suscriptor no pueda observar un avance que el standby que asumirá el control no haya persistido. Antes de la transición, verificaría que cada slot requerido en el standby sea synced, no temporal y no esté invalidado. Promovería el standby, actualizaría las conexiones, verificaría que los suscriptores consuman desde el nuevo primario y luego descongelaría las escrituras. Si la sincronización asíncrona está retrasada, retrasaría el cambio o aceptaría el RPO documentado y el costo de reconstrucción.

Análisis detallado paso a paso

1. Qué almacena un slot de replicación lógica

Un slot lógico almacena el progreso de decodificación y el límite de retención de WAL que aún no ha sido confirmado por los suscriptores. Un slot no es una señal de salud de un suscriptor; un suscriptor detenido puede hacer que el primario retenga WAL y consuma espacio en disco.

2. Creación de un slot de conmutación por error

PostgreSQL 18 admite la configuración de failover al crear un slot lógico, y una opción correspondiente al crear una suscripción. El SQL a continuación es ilustrativo; verifique los argumentos y privilegios exactos según la versión de destino y el método de despliegue.

SELECT *
FROM pg_create_logical_replication_slot('analytics_slot', 'pgoutput', false, true);

El flag de conmutación por error permite que el estado del slot se sincronice con el standby, pero no demuestra que la sincronización se haya completado.

3. Configuraciones de sincronización del standby

El standby debe habilitar la recepción y aplicación de la sincronización de slots lógicos, como sync_replication_slots. El primario puede usar synchronized_standby_slots para requerir que slots físicos particulares se pongan al día primero, evitando que el progreso del suscriptor lógico sobrepase al standby que asumirá el control.

4. Por qué la preparación asíncrona necesita una comprobación separada

La sincronización de slots copia el estado de forma asíncrona. Ante un fallo del primario, el standby puede tener las páginas de datos pero no la última posición del slot. Promover inmediatamente puede dejar a un suscriptor sin su punto de partida o provocar duplicados y brechas.

5. Comprobación del estado del slot antes de la transición

Consulte pg_replication_slots en el standby candidato. Confirme que cada slot requerido esté sincronizado, no sea temporal y no tenga motivo de invalidación; luego compare el resultado con el inventario de suscriptores.

SELECT slot_name,
       synced,
       temporary,
       invalidation_reason,
       confirmed_flush_lsn
FROM pg_replication_slots
WHERE slot_type = 'logical';

Solo cuando todos los slots requeridos pasen la verificación se debe marcar el standby como listo para asumir el control.

6. Comprobaciones adicionales para suscriptores de PostgreSQL

Para suscriptores de PostgreSQL, confirme también que el suscriptor haya consumido una posición compatible con el slot sincronizado. El retraso físico entre primario y standby por sí solo es insuficiente; combine el estado de la suscripción, el último LSN recibido y el retraso de negocio.

7. Cambio de suscriptores externos

Los sistemas externos generalmente no pueden interpretar el estado de los slots de PostgreSQL de forma automática. El orquestador de la transición debe congelar o pausar el consumo, promover el standby, actualizar la conexión y el nombre del slot, y luego usar eventos idempotentes y un desplazamiento de aplicación para demostrar que no se omitieron datos.

8. Rutas de fallo y recuperación

Un cambio planificado puede esperar hasta que todos los slots estén sincronizados. Un fallo inesperado requiere una decisión sobre el RPO: aceptar una brecha, retrasar el tráfico o reconstruir la suscripción. Un antiguo primario recuperado no debe reincorporarse a la ruta de escritura inmediatamente; aíslelo, reconstruya la replicación física y vuelva a comprobar el estado de los slots y suscripciones.

Compensaciones y límites

• Los slots de conmutación por error mejoran la recuperabilidad de la replicación lógica, pero añaden complejidad a la sincronización de slots y a la monitorización de WAL.
• Esperar a la sincronización completa de slots reduce las brechas, pero puede alargar el tiempo de conmutación por error.
• synchronized_standby_slots restringe el progreso lógico en relación con el standby físico; no proporciona cero pérdidas de extremo a extremo para todos los suscriptores externos.
• Los slots inválidos, el almacenamiento casi lleno y los suscriptores detenidos por mucho tiempo requieren alertas y limpieza, no solo un script de transición.

Plan de implementación y evidencia

1. Cree un slot lógico de conmutación por error en un clúster de prueba de PostgreSQL 18 y verifique las configuraciones y privilegios de primario/standby.
2. Inyecte detenciones de suscriptores, acumulación de WAL, slots no sincronizados y pérdidas abruptas del primario; registre los LSNs y los resultados de recuperación.
3. Automatice la consulta previa a la transición en pg_replication_slots y compare su inventario de slots con los suscriptores.
4. Realice simulacros de pausa, promoción, reconexión, puesta al día y reversión en rutas de cambios planificados y de fallos inesperados.
5. Revise los parámetros y límites con respecto a la documentación de PostgreSQL 18 sobre Logical Replication Failover, Logical Decoding y Streaming Replication.

Errores comunes y preguntas de seguimiento

Error 1: Asumir que tener los datos del standby significa que la toma de control lógica está lista

El estado del slot se sincroniza de forma asíncrona. Que las páginas de datos estén al día no demuestra que la posición del slot sea utilizable; inspeccione los campos de sincronización e invalidación.

Error 2: Monitorizar únicamente el retraso de replicación física

Monitoree también el consumo del suscriptor, el LSN del slot confirmado, el WAL retenido y el retraso de negocio. El backlog lógico puede crecer mientras la replicación física parece saludable.

Error 3: Tratar la opción de conmutación por error como un cambio automático

Habilita la sincronización del estado del slot; no promueve el standby, no actualiza conexiones ni valida suscriptores externos. La transición aún necesita orquestación y simulacros.

Pregunta de seguimiento: ¿Se puede promover antes de que un slot esté sincronizado?

Solo con una decisión explícita de RPO, brecha o reconstrucción. La compuerta predeterminada debe esperar la sincronización y registrar el resultado.

Pregunta de seguimiento: ¿Cómo se evita el consumo duplicado?

Persista un ID de evento o LSN de origen, reanude desde una posición verificable después de la transición y utilice un manejo idempotente junto con la reconciliación para la reproducción.