Fases y consideraciones de migración
Una migración correcta equilibra las consideraciones en varias fases.
Fases de migración
Las migraciones se producen en varias fases. En primer lugar, hay que planificar el enfoque de la migración: descubrir y evaluar los recursos de la base de datos, los requisitos empresariales como el tiempo de inactividad y un plan alternativo si falla la migración. A continuación, hay que preparar la migración mediante el aprovisionamiento de los recursos adecuados y la configuración de la conectividad entre entornos de origen y de destino. Una vez definido el enfoque de la migración y listos los recursos, suele ser conveniente realizar un simulacro en un entorno de ensayo para identificar problemas antes de la migración a producción. Por último, hay que realizar la migración final y validar su progreso continuo y su correcta finalización.
Este módulo se centra en las fases de preparación (2) y migración final (4, 5).
Consideraciones de migración
Debe evaluar los requisitos de tiempo de inactividad de la aplicación, la compatibilidad de versiones, las redes y la seguridad, el rendimiento, el costo y la continuidad empresarial.
Tiempo de inactividad de la aplicación
Una de las primeras cosas que debe tener en cuenta es cuánto tiempo de inactividad puede soportar su empresa. La respuesta restringe fuertemente las opciones de migración disponibles.
El mejor tiempo de inactividad es el que los usuarios no notan. En la práctica, las migraciones son procedimientos complejos y las decisiones relativas a las consideraciones de este módulo dictan el tiempo de inactividad necesario. Entre los inconvenientes se incluyen la disponibilidad frente al costo y el riesgo de la migración. Debido a la complejidad implicada en reducir el tiempo de inactividad a minutos o incluso segundos, es importante probar los supuestos y determinar cuánto tiempo de inactividad por migración es aceptable.
Migraciones sin conexión
Con una migración sin conexión, debe apagar la aplicación para mover la base de datos. Esto garantiza que no habrá ningún cambio en los datos durante la migración. Sin embargo, este enfoque requiere desmontar la base de datos para finalizar la exportación de datos. Como mínimo, el tiempo de inactividad será el que se tarde en transferir los datos. Una migración sin conexión implica:
- Desconectar todas las aplicaciones de la base de datos de origen.
- Exportar el contenido de la base de datos de origen.
- Importar los datos de origen a la base de datos de destino.
- Volver a conectar las aplicaciones a la base de datos de destino una vez completada la importación.
Algunas aplicaciones tienen ventanas de mantenimiento programadas durante períodos de tráfico bajo. Estos son momentos ideales para realizar migraciones sin conexión.
Una migración incremental sin conexión reduce el tiempo de inactividad moviendo la mayor parte de los datos antes de desconectar la aplicación. En primer lugar, migre una copia de seguridad completa de la base de datos. A continuación, migre los cambios a la base de datos que se ha agregado desde la migración anterior. Cuando el tiempo necesario para migrar estos nuevos cambios se ajuste a su tiempo de inactividad aceptable, desconecte la aplicación para inmovilizar los datos y finalizar la migración. Es posible que encuentre que un solo incremento de migración es suficiente para reducir el tiempo de inactividad en un orden de magnitud o más, especialmente para las bases de datos con años de historial. En el caso de las bases de datos grandes y ocupadas, es posible que tenga que migrar varios incrementos para alcanzar un tiempo de inactividad aceptable.
Migraciones en línea
Con una migración en línea, puede reducir o incluso eliminar la necesidad de tiempo de inactividad mediante la replicación de cambios desde el servidor de origen al servidor de destino durante la migración y, a continuación, pasar al servidor de destino cuando la replicación está totalmente sincronizada.
A veces, el tiempo de inactividad es indeseable o incluso inaceptable. En este caso, es imposible "inmovilizar" el estado de la base de datos desactivando la aplicación. En su lugar, la base de datos de origen se replica en la base de datos de destino durante las operaciones normales. Cuando el destino está totalmente atrapado con el origen, la aplicación pasa a la base de datos de destino.
Una migración en línea requiere que:
- Comience a replicar la base de datos de origen en la base de datos de destino.
- Cuando se detecta la base de datos de destino, inmovilice la base de datos de origen pausando la aplicación u obligando a que las escrituras produzcan errores habilitando el modo de solo lectura.
- Cuando la base de datos de destino esté al 100 % con los cambios, desactive la replicación en el destino.
- Redirija todos los clientes a la base de datos de destino y reanude las operaciones.
- Apague la base de datos de origen heredada.
Comparación entre migraciones en línea y migraciones sin conexión
Aunque las migraciones sin conexión requieren tiempo de inactividad, la técnica de migración incremental descrita anteriormente reduce considerablemente el tiempo de inactividad. Los incrementos múltiples pueden reducir la migración final a los datos de un día o menos. Los servicios automatizados, como Azure DMS, minimizan el tiempo de inactividad realizando una serie de migraciones cada vez más pequeñas. Las migraciones incrementales sin conexión también se pueden realizar manualmente si la configuración de red impide la automatización.
Las migraciones en línea coordinan una operación delicada entre los equipos de base de datos y aplicaciones. Las aplicaciones cliente deben ser herramientas para reaccionar correctamente a errores de escritura para evitar la pérdida de datos durante la migración. Los clientes también deben admitir la conexión a un nuevo servidor de bases de datos sin interrumpir la experiencia del usuario. Si esta herramienta de aplicación aún no existe, es posible que sea bastante costoso compilar.
Compatibilidad de versiones
La mayoría de las operaciones de aplicación son compatibles con las actualizaciones de MySQL. Sin embargo, en algunos casos, los componentes de la aplicación o el uso de la base de datos solo pueden funcionar con determinadas versiones de MySQL.
Compruebe que todos los componentes de la aplicación son compatibles con la versión de la base de datos de destino. Considere la posibilidad de separar las actualizaciones de versiones de las migraciones que reubican o reconfiguran una base de datos. Por ejemplo, si está migrando de un servidor MySQL 5.7 local a un servidor flexible de Azure Database for MySQL que ejecute MySQL 8.0, considere migrar de un servidor local a un servidor flexible Azure Database for MySQL que ejecute MySQL 5.7 y, a continuación, actualizar de 5.7 a 8.0 in situ.
Redes y seguridad
Las migraciones de bases de datos requieren transferir datos de la base de datos de origen a la de destino. El modo y la rapidez con que esto ocurra dependen en gran medida de la conexión entre las dos redes. Si no puede establecer una conexión dinámica desde el origen al destino, deberá transferir archivos de datos físicos de otra manera, por ejemplo a través de una estación de trabajo o servidor intermedios. En ese caso, asegúrese de tener suficiente espacio en disco para almacenar las instantáneas en cada sistema a lo largo del proceso.
También es fundamental tener en cuenta los requisitos de seguridad durante la migración. Necesitará la autenticación y los permisos adecuados para las bases de datos de origen y de destino. También puede crear cuentas de servicio para realizar algunos o todos los pasos de migración y, después, puede quitar su acceso tras la finalización.
Tanto si la base de datos de origen es local como si se encuentra en otro proveedor de nube, la configuración de red normalmente no permite conexiones externas. Deberá configurar la red para permitir conexiones con Azure.
Si la base de datos de origen es local y el volumen de datos es grande, mover terabytes de datos a través de una conexión normal a Internet puede ser poco práctico. En este escenario, considere la posibilidad de configurar una conexión de Azure ExpressRoute entre la red y Azure.
Incluso si usa una instancia de ExpressRoute, es probable que la conexión en la que se encuentra también sirva otro tráfico, y ambos pueden interferir entre sí. Dependiendo de la contención, el impacto en el rendimiento de las aplicaciones existentes y el proceso de migración podría ser significativo.
Rendimiento
Las migraciones de bases de datos son una excelente oportunidad para aumentar la capacidad mediante el cambio de tamaño de la infraestructura. El uso de la base de datos puede beneficiarse del aumento de los recursos de CPU, RAM o E/S.
Antes de aprovisionar el servidor de destino, tenga en cuenta el uso actual de la base de datos. Supervise las métricas de rendimiento, como el uso de CPU, junto con el crecimiento de los pronósticos y los contratos de nivel de servicio para decidir si debe asignar un tamaño de proceso mayor. Por el contrario, puede encontrar que la capacidad está sobreasignada y que reducir el tamaño ahorra costos.
Costos
Al migrar a Azure, puede aprovechar precios transparentes. Con la SKU seleccionada y otros parámetros, como redundancia y alta disponibilidad, la calculadora de precios de Azure le permite estimar sus costos posteriores a la migración durante la planificación. También puedes usar la calculadora para comparar precios y disponibilidad.
Continuidad del negocio
Las migraciones de bases de datos son un buen momento para revisar las métricas y los objetivos de continuidad empresarial. Puede ser adecuado cambiar las directivas de retención de copia de seguridad o cambiar a copias de seguridad con redundancia geográfica o alta disponibilidad. Tenga en cuenta el tiempo de actividad histórico frente al contrato de nivel de servicio y el tiempo de recuperación de interrupciones. Las migraciones también proporcionan ejemplos reales de cómo poner en marcha una nueva base de datos a partir de archivos de datos físicos, lo que puede servir de base para los planes de recuperación ante desastres.