Pregunta y contexto
Un publicador de PostgreSQL 18 atiende una suscripción de análisis, un consumidor de auditoría y trabajos temporales de backfill. Algunos consumidores permanecen fuera de línea, lo que impide el reciclaje de WAL y consume disco rápidamente. Diseñe el despliegue, la observabilidad, la invalidación y la recuperación para idle_replication_slot_timeout.
Qué evalúa el entrevistador
- Si explica por qué los slots retienen WAL y cuándo surte efecto realmente un tiempo de espera por inactividad.
- Si distingue entre slots lógicos y físicos, recuperación de suscripciones y límites de reconstrucción.
- Si diseña salvaguardas de eliminación, alertas, auditabilidad y controles de presión de disco.
- Si proporciona una ruta de nueva captura de instantánea (resnapshot), reconstrucción o confirmación humana tras la recuperación del consumidor.
Preguntas aclaratorias previas
Semántica del consumidor
¿A qué sirve cada slot? ¿Se pueden perder los datos generados durante el tiempo de inactividad o el consumidor debe reanudarse desde un límite específico? ¿Tiene un slot temporal de backfill un tiempo de vida máximo explícito?
Recursos y ventanas
¿Cuánto WAL y disco quedan, y cuáles son el restart_lsn y el retraso (lag) del consumidor de cada slot? ¿Con qué frecuencia se ejecutan los checkpoints? ¿Se pueden reconstruir las suscripciones o los consumidores durante una ventana de mantenimiento?
Autoridad de cambio
¿Quién aprueba la invalidación automática? ¿Se requiere primero la confirmación del consumidor, un ticket o una aprobación dual? ¿Qué slots deben protegerse permanentemente para recuperación ante desastres o auditoría de cumplimiento?
Una respuesta en 30 segundos
Haremos un inventario del propietario, propósito, actividad y WAL retenido de cada slot, para luego clasificar los slots en críticos, recuperables y temporales. Los slots recuperables reciben un tiempo de espera por inactividad con alertas anticipadas; los slots críticos generan alertas sin invalidación automática. Dado que la invalidación ocurre durante un checkpoint, registre el estado del slot, el motivo y las métricas de disco en el registro de auditoría. En la recuperación, elija reanudar, tomar una nueva instantánea o restaurar desde backup según el contrato de pérdida de datos.
Solución detallada
1. Explicar la retención de WAL por slots
Un slot de replicación hace que el publicador retenga el WAL necesario para un consumidor que no lo ha confirmado. Un slot lógico cuyo restart_lsn se queda atrás prolonga la vida útil del WAL; un consumidor desconectado puede convertir el crecimiento normal en un riesgo ilimitado. Registre el nombre del slot, la base de datos, el plugin, el consumidor y el propietario antes de establecer la política.
2. Clasificar los slots
Utilice las clases crítica, recuperable y temporal. Los slots críticos requieren acción humana y mayores presupuestos de capacidad. Los slots recuperables pueden expirar tras advertencias. Los slots temporales reciben un tiempo de expiración al momento de su creación. Mantenga la lista protegida fuera de la configuración enviada por el consumidor para que una aplicación no pueda marcar un slot crítico como desechable.
3. Usar el tiempo de espera por inactividad correctamente
El idle_replication_slot_timeout de PostgreSQL 18 invalida un slot que no ha sido utilizado por una conexión de replicación durante más tiempo que la duración configurada; el valor cero lo deshabilita. La invalidación se activa en el checkpoint, por lo que el tiempo real puede superar el umbral. El ajuste es a nivel de servidor y no reemplaza la clasificación comercial por slot.
4. Construir observabilidad y alertas
Consulte pg_replication_slots periódicamente para obtener el tipo de slot, base de datos, restart_lsn, estado activo, motivo de invalidación y estado de failover o sincronización. Calcule los bytes de WAL retenidos y la antigüedad del slot más viejo. Genere alertas sobre la tasa de crecimiento, el espacio libre en disco, la duración de inactividad y la invalidación inminente, incluyendo el propietario y el runbook de recuperación.
5. Manejar checkpoints y condiciones de carrera
La evaluación del tiempo de espera se ejecuta durante un checkpoint, por lo que el umbral configurado no es un límite exacto. Un consumidor puede reconectarse cerca del umbral; registre la hora de último uso, la hora del checkpoint y el motivo final de invalidación. Antes de cambiar la política o eliminar un slot, verifique si hay creaciones con el mismo nombre, sincronización de standby o una recuperación de suscripción en curso.
6. Diseñar la recuperación
Tras la invalidación, un consumidor no puede asumir que su antiguo límite sigue disponible. Si la pérdida durante el tiempo de inactividad es aceptable, cree un nuevo slot y tome una instantánea inicial. Si la pérdida es inaceptable, restaure desde el backup o el WAL retenido y reconstruya la suscripción. Registre el slot anterior, el límite de datos, la hora de la instantánea y la evidencia de validación.
7. Vincular capacidad y control de cambios
Cuando el directorio de WAL se acerque a su límite, pause los backfills de baja prioridad, limite el trabajo por lotes que genere WAL y proteja la disponibilidad del primario; no elimine un slot desconocido. Despliegue los cambios de tiempo de espera por etapas, observe el crecimiento de WAL, los checkpoints, el retraso de replicación y los errores del consumidor, y luego ajuste la política.
Ejemplo de una respuesta sólida
Mantendría un catálogo de slots con sus propietarios y clasificaría los slots como críticos, recuperables o temporales. Los slots recuperables y temporales reciben tiempos de espera por inactividad; los slots críticos solo generan alertas. Dado que la invalidación ocurre durante un checkpoint, el monitoreo registra la hora del checkpoint y el motivo real. Los informes diarios calculan el WAL retenido, la duración de inactividad y el riesgo de disco; los umbrales pausan los backfills y notifican a los propietarios. Tras la invalidación, la ruta de recuperación elige entre una nueva instantánea, restauración de backup o reconstrucción aprobada según el contrato de pérdida de datos, con cada acción auditada.
Errores comunes
- Asumir que un slot se invalida exactamente cuando expira el tiempo de espera e ignorar los checkpoints.
- Aplicar un tiempo de espera corto a todos los slots y eliminar slots de recuperación ante desastres o auditoría.
- Monitorear solo
activeen lugar de calcular el WAL retenido a partir derestart_lsn. - Reconectar un consumidor sin decidir si se perdieron datos o límites de instantáneas.
- Eliminar un slot desconocido durante un incidente de disco y romper una ruta de replicación activa.
- No tener un propietario, lista protegida o runbook de recuperación ejecutable.
Preguntas de seguimiento y respuestas
¿Cuándo surte efecto idle_replication_slot_timeout?
Después de que un slot no haya sido utilizado por una conexión de replicación durante más tiempo que el configurado, la invalidación se activa durante un checkpoint posterior, por lo que puede retrasarse.
¿Deberían expirar automáticamente también los slots físicos?
Eso depende del contrato de recuperación ante desastres. Un slot físico puede ser requerido por un standby; confirme la existencia de otro mecanismo de protección antes de permitir la invalidación automática.
¿Cómo se calcula el WAL retenido por un slot?
Compare la posición actual de WAL con el restart_lsn del slot, luego agregue la posición más antigua, la tasa de crecimiento y el espacio libre en disco por slot. active por sí solo no describe el riesgo de espacio.
¿Puede un consumidor reanudarse tras volver a conectarse?
Solo si el WAL requerido aún existe y el slot sigue siendo válido. Tras una invalidación o eliminación de WAL, se requiere una nueva instantánea, restauración de backup o una brecha de datos explícita.
¿Cómo previene fugas de slots temporales de backfill?
Registre la expiración y el propietario en el momento de la creación, genere alertas por separado, pase a un estado de confirmación antes de la invalidación y verifique que el reciclaje de WAL se recupere posteriormente.