Cambios en la base de datos sin interrupción: expandir y contraer

Objetivo

Modificar la estructura de la base de datos mientras el servicio sigue en funcionamiento, y hacer que cada estado intermedio funcione tanto con la versión antigua del código como con la nueva.

Requisitos previos

Migraciones versionadas junto con el código; un proceso de despliegue capaz de entregar código y migraciones por separado; conocimiento de qué sentencias toman bloqueos fuertes. La documentación de PostgreSQL sobre ALTER TABLE indica el nivel de bloqueo de cada forma —la mayoría toma ACCESS EXCLUSIVE, que bloquea cualquier otro uso de la tabla— y señala que ADD COLUMN con un DEFAULT no volátil guarda el valor en los metadatos en lugar de reescribir la tabla; que una restricción CHECK o NOT NULL lee la tabla, pero no la reescribe; y que una restricción creada con NOT VALID solo se comprueba mediante VALIDATE CONSTRAINT, que toma únicamente un bloqueo SHARE UPDATE EXCLUSIVE. CREATE INDEX CONCURRENTLY construye un índice sin bloquear las inserciones, modificaciones ni eliminaciones sobre la tabla. El parámetro lock_timeout aborta una sentencia que espera un bloqueo durante más tiempo del indicado.

Pasos

1. Expandir: crear la columna, tabla o índice nuevos de modo que sea rápido y no bloquee (columna anulable o valor por defecto constante, CREATE INDEX CONCURRENTLY, restricciones NOT VALID). El código antiguo ignora lo nuevo.
2. Ejecutar cada migración con lock_timeout fijado (unos pocos segundos) y reintentar en caso de aborto, en lugar de dejar que se acumule una cola de solicitudes bloqueadas detrás de un bloqueo en espera.
3. Desplegar el código que escribe ambas representaciones y sigue leyendo la antigua.
4. Rellenar las filas existentes en lotes pequeños con pausas entre ellos; observar los tiempos de espera de bloqueo y el retraso de replicación. Después, ejecutar VALIDATE CONSTRAINT.
5. Desplegar el código que lee la representación nueva y la compara durante un tiempo con la antigua (registrando las discrepancias).
6. Dejar de escribir la representación antigua; desplegar.
7. Contraer: eliminar la columna o tabla antigua en una versión posterior, en cuanto ya no haga falta poder revertir a la versión de código anterior.

Resultado esperado

Cada despliegue es reversible por sí mismo; ninguna migración mantiene un bloqueo el tiempo suficiente como para hacerse notar.

Límites y base de verificación

El patrón multiplica los pasos y dura días en lugar de minutos. Una columna se renombra como «crear, copiar, eliminar», no mediante RENAME, cuando deben convivir ambas versiones de código. El comportamiento de los bloqueos sigue la documentación citada; no se afirman tiempos. Si lock_timeout junto con el reintento reduce el número de incidentes es algo que el wiki recoge como hipótesis, no como hallazgo.

Reintentar con la vista puesta en quien bloquea

Un aborto por lock_timeout es información, no una invitación a un bucle infinito: la propia solicitud de bloqueo en espera ya bloquea a todos los accesos nuevos que llegan detrás, y cada reintento genera una nueva pausa breve. Antes del siguiente intento, pg_blocking_pids(pg_backend_pid()) junto con pg_stat_activity (state, xact_start, query) muestra quién retiene el bloqueo. Una consulta larga o una sesión colgada en idle in transaction no termina por sí sola; aquí esperar, abortar o usar pg_terminate_backend es una decisión consciente, e idle_in_transaction_session_timeout previene de antemano el tipo de caso más frecuente. El bucle necesita una pausa entre intentos y un límite superior. lock_timeout solo limita la espera por el bloqueo; la duración de VALIDATE CONSTRAINT y de los lotes de relleno la limita statement_timeout.