Migrar MySQL: Servidor flexible a compatibilidad con zonas de disponibilidad
Esta guía describe cómo migrar MySQL: Servidor Flexible desde la compatibilidad con zonas de no disponibilidad a la compatibilidad con zonas de disponibilidad.
Puede configurar el servidor flexible de Azure Database for MySQL para usar uno de los dos modelos de arquitectura de alta disponibilidad (HA):
Arquitectura de alta disponibilidad de la misma zona (zonal). Esta opción es preferible para la redundancia de infraestructura con menor latencia de red, ya que el servidor principal y el servidor en espera estarán en la misma zona de disponibilidad. Proporciona alta disponibilidad sin necesidad de configurar la redundancia de las aplicaciones entre zonas. La alta disponibilidad en la misma zona se prefiere cuando se quiere lograr el máximo nivel de disponibilidad dentro de una sola zona de disponibilidad con la mínima latencia de red. La alta disponibilidad en la misma zona está disponible en todas las regiones de Azure donde es posible utilizar la opción Servidor flexible de Azure Database for MySQL. Para más información sobre la arquitectura de alta disponibilidad de la misma zona, vea Arquitectura de alta disponibilidad de la misma zona.
Arquitectura de alta disponibilidad con redundancia de zona. Esta opción es preferible para el aislamiento completo y la redundancia de la infraestructura en varias zonas de disponibilidad. Proporciona el máximo nivel de disponibilidad, pero exige configurar la redundancia de las aplicaciones entre zonas. La alta disponibilidad con redundancia de zona es preferible cuando se quiere lograr el máximo nivel de disponibilidad frente a cualquier error de infraestructura en la zona de disponibilidad y cuando la latencia entre las zonas de disponibilidad es aceptable. Solo se puede habilitar cuando se crea el servidor. La alta disponibilidad con redundancia de zona está disponible en un subconjunto de regiones de Azure donde la región admite varias zonas de disponibilidad y recursos compartidos de archivos Premium con redundancia de zona están disponibles. Para más información sobre la arquitectura de alta disponibilidad con redundancia de zona, vea Arquitectura de alta disponibilidad con redundancia de zona.
Para migrar la carga de trabajo existente de alta disponibilidad zonal (misma zona a alta disponibilidad) con redundancia de zona, deberá hacer lo siguiente:
Implemente y configure un nuevo servidor que se haya configurado para alta disponibilidad con redundancia de zona.
Siga las instrucciones de migración de este documento para mover los recursos al nuevo servidor.
Requisitos previos
Para migrar a la compatibilidad con la zona de disponibilidad:
Necesitará al menos uno de los dos servidores siguientes:
Un servidor de origen que ejecuta el servidor flexible de Azure Database for MySQL en una región que no admite zonas de disponibilidad.
Servidor flexible de Azure Database for MySQL que no estaba habilitado para alta disponibilidad en el momento de la creación.
Importante
Si originalmente aprovisionó el servidor flexible de Azure Database for MySQL como un servidor que no es de alta disponibilidad, simplemente puede habilitarlo para la arquitectura de alta disponibilidad de la misma zona. Sin embargo, si quiere habilitarla para la arquitectura de alta disponibilidad con redundancia de zona, deberá implementar una de las opciones de migración disponibles que se enumeran en este artículo.
Deberá crear un servidor de destino que ejecute el servidor flexible de Azure Database for MySQL en una región que admita zonas de disponibilidad. Para más información sobre cómo crear un servidor flexible de Azure Database for MySQL, vea Uso de Azure Portal para crear un servidor flexible de Azure Database for MySQL. Asegúrese de que el servidor creado está configurado para la redundancia de zona habilitando la alta disponibilidad y seleccionando la opción con Redundancia de zona.
Sugerencia
Si desea que la flexibilidad de poder moverse entre zonas (misma zona) y alta disponibilidad con redundancia de zona en el futuro, puede aprovisionar el servidor flexible de Azure Database for MySQL con alta disponibilidad con redundancia de zona habilitada durante la creación del servidor. Una vez aprovisionado el servidor, puede deshabilitar la alta disponibilidad.
Requisitos de tiempo de inactividad
Las migraciones se pueden clasificar como en línea o sin conexión:
• Migración sin conexión. Si la aplicación puede permitirse cierto tiempo de inactividad, las migraciones sin conexión siempre son la opción preferida, ya que son sencillas y fáciles de ejecutar. Con una migración sin conexión, el servidor de origen se desconecta, y se realiza un volcado y una restauración de las bases de datos en el servidor de destino. Esta opción requerirá el mayor tiempo de inactividad. La duración del tiempo de inactividad viene determinada por el tiempo necesario para realizar la restauración en el servidor de destino.
• Migración en línea. Esta opción tiene un tiempo de inactividad mínimo y es la mejor opción si desea menos tiempo de inactividad. El servidor de origen permite actualizaciones y la solución de migración se encargará de replicar los cambios continuos entre el servidor de origen y de destino junto con el volcado inicial y la restauración en el destino.
Opción de migración 1: Migración sin conexión
Puede migrar de un servidor flexible de Azure Database a otro mediante una de las siguientes herramientas. Ambas opciones requerirán tiempo de inactividad.
Data Migration Service (DMS). Para obtener información sobre cómo migrar el servidor flexible de MySQL a otro con DMS, vea Migrar Azure Database for MySQL: Servidor único a servidor flexible sin conexión mediante DMS mediante Azure Portal. Aunque en el tutorial se describen los pasos para migrar del servidor único de Azure MySQL al servidor flexible, puede usar el mismo procedimiento para migrar datos de un servidor flexible de Azure Database for MySQL que no admite zonas de disponibilidad a otra que admita zonas de disponibilidad.
Herramientas de código abierto. Puede migrar sin conexión con herramientas de código abierto, como MySQL Workbench, mydumper/myloader, o mysqldump para realizar copias de seguridad y restaurar la base de datos. Para obtener información sobre cómo usar estas herramientas, vea Opciones de para migrar Azure Database for MySQL: Servidor único a servidor flexible. Aunque en el tutorial se describen los pasos para migrar del servidor único de Azure MySQL al servidor flexible, puede usar el mismo procedimiento para migrar datos de un servidor flexible de Azure Database for MySQL que no admite zonas de disponibilidad a otra que admita zonas de disponibilidad.
Opción de migración 2: Migración en línea
Puede migrar de un servidor flexible de Azure Database a otro con un tiempo de inactividad mínimo a las aplicaciones mediante una de las siguientes herramientas:
Data Migration Service (DMS). Para obtener información sobre cómo migrar el servidor flexible de MySQL a otro con DMS, vea Migración de Azure Database for MySQL: Servidor único a servidor flexible en línea mediante DMS a través de Azure Portal. Aunque en el tutorial se describen los pasos para migrar del servidor único de Azure MySQL al servidor flexible, puede usar el mismo procedimiento para migrar datos de un servidor flexible de Azure Database for MySQL que no admite zonas de disponibilidad a otra que admita zonas de disponibilidad.
Herramientas de código abierto. Puede usar una combinación de herramientas de código abierto, como mydumper/myloader junto con Replicación de datos de entrada. Para obtener información sobre cómo configurar la replicación de datos de entrada, vea Configuración de la replicación de datos de Azure Database for MySQL.
Importante
La replicación de datos de entrada no es compatible con los servidores habilitados para alta disponibilidad. La solución consiste en aprovisionar primero el servidor de destino con alta disponibilidad con redundancia de zona y, a continuación, deshabilitar la alta disponibilidad antes de configurar la replicación de datos de entrada. Una vez completada la replicación, habilite la alta disponibilidad con redundancia de zona una vez más en el servidor de destino.
Pasos siguientes
Más información sobre: