Saltar a contenido

Migración de Bases de Datos

Migrar una base de datos asusta porque la versión ingenua de la migración es mala: parar la aplicación, exportar todo, importar todo, cruzar los dedos. En una base de 500 GB eso es una noche entera de indisponibilidad y ningún camino de vuelta.

La migración que ejecuta InteSys es otra: la base nueva se llena y se mantiene sincronizada mientras la antigua sigue atendiendo producción. La parada real ocurre solo al cambiar la dirección, y dura segundos.

Migración con carga inicial, replicación de cambios, cutover y flujo inverso armado para rollback

El flujo inverso sigue armado después del cutover: es lo que hace posible el rollback.

De dónde suelen venir los clientes

Origen Complicación típica
Servidor propio / colocation Versión antigua, sin réplica y con copias nunca probadas
Proveedor extranjero Mala latencia para el usuario brasileño y transferencia internacional de datos personales
Base gestionada de nube pública Costo creciente, poco control de parámetros y egreso caro a la salida
VM de aplicación Base conviviendo con la aplicación en el mismo host, disputando CPU e I/O

Salir de un proveedor extranjero tiene, además de la ganancia de latencia, un efecto de cumplimiento: el dato pasa a estar bajo soberanía brasileña, sin transferencia internacional que documentar.

1. Relevamiento

Antes de mover un solo byte:

  • Inventario — bases, esquemas, tamaño por tabla, motores de almacenamiento, extensiones y juegos de caracteres.
  • Versiones — versión de origen y de destino. Un salto de versión mayor es migración y actualización: son dos riesgos, y a veces conviene separarlos.
  • Dependencias ocultas — triggers, procedimientos almacenados, jobs de cron, usuarios con privilegios especiales, replicación ya existente.
  • Perfil de carga — picos de escritura y consultas más pesadas, para dimensionar el destino.
  • Requisito de ventana — cuánta indisponibilidad tolera el negocio. Ese número decide el método.

2. Elección del método

Método Downtime Cuándo usarlo
Dump y restore Horas, proporcional al tamaño Bases pequeñas o entornos que pueden parar de madrugada
Copia física + replicación Minutos Misma versión mayor y mismo motor; la réplica se levanta de la copia y alcanza al primario
Replicación lógica / CDC Segundos El estándar para producción crítica; tolera cambio de versión y ajuste de esquema
Blue/green de aplicación Cero percibido Cuando la aplicación sabe escribir en ambos lados durante la transición

En la práctica, casi toda migración de producción usa replicación lógica o CDC: logical replication en PostgreSQL, replicación por binlog con GTID en MySQL, o una herramienta de captura de cambios cuando origen y destino son heterogéneos.

3. Carga inicial

El destino se llena con una copia consistente del origen, marcada con la posición exacta del log de transacciones (GTID en MySQL, LSN en PostgreSQL). Esa marca es lo que permite retomar la replicación sin hueco y sin duplicados.

Durante la carga inicial, la base de origen sigue atendiendo producción normalmente.

Índices después de los datos

En bases grandes, cargar datos con los índices ya creados es varias veces más lento. El orden es: esquema sin índices secundarios → datos → índices → constraints → estadísticas.

4. Sincronización continua

Terminada la carga, el destino pasa a consumir el flujo de cambios del origen y el lag baja a segundos. Ese estado puede durar horas o días — y es exactamente lo que da libertad para elegir el horario del cutover.

En esa ventana hacemos la validación en frío:

  • conteo de filas por tabla en ambos lados;
  • checksum de muestras de las tablas críticas;
  • comparación de secuencias, AUTO_INCREMENT y objetos de esquema;
  • ejecución de las consultas más pesadas de la aplicación contra el destino, comparando plan de ejecución y tiempo.

5. Cutover

El único momento de parada. Procedimiento típico, de dos a cinco minutos en total y segundos de indisponibilidad real:

  1. Congelar la escritura — la aplicación entra en modo solo lectura o el pool se pausa.
  2. Drenar el lag — esperar a que el destino llegue a lag cero. Es la etapa que define la duración.
  3. Verificar — última comparación de conteos en las tablas de mayor escritura.
  4. Cambiar la dirección — DNS, connection string o, preferentemente, el proxy (ProxySQL, PgBouncer) pasa a apuntar al clúster nuevo.
  5. Liberar la escritura — la aplicación vuelve a la normalidad, ya en la base nueva.
  6. Armar el retorno — se enciende la replicación inversa (destino → origen).

El rollback tiene fecha de vencimiento

El camino de vuelta solo existe mientras la replicación inversa esté activa y el origen, intacto. Fijamos con el cliente una ventana de rollback — normalmente de 24 a 72 horas — y solo después de ella se apaga el origen.

6. Estabilización

En las primeras horas y días tras el cutover:

  • monitoreo reforzado de latencia, errores de conexión y consultas lentas;
  • comparación de rendimiento con la línea base recogida antes de la migración;
  • ajuste de parámetros con carga real, no sintética;
  • primera copia completa en el destino, con restauración probada;
  • primera prueba de failover ya en el entorno nuevo.

Riesgos conocidos y cómo los tratamos

Riesgo Tratamiento
Diferencia de collation entre origen y destino Comparada en el relevamiento; ordenación y claves verificadas antes del cutover
Secuencia / AUTO_INCREMENT desalineada Reposicionada en el cutover, antes de liberar la escritura
Tabla sin clave primaria Bloquea CDC en varias herramientas; se trata en el relevamiento, no en el cambio
Objeto no replicado (trigger, job, usuario) Migrado explícitamente por checklist, no por el flujo de datos
Aplicación con dirección fija en el código Identificada antes; el proxy elimina la dependencia

Páginas Relacionadas