Ventanas de Mantenimiento
Las ventanas de mantenimiento son un contrato con los usuarios y los ingenieros de guardia. Programe trabajos de Postgres de alto impacto cuando el radio de explosión se comprenda, se comunique y sea reversible.
Receta
Tarjeta de receta de referencia rápida, lista para copiar y pegar.
## Plantilla de Notificación de Mantenimiento
Ventana: 2026-07-12 02:00-04:00 UTC (bajo tráfico)
Impacto: Picos de latencia de escritura de hasta 30 segundos; sin interrupción de lectura planificada
Cambios: Reconstrucción de índice V2050, ensayo de conmutación de Patroni
Reversión: Revertir migración V2050; DNS sin cambios
Página de estado: https://status.example.com/incidents/42-- Pre-ventana: confirmar que no hay transacciones largas inesperadas
SELECT count(*) FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND now() - xact_start > interval '10 minutes';Cuándo usar esto: DDL de alto riesgo, simulacros de conmutación por error, redimensionamiento de almacenamiento que requiere reinicio o corte de pg_upgrade.
Ejemplo de Trabajo
El equipo programa VALIDATE CONSTRAINT en la tabla payments de 80 millones de filas durante la ventana del domingo a las 03:00 UTC.
# T-7 días: correo electrónico al cliente + banner en la aplicación
# T-1 día: congelar otros cambios de alto riesgo
# T-0: puente de guardia abierto, escriba asignadoSET lock_timeout = '3s';
SET statement_timeout = '2h';
ALTER TABLE payments VALIDATE CONSTRAINT payments_amount_positive;# Post-ventana: verificar la tasa de error y el retraso de replicación
psql -c "SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) FROM pg_stat_replication;"Lo que esto demuestra:
- Comunique el impacto visible para el usuario, no solo "mantenimiento de la base de datos".
- Congelar cambios competidores para evitar tormentas de bloqueos.
- Establecer tiempos de espera de sesión antes del DDL en la ventana.
- Verificar que las réplicas se hayan puesto al día antes de declarar el éxito.
Análisis Profundo
Dimensionamiento de la Ventana
| Tipo de trabajo | Sugerencia de dimensionamiento |
|---|---|
CREATE INDEX CONCURRENTLY | 2-3x duración en staging |
| Validar restricción | Tiempo de escaneo de tabla + búfer de reintento de bloqueo |
| Simulacro de conmutación por error | Tormenta de arranque en frío de la aplicación + 15 min de observación |
pg_upgrade | Mínimo de la documentación del proveedor + 100% de búfer la primera vez |
Elija ventanas de los paneles de tráfico, no solo por conveniencia de zona horaria local.
Lenguaje de Impacto Honesto
| Diga esto | No diga esto |
|---|---|
| "El checkout puede fallar hasta por 60 segundos" | "Mantenimiento breve" |
| "Modo de solo lectura para la API de informes" | "No se espera impacto" |
| "La conmutación por error puede descartar transacciones en curso" | "Actualización sin interrupciones" |
Política de Congelación
Durante la ventana:
- No se desplegarán aplicaciones no relacionadas.
- No se realizarán experimentos con la política de escalado automático.
- No se rotarán certificados a menos que se incluyan en la misma guía de ejecución.
-- Opcional: revocar CREATE de los roles de la aplicación durante la ventana (casos extremos)
REVOKE CREATE ON SCHEMA public FROM app_migrator;Trampas
- Apilamiento de múltiples DDL de alto riesgo: Un fallo a mitad de ventana oscurece la causa raíz. Solución: Un objetivo principal por ventana.
- Deriva silenciosa de réplicas: El DDL pesado en el primario aumenta el retraso; las aplicaciones que leen réplicas ven datos obsoletos. Solución: Monitorear el retraso en bytes; retrasar la conmutación del tráfico de lectura.
- Tiempo de reversión faltante: La ventana termina antes de que se complete la verificación. Solución: Reservar 30 minutos de búfer; extender la página de estado si es necesario.
- Base de usuarios global: "Bajo tráfico" localmente es pico en otros lugares. Solución: Usar mapas de calor de tráfico UTC.
- Pools de conexión olvidados: Las aplicaciones mantienen conexiones a través de reinicios breves. Solución: Drenar PgBouncer previamente; coordinar la vida útil máxima.
Alternativas
| Alternativa | Usar cuándo | No usar cuándo |
|---|---|---|
| DDL en línea solamente | Cultura madura de expansión/contracción | La corrección de emergencia necesita reescritura inmediata |
| Base de datos Blue/green | Presupuesto de corte sin tiempo de inactividad | Equipo pequeño sin automatización |
| Ventana de solo lectura | Proteger datos durante operación arriesgada | Se requieren escrituras para ingresos |
| Cambio inmediato | Mitigación de Sev-1 | Mejora planificada del esquema |
Preguntas Frecuentes
¿Con qué frecuencia debemos ejecutar ventanas de mantenimiento?
Mensualmente para lotes de riesgo medio; ad hoc para alto riesgo; trimestralmente para simulacros de DR.
¿Necesitamos una página de estado para una base de datos solo interna?
Sí, si alguna API orientada al cliente depende de la base de datos.
¿Podemos ejecutar la indexación CONCURRENTLY fuera de una ventana?
A menudo sí para nivel bajo; aún así notificar al guardia y monitorear el retraso.
¿Quién aprueba la extensión de la ventana?
Comandante de Incidentes o propietario del cambio más oficial de producto.
¿Qué pasa si la migración excede la ventana?
Comunicar la nueva ETA; revertir si se supera el SLA de reversión.
¿Deberían las aplicaciones reducir su escala antes del mantenimiento?
A veces, aumentar la escala de los trabajadores de conexión después del reinicio; planificar según la guía de ejecución.
¿Cómo elegimos la zona horaria?
El TPS de escritura global más bajo de las métricas, no la ubicación de la oficina.
¿Son los simulacros de conmutación por error mantenimiento?
Sí. Trátelos con la misma rigor de comunicación y reversión.
¿Qué métricas definen el éxito post-ventana?
Tasa de error, latencia p95, retraso de bytes de replicación, profundidad de la cola de trabajos fallidos.
¿Qué debo leer a continuación?
Ver SLO de tiempo de actividad para almacenes de datos para la alineación del presupuesto de errores.
Relacionado
- Conceptos básicos de gestión de cambios - niveles de riesgo
- SLO de tiempo de actividad para almacenes de datos - presupuestos de errores
- Reversión para migraciones fallidas - rutas inversas
- DDL sin tiempo de inactividad - patrones en línea
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+.