Mantener un cambio de base de datos compatible entre lanzamientos

Mapea cada lector y escritor

Trabaja en un esquema aislado con datos representativos saneados. Necesitas las versiones actual y siguiente de la aplicación, conocimiento de tu framework de migración, una estrategia de copia de seguridad revisada y visibilidad sobre transacciones largas. Incluye workers, tareas programadas, informes e instancias antiguas de la aplicación. Una API puede actualizarse rápidamente mientras un worker de larga duración sigue escribiendo en la columna antigua.

Nuestro servicio de informes ilustrativo almacena una etiqueta de exportación en label y quiere display_name. Este es un ejemplo de diseño, no SQL universal ejecutable. Confirma tu versión exacta de PostgreSQL y tu framework antes de elegir la sintaxis de migración o la configuración de bloqueos.

Amplía sin retirar la representación antigua

Introduce primero el nuevo campo anulable. Despliega una versión de compatibilidad que escriba ambos valores en una transacción y lea con el fallback requerido mientras los datos estén incompletos. Define qué ocurre cuando un cliente edita un registro durante el relleno. Un reintento no debe crear una segunda exportación lógica.

PostgreSQL ALTER TABLE las operaciones adquieren bloqueos, con el nivel dependiendo del subcomando. Un cambio pequeño puede esperar detrás de una transacción larga y luego obstruir otro trabajo. Revisa la operación concreta y observa las esperas durante el ensayo; aditivo no significa libre de bloqueos.

Referencia técnica: PostgreSQL ALTER TABLE · Bloqueo explícito de PostgreSQL.

Haz visible el límite de compatibilidad

Un fallback para valores faltantes no puede detectar un nuevo valor no nulo pero obsoleto. Antes de cambiar los lectores, retira los escritores solo antiguos y verifica la consistencia. Revertir a código solo antiguo tras el cambio de lectores podría recrear la divergencia. Mantén la versión de compatibilidad como el artefacto de recuperación revisado.

Rellena en trabajos acotados y reiniciables

Encuentra filas que necesiten copiarse sin sobrescribir una edición más reciente del cliente. Usa un orden estable, una condición de actualización segura frente a concurrencia y lotes elegidos para la carga de trabajo. Persiste el progreso para que un fallo pueda reanudarse en un límite conocido. Monitoriza el volumen de escritura, las esperas de bloqueo, la latencia de solicitudes y la replicación donde exista.

Ningún tamaño de lote es seguro para toda aplicación. En el ensayo compara un lote pequeño con tráfico ordinario, luego elige una regla de pausa o parada. Si un lote falla, inspecciona qué se confirmó antes de reintentar. Un bucle de reintento ilimitado puede convertir una discrepancia recuperable en presión sostenida sobre la base de datos.

Comprueba la semántica, no solo las filas pobladas

Verifica valores faltantes, etiquetas representativas, registros nuevos y actualizaciones de exportaciones existentes. Contar filas no nulas puede parecer correcto mientras los valores se copiaron de la fuente equivocada. Prueba el artefacto de compatibilidad contra datos parcialmente poblados y ejercita un worker iniciado antes del despliegue.

Registra la versión del esquema, la revisión de migración, los criterios de finalización y las combinaciones incompatibles. Inspecciona el uso del fallback y la consistencia antes de eliminar cualquiera de los dos. Si las comprobaciones fallan, detén el relleno o la promoción, preserva la evidencia y elige un artefacto compatible o una reparación hacia adelante revisada. No afirmes que una reversión de la aplicación reconstruye datos confirmados.

Retira el campo antiguo en otra versión revisada

Elimina las lecturas y escrituras antiguas después de que el relleno y el periodo de observación cumplan tus criterios. Revisa también las tareas poco frecuentes además de las rutas interactivas. Eliminar el campo antiguo pertenece a un cambio posterior con su propia decisión de recuperación, para que un problema de versión no te obligue a combinar la reparación de código con la reconstrucción de datos.

Si aparecen datos incorrectos tras la retirada, detén más daños y usa el plan de recuperación o una reparación aprobada. No apliques una migración descendente destructiva solo porque el tooling exponga un botón de reversión. Adjunta la matriz a la registro de publicación y ensaya recuperación de datos antes de cambiar producción. El resultado útil es un límite de compatibilidad explícito, no una garantía de cero tiempo de inactividad.