Prácticas recomendadas para la migración de bases de datos

Migrar una base de datos es más complejo que trasladar una máquina virtual porque las bases de datos tienen estado (stateful) y suelen mantener conexiones activas las 24 horas del día, los 7 días de la semana. Un enfoque ingenuo de copia y restauración requiere horas de inactividad, algo inaceptable en los sistemas de producción. La migración de bases de datos siguiendo las prácticas recomendadas utiliza la replicación continua de datos para mantener sincronizados el origen y el destino mientras se valida el destino, y después realiza un cambio breve y planificado cuando el tráfico se redirige a la nueva base de datos de Azure.

Azure Database Migration Service (DMS) es un servicio totalmente administrado que coordina migraciones en línea (con un tiempo de inactividad casi nulo) y sin conexión (basadas en tiempo de inactividad) desde motores locales populares hacia servicios de bases de datos administrados de Azure. DMS admite orígenes como SQL Server, MySQL, PostgreSQL, MongoDB y Oracle, y destinos como Azure SQL Database, Azure SQL Managed Instance, Azure Database for MySQL y Azure Cosmos DB. El servicio se integra con Data Migration Assistant (DMA) para realizar comprobaciones de compatibilidad previas a la migración.

Antes de migrar SQL Server, ejecute Data Migration Assistant (DMA) en la base de datos de origen. DMA identifica: problemas de compatibilidad (características utilizadas en la base de datos que no son compatibles con el destino Azure SQL), cambios importantes, características en desuso y recomendaciones de rendimiento. Genera un informe HTML detallado que prioriza los problemas según su gravedad para que el equipo pueda corregirlos antes de que comience la ventana de migración.

La migración sin conexión deja la base de datos de origen fuera de servicio durante toda la migración, lo que resulta aceptable para bases de datos pequeñas o sistemas no críticos en los que es posible establecer una ventana de mantenimiento. La migración en línea utiliza la captura de datos modificados (CDC) o el envío de registros de transacciones para replicar continuamente los cambios mientras se carga la nueva base de datos, y reduce el tiempo de inactividad al paso final del cambio. Se recomienda la migración en línea para bases de datos de más de 1 GB o con SLA que exijan menos de 1 hora de inactividad.

Un proyecto de migración de DMS especifica la conexión de origen (nombre del servidor, autenticación y nombres de las bases de datos), la conexión de destino (cadena de conexión de Azure SQL) y el modo de migración (en línea o sin conexión). También se seleccionan las bases de datos y tablas que se migrarán. DMS valida la conectividad antes de comenzar. El proyecto de migración permanece en el portal de Azure, por lo que puede supervisar el progreso, volver a intentar las tablas con errores y consultar registros de actividad detallados.

Migre siempre el esquema antes que los datos. Use DMA o SQL Server Management Studio (SSMS) para crear scripts e implementar tablas, vistas, procedimientos almacenados, funciones e índices en la base de datos Azure SQL de destino. Compruebe que todos los objetos del esquema existen y se compilan sin errores antes de permitir que DMS inicie la transferencia de datos. Los errores de esquema detectados durante la migración pueden dañar la ejecución de la migración y obligarle a reiniciarla desde cero.

DMS realiza una carga completa de datos leyendo la tabla de la base de datos de origen por tabla y escribiendo las filas en el destino de Azure SQL mediante una inserción masiva. Durante la carga completa, el servicio gestiona las tablas grandes dividiéndolas en lotes. Los índices del destino se deshabilitan durante la carga para maximizar el rendimiento y, posteriormente, se vuelven a generar. Para bases de datos muy grandes (a escala de TB), considere usar Azure Data Factory o exportaciones bacpac para precargar los datos y reducir el tiempo de ejecución de DMS.

En las migraciones en línea, DMS habilita SQL Server Change Data Capture (CDC) en el origen para capturar las operaciones INSERT, UPDATE y DELETE que se producen mientras la carga completa está en curso. Una vez que finaliza la carga completa, DMS reproduce estos cambios en el destino, reduciendo gradualmente la diferencia. Cuando la latencia desciende a casi cero, la base de datos está lista para el cambio. CDC requiere que SQL Server Agent esté en ejecución y que la base de datos de origen se encuentre en modo de recuperación completa.

Cuando el retraso de CDC sea mínimo, inicie el cambio en el portal de DMS. DMS deja de aceptar nuevos eventos de CDC, aplica los cambios restantes y marca la migración como completada. En este momento, redirija las cadenas de conexión de la aplicación al punto de conexión de Azure SQL. Ejecute consultas de validación de datos que comparen los recuentos de filas y los agregados de sumas de comprobación entre el origen y el destino para las tablas críticas. Mantenga la base de datos de origen en modo de solo lectura durante 24–48 horas después del cambio por si fuera necesario revertirlo.

Después de la migración, Azure SQL Database puede funcionar de manera diferente a SQL Server local debido a las diferencias en las cachés de planes de consulta, las estadísticas y el hardware. Ejecute Database Experimentation Assistant (DEA) para reproducir los seguimientos de carga de trabajo en el destino de Azure y comparar los planes de ejecución. Habilite Automatic Tuning en Azure SQL para que el servicio cree o elimine índices automáticamente y fuerce planes de consulta sin regresiones, mejorando el rendimiento con el tiempo sin intervención manual.

DMS también migra motores de código abierto: de MySQL a Azure Database for MySQL mediante el patrón de mysqldump + replicación de binlog, y de PostgreSQL a Azure Database for PostgreSQL mediante ranuras de replicación lógica. Para las migraciones de MongoDB a Cosmos DB, use la API de Cosmos DB para MongoDB y la canalización nativa de mongodump / mongorestore, o el conector de MongoDB de Azure Data Factory para CDC incremental. Pruebe siempre la migración en una copia que no sea de producción antes de ejecutarla con datos activos.

Compruebe sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que Azure Database Migration Service coordina las migraciones de bases de datos en línea y sin conexión, que la evaluación previa a la migración con DMA detecta problemas de compatibilidad antes de la ventana de migración y que la captura de datos modificados permite realizar el cambio en bases de datos de producción con un tiempo de inactividad casi nulo. A continuación, cambiaremos el enfoque hacia la optimización de los costes de Azure.