Preguntas más frecuentes (P+F)
Al usar Azure Database Migration Service, ¿cuál es la diferencia entre una migración sin conexión y una migración en línea? Azure Database Migration Service admite migraciones sin conexión y en línea. Con una migración sin conexión, el tiempo de inactividad de la aplicación se inicia cuando comienza la migración. Con una migración en línea, el tiempo de inactividad se limita al momento de transicionar al final del proceso. Se recomienda que pruebe una migración sin conexión para determinar si el tiempo de inactividad es aceptable; si no es así, realice una migración en línea. Puede encontrar una comparación entre las migraciones en línea y sin conexión en la tabla siguiente:
Área Migración en línea Migración sin conexión Disponibilidad de la base de datos para lecturas durante la migración Disponible Disponible Disponibilidad de la base de datos para escrituras durante la migración Disponible Por lo general, no se recomienda. Cualquier escritura iniciada después de la migración no se captura ni se migra Idoneidad de la aplicación Aplicaciones que necesitan un tiempo de actividad máximo Aplicaciones que pueden permitirse una ventana planeada de tiempo de inactividad Idoneidad del entorno Entorno de producción Normalmente, es un entorno de desarrollo, pruebas y algunos entornos de producción que se pueden permitir tiempo de inactividad Idoneidad para cargas de trabajo con escritura intensiva Esta opción es adecuada, pero se espera que reduzca la carga de trabajo durante la migración. No es aplicable. Las escrituras en el origen después de que se inicie la migración no se replican en el destino Transición manual Obligatorio No se requiere Tiempo de inactividad necesario Menor Más Tiempo de migración Depende del tamaño de la base de datos y de la actividad de escritura hasta la transición. Depende del tamaño de la base de datos. Voy a configurar un proyecto de migración en DMS y tengo dificultades para conectarme a la base de datos de origen. ¿Cuál debo hacer?
Si tiene problemas para conectarse al sistema de la base de datos de origen mientras trabaja en la migración, cree una máquina virtual en la misma subred de la red virtual con la que ha configurado la instancia de DMS. En la máquina virtual, debería poder ejecutar una prueba de conexión. Si la prueba de conexión se realiza correctamente, no debería tener ningún problema al conectarse a la base de datos de origen. Si la prueba de conexión no se realiza correctamente, póngase en contacto con el administrador de la red.
¿Por qué mi instancia de Azure Database Migration Service no está disponible o está detenida?
Si el usuario detiene explícitamente la instancia de Azure Database Migration Service (DMS) o si el servicio está inactivo durante un período de 24 horas, este estará en pausa o detenido automáticamente. En cada caso, el servicio no estará disponible y se encontrará en estado detenido. Para reanudar las migraciones activas, reinicie el servicio.
¿Existen recomendaciones sobre cómo optimizar el rendimiento de Azure Database Migration Service?
Hay un par de cosas que puedes intentar para acelerar la migración de la base de datos mediante DMS:
Use el plan de tarifa de uso general de varias CPU cuando cree la instancia de servicio para permitir que el servicio aproveche las diversas CPU virtuales para la paralelización y realizar una transferencia de datos más rápida.
De manera temporal, escale verticalmente la instancia de destino de Azure MySQL Database a la SKU de nivel Premium durante la operación de migración de datos para minimizar la limitación de Azure MySQL Database que puede afectar a las actividades de transferencia de datos al usar las SKU de nivel inferior.
¿Qué componentes de datos, esquemas y metadatos se migran como parte de la migración?
Azure Database Migration Service migra el esquema, los datos y los metadatos del origen al destino. Todos los siguientes componentes de datos, esquemas y metadatos se migran como parte de la migración de la base de datos:
Migración de datos: todas las tablas de todas las bases de datos o esquemas.
Migración de esquemas: nomenclatura, clave principal, tipo de datos, posición ordinal, valor predeterminado, nulabilidad, atributos de incremento automático, índices secundarios
Migración de metadatos, procedimientos almacenados, funciones, desencadenadores, vistas, restricciones de clave externa
¿Hay alguna opción para revertir una migración de servidor único a servidor flexible?
Puede realizar cualquier número de migraciones de prueba y, una vez se sienta seguro tras realizar las pruebas, hacer la migración final. Una migración de prueba no afecta al servidor único de origen, que sigue funcionando y continúa las replicaciones hasta que se realiza la migración real. Si se producen errores durante la migración de prueba, puede optar por posponer la migración final y mantener el servidor de origen en ejecución. Luego, puede volver a intentar la migración final después de resolver los errores. Después que haya realizado una migración final al servidor flexible y de que se haya cerrado el servidor único de origen, no podrá revertir el servidor flexible a un servidor único.
El tamaño de mi base de datos es superior a 1 TB, por lo que ¿cómo debo continuar con la migración?
Para admitir migraciones de bases de datos de más de 1 TB, genere una incidencia de soporte técnico con Azure Database Migration Service para escalar verticalmente al agente de migración para que admita las migraciones de bases de datos de más de 1 TB.
¿Se admite la migración entre regiones?
Azure Database Migration Service admite migraciones entre regiones, por lo que puede migrar el servidor único a un servidor flexible que esté implementado en otra región mediante DMS.
¿Se admite la migración entre suscripciones?
Azure Database Migration Service admite migraciones entre suscripciones, por lo que puede migrar el servidor único a un servidor flexible que esté implementado en otra suscripción mediante DMS.
¿Se admite la suscripción entre grupos de recursos?
Azure Database Migration Service admite migraciones entre grupos de recursos, por lo que puede migrar el servidor único a un servidor flexible que esté implementado en otro grupo de recursos mediante DMS.
¿Hay compatibilidad entre versiones?
Sí, se admite la migración desde servidores MySQL de una versión inferior (v5.6 y versiones posteriores) a versiones posteriores.