Un despliegue gradual no reemplaza todo el sistema al mismo tiempo. Código antiguo y nuevo pueden compartir base; los workers pueden actualizarse después; un rollback de aplicación no deshace transformaciones de datos. Trata los cambios de esquema como una transición compatible entre versiones, no como una sentencia DDL añadida al deploy.
| Cambio | Secuencia más segura | Riesgo que revisar |
|---|---|---|
| Renombrar columna | Añadir, soportar ambos, rellenar, cambiar y retirar después | Jobs o informes antiguos siguen consultando el nombre original |
| Cambiar significado | Añadir campo versionado y transformar con validación | Unidades, nulos o redondeo distintos |
| Exigir un nuevo valor | Nullable, rellenar, validar y luego restringir | Escaneo grande o lock al añadir constraint |
| Eliminar tabla | Parar escrituras, observar lecturas, archivar y borrar al final | Procesos no documentados aún la usan |
Documenta qué versiones admiten cada fase, incluyendo jobs agendados, herramientas de informes y scripts administrativos. Revertir código solo es seguro si el esquema expandido sigue siendo compatible y los datos no cruzaron un límite irreversible.
Los backfills deben ser idempotentes, reanudables y limitados por filas o duración. Usa un cursor estable, checkpoints e indicadores de progreso, errores y pendientes. Reduce el ritmo si la latencia o el retraso de réplicas excede el umbral. Compara recuentos y muestras transformadas antes de cambiar las lecturas.
En tablas grandes, evita una transacción gigante que retenga locks y genere WAL excesivo. Mide lotes con volúmenes parecidos a producción. Mantén coherentes las escrituras viejas y nuevas durante el solapamiento y usa consultas de conciliación para detectar diferencias.
“Online” no significa sin locks. El nivel depende del motor y del subcomando; incluso un cambio de metadatos puede esperar transacciones largas o bloquear brevemente. Consulta la documentación de la versión, configura timeouts, observa las colas de locks y separa cambios arriesgados.
Separa el cambio de esquema del backfill si tienen duraciones y fallos diferentes. Define si la recuperación es reintentar, avanzar con una corrección o restaurar. Las transformaciones de producción suelen ser más seguras con roll-forward. Un backup solo sirve si el tiempo y la pérdida de datos cumplen el objetivo; prueba la restauración.
Ejecuta migraciones una sola vez en una etapa controlada, no desde cada réplica. Serializa la ejecución, registra versión y duración y alerta ante fallos. No edites migraciones ya aplicadas; añade otra correctiva. Revisa el SQL generado y prueba la actualización desde el esquema actual y desde una base vacía.
Las migraciones seguras consideran versiones coexistentes, tráfico activo y cambios de datos potencialmente irreversibles. Expande con compatibilidad, rellena por lotes, verifica antes del cambio y contrae cuando ya no queden consumidores antiguos. Los pasos pequeños y predecibles superan un deploy que mezcla esquema, transformación y limpieza.