Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Nota:
Este artículo contiene referencias al término esclavo, un término que Microsoft ya no usa. Cuando se elimine el término del software, se eliminará también de este artículo.
Es posible migrar sus servicios en la nube o local de un servidor MySQL a Azure Database for MySQL: servidor flexible mediante Azure Database Migration Service (DMS), un servicio totalmente administrado diseñado para habilitar migraciones eficaces desde varios orígenes de base de datos a plataformas de datos de Azure. En este tutorial, se realiza una migración en línea de una base de datos de ejemplo desde un servidor MySQL local a una instancia de Azure Database for MySQL: Servidor Flexible (en ambos se ejecuta la versión 5.7) mediante una actividad de migración Replicar cambios de DMS.
La ejecución de una migración de replicación de cambios, con nuestro escenario sin conexión con "Habilitar la coherencia transaccional" permite a las empresas migrar sus bases de datos a Azure mientras las bases de datos permanecen operativas. Es decir, las migraciones se pueden completar con un tiempo de inactividad mínimo para las aplicaciones críticas, lo que limita el impacto en la disponibilidad del nivel de servicio y las molestias a sus clientes finales.
En este tutorial, aprenderá a:
- Cree un proyecto de migración de replicación de cambios de MySQL en DMS.
- Ejecute la migración Replicar cambios.
- Supervisar la migración
- Aplicar los pasos posteriores a la migración.
Requisitos previos
Para completar este tutorial, necesita:
Utilice la herramienta de línea de comandos MySQL de su elección para determinar si log_bin está habilitado en el servidor de origen. El Binlog no siempre está activado por defecto, así que verifique que está activado antes de iniciar la migración. Para determinar si log_bin se ha habilitado en el servidor de origen, ejecute el siguiente comando: SHOW VARIABLES LIKE 'log_bin'.
Asegúrese de que el usuario tenga el permiso "REPLICATION_APPLIER" o "BINLOG_ADMIN" en el servidor de destino para aplicar el archivo de registro binario.
Asegúrese de que el usuario tenga el permiso "REPLICATION SLAVE" en el servidor de destino.
Asegúrese de que el usuario tiene los permisos "REPLICATION CLIENT" y "REPLICATION SLAVE" en el servidor de origen para leer y aplicar el archivo de registro binario.
Ejecute un escenario de migración sin conexión con "Habilitar la coherencia transaccional" para obtener el archivo de registro bin y la posición.
Si se trata de una migración para replicar cambios, configure el parámetro binlog_expire_logs_seconds en el servidor de origen para garantizar que los archivos binlog no se purguen antes de que la réplica confirme los cambios. Para empezar, le recomendamos al menos dos días. Después que la fase de transición se efectúe correctamente, se puede restablecer el valor.
Limitaciones
A medida que se prepare para la migración, asegúrese de tener en cuenta las siguientes limitaciones.
Al realizar una migración de cambios de replicación, el nombre de la base de datos en el servidor de destino debe ser el mismo que el nombre en el servidor de origen.
La compatibilidad se limita al formato binlog ROW.
La replicación de cambios de DDL solo se admite cuando ha seleccionado la opción replicar instrucciones de administración y definición de datos para objetos seleccionados en la interfaz de usuario de DMS. La característica de replicación admite la replicación de instrucciones de administración y definición de datos que se producen después de la carga inicial y se registran en el registro binario en el destino.
No se admite el cambio de nombre de bases de datos ni tablas al replicar cambios.
Creación de un proyecto de migración de replicación de cambios
Para crear un proyecto de migración Replicar cambios, realice los pasos siguientes.
En Azure Portal, seleccione Todos los servicios, busque Azure Database Migration Service y, luego, elija Azure Database Migration Services.
En los resultados de la búsqueda, seleccione la instancia de DMS que creó para ejecutar la migración preliminar sin conexión y, a continuación, seleccione + Nuevo proyecto de migración.
En la página Nuevo proyecto de migración, especifique un nombre para el proyecto. En el cuadro de selección Tipo de servidor de origen, seleccione MySQL y en el cuadro selección Tipo de servidor de destino, seleccione Azure Database for MySQL: Servidor flexible; en el cuadro de selección Tipo de actividad de migración, seleccione Replicar cambios y, después, seleccione Crear y ejecutar la actividad.
Configuración del proyecto de migración
Para configurar el proyecto de migración de DMS, los pasos que se indican.
En la pantalla Seleccionar origen, escriba el nombre del servidor de origen, el puerto del servidor, el nombre de usuario y la contraseña en el servidor de origen.
Seleccione Siguiente: seleccionar destino>> y, a continuación, en la pantalla Seleccionar destino, localice el servidor en función de la suscripción, la ubicación y el grupo de recursos. El nombre de usuario se rellena automáticamente y, a continuación, proporcione la contraseña del servidor flexible de destino.
Seleccione Siguiente: seleccione binlog>> y, a continuación, en la pantalla Seleccionar binlog, escriba el nombre del archivo binlog y la posición de binlog como se capturó en la ejecución anterior del escenario de migración sin conexión.
Seleccione Siguiente: Seleccionar bases de datos>> y, a continuación, en la pestaña Seleccionar bases de datos, seleccione los objetos de servidor que quiera migrar.
Seleccione Siguiente : Seleccionar tablas>> para ir a la pestaña Seleccionar tablas. Seleccione todas las tablas que se van a migrar.
Después de configurar para la migración del esquema, seleccione Revisar e iniciar la migración.
Solo tiene que ir a la pestaña Configurar las opciones de migración si intenta solucionar errores con las migraciones.
En la pantalla Resumen, en el cuadro de texto Nombre de actividad, especifique un nombre para la actividad de migración y consulte el resumen para asegurarse de que los detalles de origen y de destino coincidan con los que especificó anteriormente.
Seleccione Iniciar migración.
Aparecerá la ventana de actividad de migración. El estado de la actividad es Inicializando. El estado cambia a En ejecución cuando se inician las migraciones de tabla.
Supervisión de la migración
Supervise la opción Segundos después del origen y, en cuanto el valor se acerque a 0, inicie la transición yendo a la pestaña del menú Iniciar transición en la parte superior de la pantalla de la actividad de migración.
Siga los pasos descritos en la ventana de transición antes de iniciar esta. Después de completar todos los pasos, seleccione Confirmar y, a continuación, seleccione Aplicar.
Una vez que se complete la transición, ya puede realizar validaciones y pasos posteriores a la migración.
Actividades posteriores a la migración
Una vez finalizada la migración, asegúrese de completar las siguientes actividades posteriores a la migración.
Hacer pruebas de seguridad de la aplicación en la base de datos de destino para verificar la migración.
Actualice la cadena de conexión para que apunte al nuevo servidor flexible.
Elimine el servidor de origen después de asegurar la continuidad de la aplicación.
Para limpiar los recursos de DMS, realice los pasos siguientes:
- En Azure Portal, seleccione Todos los servicios, busque Azure Database Migration Service y, luego, elija Azure Database Migration Services.
- Seleccione la instancia del servicio de migración en los resultados de la búsqueda y, a continuación, seleccione Eliminar servicio.
- En el cuadro de diálogo de confirmación, en el cuadro de texto TYPE THE DATABASE MIGRATION SERVICE NAME, especifique el nombre de la instancia y seleccione Eliminar.
Procedimientos recomendados de migración
Al llevar a cabo una migración, tenga en cuenta los siguientes procedimientos recomendados.
Como parte de la detección y evaluación, tome la SKU del servidor, el uso de CPU, el almacenamiento, los tamaños de base de datos y el uso de extensiones como algunos de los datos críticos que le ayudarán con las migraciones.
Haga migraciones de prueba antes de la migración en la fase de producción:
- Las migraciones de prueba son importantes para asegurarse de abarcar todos los aspectos de la migración de la base de datos, incluidas las pruebas de aplicaciones. El procedimiento recomendado consiste en comenzar ejecutando una migración de prueba. Después de que una migración recién iniciada entre en la fase Replicar cambios de datos con un retraso mínimo, use su destino de servidor flexible solo para ejecutar cargas de trabajo de prueba. Use ese destino para probar la aplicación para garantizar el rendimiento y los resultados esperados. Si va a migrar a una versión de MySQL superior, pruebe la compatibilidad de la aplicación.
- Una vez completadas las pruebas, puede migrar las bases de datos de producción. En este momento, tiene que finalizar el día y la hora de la migración de producción. Idealmente, en este momento se usará poco la aplicación. Todas las partes interesadas que tengan que participar tienen que estar disponibles y listas. Tenga en cuenta que la migración de producción requiere una supervisión cercana. Para una migración en línea, la replicación debe completarse antes de realizar la migración total para evitar la pérdida de datos.
Redirija todas las aplicaciones dependientes para acceder a la nueva base de datos principal y haga que el servidor de origen sea de solo lectura. A continuación, abra las aplicaciones para su uso en producción.
Después de que la aplicación comience a ejecutarse en el servidor flexible de destino, no pierda de vista el rendimiento de la base de datos para saber si necesita hacer ajustes.
Contenido relacionado
- ¿Qué es Azure Database for MySQL: servidor flexible?
- ¿Qué es Azure Database Migration Service?
- Problemas conocidos con la migración a Azure Database for MySQL
- Solución de problemas y errores comunes de Azure Database Migration Service (clásico)
- Solución de errores de DMS al conectarse a las bases de datos de origen