Planteamiento y alcance
Operas un consumidor de CDC que lee cambios de una base de datos PostgreSQL en producción. Durante una conmutación planificada (switchover) o una falla inesperada, ¿cómo permitirías que el nuevo primario continúe atendiendo el mismo slot de replicación lógica sin ocultar duplicados, vacíos (gaps), acumulación de WAL o una afirmación injustificada de cero pérdidas? Explica los slots de failover de PostgreSQL 18, las verificaciones de sincronización, las reconexiones de consumidores, el monitoreo y la reversión (rollback).
PostgreSQL documenta que los slots de replicación lógica se pueden sincronizar con un standby físico, pero la sincronización de slots es asíncrona. Antes de promover un standby, los slots requeridos deben estar presentes y reportarse como failover_ready. Esta pregunta de confiabilidad de backend evalúa si puedes conectar las capacidades de la base de datos, la semántica del consumidor y la orquestación de failover en un proceso verificable.
Lo que evalúa el entrevistador
- Distinguir la replicación física de WAL, los slots de replicación lógica y las confirmaciones (acknowledgements) del consumidor.
- Explicar los límites de la opción de slot
failoverysynchronized_standby_slots. - Manejar conmutaciones planificadas y fallas repentinas con diferentes ventanas de pérdida y duplicación.
- Saber que un standby activo no es prueba de que cada slot lógico esté listo.
- Diseñar alertas para la retención de WAL, el retraso (lag) de slots, las reconexiones y el retardo del consumidor.
- Asignar el descubrimiento de conexiones, el cercado (fencing) y la idempotencia downstream a componentes explícitos.
Preguntas aclaratorias para hacer
- ¿Es el consumidor otro suscriptor de PostgreSQL o un cliente de CDC que no es de PostgreSQL, como Debezium? Las verificaciones de preparación difieren.
- ¿El objetivo es un cambio planificado con pérdida cercana a cero o un punto de recuperación acotado tras una caída (crash)?
- ¿Puede el downstream deduplicar por LSN, ID de transacción, ID de evento o clave de negocio?
- ¿Utilizan el primario y el standby la misma versión mayor de PostgreSQL y el mismo plugin de salida?
- ¿Qué coordinador promueve el standby, cambia el descubrimiento, cerca el primario anterior y previene el split-brain?
Respuesta de 30 segundos
Definiría primero el punto de recuperación y la tolerancia a duplicados, y luego modelaría la sincronización de slots, la promoción, la reconexión y la idempotencia downstream como una máquina de estados. Habilitaría el failover para cada slot lógico que deba sobrevivir a la promoción y verificaría cada slot en el standby, incluyendo su presencia, estado de sincronización y valor de failover_ready. Durante un cambio, cercaría el primario anterior antes de cambiar el descubrimiento. El consumidor reanudaría desde un LSN registrado; las transacciones reproducidas se volverían inofensivas mediante idempotencia por LSN o clave de negocio. Monitorearía el retraso de slots, el WAL retenido, el retardo del consumidor y los resultados de reconexión, y no trataría la sincronización asíncrona de slots como una garantía de cero pérdidas.
Análisis detallado paso a paso
1. Definir la semántica de datos
Incorpora RPO, RTO y el manejo de duplicados en el diseño. Una conmutación planificada puede esperar a que se sincronicen los slots requeridos; una falla repentina solo puede recuperarse a partir del WAL que llegó al standby promovido. El consumidor debe persistir su último LSN confirmado o posición equivalente, y los efectos secundarios deben usar claves de idempotencia.
2. Configurar slots lógicos compatibles con failover
PostgreSQL 18 admite slots lógicos que pueden sincronizarse con un standby. Habilita la opción de failover al crear el slot o la suscripción, y mantén un inventario de cada slot que la flota de consumidores necesita. No olvides los slots de sincronización de tablas ni los consumidores secundarios.
-- Illustrative only: allow a logical slot to synchronize to a standby
SELECT *
FROM pg_create_logical_replication_slot('cdc_orders', 'pgoutput', false, true);La firma exacta y los permisos deben coincidir con la versión de PostgreSQL y el plugin desplegados. El ejemplo no puede reemplazar las comprobaciones de configuración y compatibilidad.
3. Transferir el estado del slot a través de la replicación física
Configura el standby físico para recibir WAL y utiliza synchronized_standby_slots donde el flujo de trabajo de failover documentado lo requiera. Antes de la promoción, inspecciona pg_replication_slots en el standby y confirma que cada slot requerido exista, esté sincronizado y sea failover_ready. La copia de slots es asíncrona, por lo que una conexión de transmisión (streaming) saludable por sí sola es insuficiente.
4. Conmutación planificada (switchover)
Pausa o drena los consumidores de CDC y registra sus últimas posiciones confirmadas. Detén las escrituras en el primario anterior y espera la replicación física y la sincronización de slots. Concilia el inventario de slots en ambos nodos, promueve únicamente después de que todos los slots requeridos estén listos, luego cambia el descubrimiento de conexiones y reanuda los consumidores desde los mismos slots lógicos. Si el límite se reproduce, las comprobaciones de LSN o la idempotencia downstream eliminan los efectos duplicados.
5. Falla repentina y protección contra split-brain
Una caída no puede esperar a la sincronización de slots. Cerca el primario anterior antes de que pueda regresar y escribir, luego calcula el punto de recuperación demostrado por el nodo promovido. El coordinador debe garantizar que solo un nodo sea escribible. Después de los cambios en DNS, VIP o descubrimiento de servicios, los consumidores deben validar la identidad del servidor y la presencia del slot. Un slot no sincronizado debe reportarse como una transferencia incompleta, con recuperación manual o reconstrucción de suscripción como una opción explícita.
6. Monitorear la retención de WAL y el progreso del consumidor
Rastrea el restart_lsn, confirmed_flush_lsn, el retraso del slot, el WAL retenido, el recuento de reconexiones y el retardo de extremo a extremo de cada slot. Un slot abandonado puede impedir el reciclaje de WAL y llenar el disco. Separa una alerta para "el slot existe" de "el consumidor ha procesado hasta el LSN objetivo", y establece tiempos de espera, regulaciones (throttles) y umbrales de intervención humana para la recuperación.
7. Reversión, reconstrucción y aceptación
Si las verificaciones de preparación fallan, no promuevas automáticamente; mantén el primario anterior o entra en un modo degradado declarado. Ejercita conmutaciones planificadas, pérdida repentina de energía, desconexión de consumidores, sincronización demorada de slots y reinicio del primario anterior. Registra la última confirmación (commit), el primer evento en el nuevo primario, el recuento de duplicados, el recuento de vacíos, el RTO y el uso máximo de disco. Rastrea cada vacío hasta un LSN.
Respuesta de ejemplo de alta calidad
Modelaría el flujo de trabajo en seis estados: slots listos, primario anterior cercado, standby promovido, descubrimiento cambiado, consumidores reanudados y posiciones downstream confirmadas. Habilitaría el failover para los slots lógicos requeridos e inspeccionaría synchronized_standby_slots y pg_replication_slots en el standby hasta que cada slot esté presente y sea failover_ready. Debido a que la sincronización es asíncrona, un standby activo no es evidencia suficiente para una promoción segura.
Para un cambio planificado, pausaría los consumidores, congelaría las escrituras en el primario anterior, esperaría la replicación física y la sincronización de slots, y luego promovería. Para una caída, cercaría el primario anterior y declararía el RPO recuperable en lugar de afirmar cero pérdidas. Los consumidores se reconectarían y reanudarían desde los LSN almacenados; la idempotencia downstream absorbería la reproducción. Finalmente, monitorearía el retraso de slots, la retención de WAL, el retardo de consumidores, las reconexiones y los vacíos, y validaría el RPO y el RTO con simulacros de pérdida de energía y demora de sincronización.
Errores comunes
- Promover porque el standby está en línea → la sincronización de slots aún puede estar incompleta → verifica la presencia de cada slot, el estado de sincronización y
failover_ready. - Tratar un slot lógico como prueba de que el consumidor procesó los datos → el estado del slot difiere de la confirmación downstream → rastrea los LSN y las posiciones de los consumidores por separado.
- Prometer cero pérdidas ante una caída → el WAL no sincronizado puede no estar disponible → declara el RPO planificado y no planificado por separado.
- Cambiar el DNS sin cercar el primario anterior → las escrituras split-brain siguen siendo posibles → cerca primero, luego promueve y cambia el descubrimiento.
- Ignorar un slot estancado → el WAL retenido puede agotar el disco → alerta sobre el retraso, el disco y la antigüedad máxima de retención.
- Probar solo la promoción de la base de datos → los consumidores, plugins y efectos downstream pueden fallar → ejecuta un simulacro de reproducción de extremo a extremo.
Preguntas de seguimiento y respuestas
¿Demuestra failover_ready que no se perderá ningún evento?
No. Indica que el slot lógico correspondiente está sincronizado con el standby de destino y puede continuar después de la promoción. La pérdida todavía depende de la replicación física en el momento de la falla, la posición de confirmación del consumidor y la semántica de procesamiento downstream.
¿Por qué pausar a los consumidores durante un cambio planificado?
Pausar fija las últimas posiciones confirmadas y evita que un consumidor lea del primario anterior y del nuevo al mismo tiempo. Es posible un coordinador más elaborado, pero debe demostrar que previene el split-brain, el desorden y las confirmaciones ambiguas.
¿Cómo debe un cliente de CDC que no sea de PostgreSQL verificar la preparación?
No puede reutilizar las consultas de suscripción de PostgreSQL directamente. Debe mantener su propio inventario de slots y verificaciones de estado, verificar los slots sincronizados en el standby y luego validar la nueva conexión y la continuidad de posición utilizando su protocolo de cliente.
¿Qué pasa si un slot no está sincronizado pero el negocio debe recuperarse?
Declara el RPO real y elige un punto de recuperación conservador. Reconstruye el slot, toma una nueva instantánea (snapshot) o compensa desde copias de seguridad si es necesario. No presentes un estado de replicación no verificado como una recuperación sin pérdidas.
¿Cómo evitas que el primario anterior regrese?
Utiliza cercado por coordinador o nube, aislamiento de red y rotación de credenciales de escritura. Un cambio de DNS por sí solo no puede evitar que el primario anterior acepte escrituras.
¿Cómo demuestras que la reproducción no causó efectos secundarios duplicados?
Deduplica por LSN de transacción, ID de evento o una clave de idempotencia, y luego registra recuentos de reproducción, totales comerciales finales y restricciones de orden durante un simulacro. Compara posiciones auditables antes y después del cambio.