Migración local automática de Azure Database for MySQL: Servidor único a servidor flexible

SE APLICA A: Azure Database for MySQL: Servidor único

La migración automática local de Azure Database for MySQL, con servidor único a servidor flexible es una migración local iniciada por el servicio durante la ventana de mantenimiento planeado para cargas de trabajo de base de datos de servidor único con SKU básica, de uso general o optimizada para memoria, el almacenamiento de datos usado <= 100 GiB y sin características complejas (CMK, Microsoft Entra ID, Read Replica, Virtual Network, Double Infra encryption, Service Endpoint/VNet Rules) habilitado. El servicio identifica los servidores aptos y se envían pasos detallados de notificación anticipada para revisar los detalles de la migración.

La migración local proporciona una experiencia de migración sin conexión altamente resistente y de recuperación automática durante una ventana de mantenimiento planeado, con menos de 5 minutos de tiempo de inactividad. Usa la tecnología de copia de seguridad y restauración para acelerar el tiempo de migración. Esta migración elimina la sobrecarga de migrar manualmente el servidor y asegura de que pueda aprovechar las ventajas del servidor flexible, incluido un mejor rendimiento y precio, un control pormenorizado de la configuración de la base de datos y ventanas de mantenimiento personalizadas. A continuación se describen las fases clave de la migración:

• El servidor flexible de destino se implementa y hereda todos los conjuntos de características y propiedades (incluidos los parámetros de servidor y las reglas de firewall) del servidor único de origen. El servidor único de origen se establece en solo lectura y la copia de seguridad del servidor único de origen se copia en el servidor flexible de destino.
• El conmutador DNS y la transición se realizan correctamente en la ventana de mantenimiento planeado con un tiempo de inactividad mínimo, lo que permite el mantenimiento de la misma cadena de conexión después de la migración. Las aplicaciones cliente se conectan sin problemas al servidor flexible de destino sin necesidad de actualizaciones manuales controladas por el usuario. Además de los formatos de cadena de conexión (servidor único y flexible) que se admiten en el servidor flexible migrado, ambos formatos de nombre de usuario: username@server_name y nombre de usuario también se admiten en el servidor flexible migrado.
• El servidor flexible migrado está en línea y ahora se puede administrar a través de Azure Portal/la CLI. El servidor único detenido se elimina siete días después de la migración.

Nota:

Si la instancia de servidor único tiene almacenamiento de uso general V1, la instancia programada se somete a una operación de reinicio adicional 12 horas antes de la hora de migración programada. Esta operación de reinicio sirve para habilitar el parámetro de servidor de log_bin necesario para actualizar la instancia al almacenamiento de uso general V2 antes de realizar la migración automática en contexto.

Elegibilidad

Si posee una carga de trabajo de servidor único con almacenamiento de datos usado <= 100 GiB y sin características complejas (CMK, Microsoft Entra ID, Réplica de lectura, red virtual, doble cifrado de infraestructura, reglas de red virtual o punto de conexión de servicio) habilitadas, ahora puede designarse personalmente (si aún no está programado por el servicio) para la migración automática mediante el envío de los detalles del servidor con este formulario.

Configuración de alertas de migración

El servicio envía una notificación anticipada a los servidores aptos para la migración automática local.

A continuación se describen las maneras de comprobar y configurar las notificaciones de migración automática:

• Los propietarios de suscripciones de servidores únicos programados para la migración automática reciben una notificación por correo electrónico.
• Configure las alertas de estado del servicio para recibir notificaciones de progreso y programación de migración local a través de correo electrónico o SMS siguiendo estos pasos.
• Compruebe la notificación de migración local en Azure Portal siguiendo estos pasos.

Revisión de la programación de migración

A continuación, se describen las maneras de revisar la programación de migración una vez que haya recibido la notificación de migración automática local:

Nota:

La programación de migración se bloqueará 7 días antes de la ventana de migración programada después de la cual no podrá volver a programar.

• La página de información general del servidor único de la instancia muestra un banner del portal con información sobre la programación de migración.
• En el caso de los servidores únicos programados para la migración automática, se ilumina una nueva hoja de migración en el portal. Para revisar la programación de migración, vaya a la hoja Migración de la instancia de servidor único.
• Si desea aplazar la migración, puede aplazarla un mes a la vez. Para ello, vaya a la hoja Migración de la instancia de servidor único en Azure Portal y vuelva a programar la migración seleccionando otra ventana de migración dentro de un mes.
• Si el servidor único tiene una SKU de uso general, tiene la opción de habilitar la alta disponibilidad al revisar la programación de migración. Como la alta disponibilidad solo se puede habilitar durante el tiempo de creación de un servidor flexible de MySQL, se recomienda encarecidamente habilitar esta característica al revisar la programación de migración.
• Si el servidor único tiene puntos de conexión privados, realice los siguientes pasos obligatorios al revisar la programación de migración al menos 7 días antes de la migración programada:
  • Revise los puntos de conexión privados que se muestran para migrar. Asegúrese de que están marcados como Listos para migrar. Si están marcados como ineligibles, seleccione la suscripción adecuada y la zona DNS privada.
  • Active la casilla de confirmación después de realizar las comprobaciones de requisitos previos enumerados para migrar puntos de conexión privados.
  • Haga clic en el botónAutenticar para autenticar la conexión ARM necesaria para migrar los puntos de conexión privados de origen al servidor de destino.

Comprobaciones de requisitos previos para la migración automática local

Revise los siguientes requisitos previos para garantizar una migración automática correcta en contexto:

• La instancia de servidor único debe estar en estado listo y no en estado detenido durante la ventana de mantenimiento planeado para que se realice la migración automática.
• En el caso de la instancia de Servidor único con SSL habilitado, asegúrese de tener los tres certificados (BaltimoreCyberTrustRoot, DigiCertGlobalRootG2 Root CA y DigiCertGlobalRootCA Root CA) disponibles en el almacén raíz de confianza. Además, si tiene el certificado anclado a la cadena de conexión, cree un certificado CA combinado con los tres certificados antes de la migración automática programada para garantizar la continuidad empresarial después de la migración.
• El motor MySQL no garantiza ningún criterio de ordenación si no hay ninguna cláusula "SORT" presente en las consultas. Después de la migración automática local, puede observar un cambio en el criterio de ordenación. Si es fundamental conservar el criterio de ordenación, asegúrese de que las consultas se actualizan para incluir la cláusula "SORT" antes de la migración automática local programada.
• Si el Servidor único de Azure Database for MySQL de origen tiene la versión v8.x del motor, asegúrese de actualizar la versión del controlador de cliente .NET del servidor de origen a la versión 8.0.32 para evitar cualquier incompatibilidad de codificación después de la migración al Servidor flexible.
• Si el servidor único de Azure Database for MySQL de origen tiene la versión v8.x del motor, asegúrese de actualizar la versión TLS del servidor de origen de v1.0 o v1.1 a TLS v1.2 antes de la migración, ya que las versiones anteriores de TLS han quedado en desuso para el servidor flexible.
• Si el servidor único de Azure Database for MySQL de origen tiene nombres de reglas de firewall que superan los 80 caracteres, cámbielos para asegurarse de que la longitud del nombre sea inferior a 80 caracteres. (La longitud del nombre de la regla de firewall admitida en el servidor flexible es de 80 caracteres, mientras que en el servidor único la longitud permitida es de 128 caracteres).
• Si el servidor único de Azure Database for MySQL de origen utiliza puertos no predeterminados como 3308, 3309 y 3310, cambie el puerto de conectividad a 3306, ya que los puertos no predeterminados mencionados anteriormente no son compatibles con servidor flexible.

¿Cómo se aprovisiona automáticamente el servidor flexible de MySQL de destino?

El nivel de proceso y la SKU para el servidor flexible de destino se aprovisionan en función del plan de tarifa y los núcleos virtuales del servidor único de origen según los detalles de la tabla siguiente.

Plan de tarifa de servidor único	Núcleos virtuales de servidor único	Nivel del servidor flexible	Nombre de SKU del servidor flexible
Básico	1	Flexible	Standard_B1s
Básico	2	Flexible	Standard_B2s
Uso general	2	GeneralPurpose	Standard_D2ds_v4
Uso general	4	GeneralPurpose	Standard_D4ds_v4
De uso general	8	GeneralPurpose	Standard_D8ds_v4
Uso general	16	GeneralPurpose	Standard_D16ds_v4
De uso general	32	GeneralPurpose	Standard_D32ds_v4
De uso general	64	GeneralPurpose	Standard_D64ds_v4
Memoria optimizada	4	MemoryOptimized	Standard_E4ds_v4
Memoria optimizada	8	MemoryOptimized	Standard_E8ds_v4
Memoria optimizada	16	MemoryOptimized	Standard_E16ds_v4
Memoria optimizada	32	MemoryOptimized	Standard_E32ds_v4

• La versión, región, *tamaño de almacenamiento, suscripción y grupo de recursos de MySQL para el servidor flexible de destino son los mismos que los del servidor único de origen.
• Para servidores únicos con menos de 20 GiB de almacenamiento, el tamaño de almacenamiento se establece en 20 GiB, ya que es el límite de almacenamiento mínimo en Azure Database for MySQL - Servidor flexible.
• Ambos formatos de nombre de usuario: username@server_name (servidor único) y nombre de usuario (servidor flexible) se admiten en el servidor flexible migrado.
• Ambos formatos de cadena de conexión: servidor único y servidor flexible se admiten en el servidor flexible migrado.
• En el caso de la instancia de servidor único con almacén de consultas habilitado, el parámetro del servidor "slow_query_log" en la instancia de destino se establece en ACTIVADO para garantizar la paridad de las características al migrar al servidor flexible. Para determinadas cargas de trabajo, esto podría afectar al rendimiento. Si observase alguna degradación del rendimiento, ajuste este parámetro del servidor a "DESACTIVADO" en la instancia del servidor flexible.

Pasos posteriores a la migración

Esta es la información que necesita saber después de la migración local:

Nota:

Después de la migración, no reinicie la instancia de servidor único detenida, ya que puede dificultar la conectividad de la aplicación y del cliente.

• Copie las siguientes propiedades del servidor único de origen para que la operación de migración local del servidor flexible de destino se complete correctamente:
  • Configuración de la página de supervisión (alertas, métricas y configuración de diagnóstico) y configuración de bloqueos
  • Los scripts de Terraform/CLI que hospede para administrar la instancia de servidor único deben actualizarse con referencias al servidor flexible.
• En el caso de la instancia de servidor único con almacén de consultas habilitado, el parámetro del servidor "slow_query_log" en la instancia de destino se establece en ACTIVADO para garantizar la paridad de las características al migrar al servidor flexible. Nota, para determinadas cargas de trabajo, esto podría afectar al rendimiento. Si observase alguna degradación del rendimiento, ajuste este parámetro del servidor a "DESACTIVADO" en la instancia del servidor flexible.
• Para la instancia de servidor único con Microsoft Defender for Cloud habilitado, se migra el estado de habilitación. Para lograr la paridad en la migración automática del servidor flexible para las propiedades que puede configurar en servidor único, tenga en cuenta los detalles de la tabla siguiente:

Propiedad	Configuración
Supresión de tipos de alerta específicos	Deshabilite tipos de alerta específicos con la plataforma Microsoft Defender for Cloud. Para obtener más información, consulte Supresión de alertas de la guía de Microsoft Defender for Cloud. Los usuarios de servidor único pueden usar la propiedad de API: properties.disabledAlerts
Notificaciones por correo electrónico	Defina de forma centralizada notificaciones por correo electrónico para las alertas de Microsoft Defender for Cloud para todos los recursos de una suscripción. Para más información, consulte Configuración de notificaciones de alertas de seguridad por correo electrónico. Los usuarios de servidor único pueden usar las propiedades de API: properties.emailAccountAdmins, properties.emailAddresses
Exportación de alertas para su posterior procesamiento o archivado	Las alertas se almacenan en la plataforma de Microsoft Defender for Cloud y se exponen a través de Azure Resource Graph. Es posible exportar alertas a almacenes diferentes y administrar la retención por separado. Para obtener más información, consulte Configuración de la exportación continua en Azure Portal: Microsoft Defender for Cloud. Los usuarios de servidor único pueden usar las propiedades de API: properties.retentionDays, properties.storageAccountAccessKey, properties.storageEndpoint

Preguntas más frecuentes (P+F)

Q. ¿Por qué se está produciendo la migración automática?

A. Su instancia de Azure Database for MySQL : servidor único es apta para la migración local a nuestra oferta insignia de Azure Database for MySQL: servidor flexible. Esta migración local eliminará la sobrecarga de migrar manualmente el servidor y asegura de que puede aprovechar las ventajas del servidor flexible, incluido un mejor rendimiento & precios, un control pormenorizado de la configuración de la base de datos y ventanas de mantenimiento personalizadas.

Q. ¿Cómo tiene lugar la migración automática? ¿Qué tantos elementos migra?

A. El servidor flexible se aprovisiona para que coincida con los mismos núcleos virtuales y el almacenamiento que el servidor único. A continuación, el servidor único de origen se coloca en estado detenido, se toma la instantánea del archivo de datos y se copia en el servidor flexible de destino. El conmutador DNS se realiza para enrutar todas las conexiones existentes al destino y el servidor flexible de destino se pone en línea. La migración automática migra los archivos de datos de todo el servidor (incluidos el esquema, los datos, los inicios de sesión) además de los parámetros de servidor (todos los parámetros de servidor modificados del origen se copian en el destino, los parámetros de servidor sin modificar toman el valor predeterminado definido por el servidor flexible) y las reglas de firewall. Se trata de una migración sin conexión en la que se ve un tiempo de inactividad de 5 minutos o menos.

Q. ¿Cómo puedo configurar o ver las alertas de migración local?

A A continuación se muestran las formas en que puede configurar alertas:

• Configure las alertas de estado del servicio para recibir notificaciones de progreso y programación de migración local a través de correo electrónico o SMS siguiendo estos pasos.
• Compruebe la notificación de migración local en Azure Portal siguiendo estos pasos.

Q. ¿Cómo puedo aplazar la migración programada?

A. Para revisar la programación de migración, vaya a la hoja Migración de la instancia de servidor único. Si desea aplazar la migración, puede aplazarla un mes como máximo. Para ello, vaya a la hoja Migración de la instancia de servidor único en Azure Portal y vuelva a programar la migración seleccionando otra ventana de migración dentro de un mes. Los detalles de la migración se bloquearán siete días antes de la ventana de migración programada, después de la cual no se podrá volver a programar. Esta migración local se puede aplazar mensualmente hasta el 16 de septiembre de 2024.

Q. ¿Qué nombre de usuario y cadena de conexión se admitirá para el servidor flexible migrado? ​​

A Ambos formatos de nombre de usuario: username@server_name (formato de servidor único) y nombre de usuario (formato de servidor flexible) se admiten para el servidor flexible migrado y, por lo tanto, no es necesario actualizarlos para mantener la continuidad de la aplicación después de la migración. Además, ambos formatos de cadena de conexión (formato de servidor único y flexible) también se admiten para el servidor flexible migrado.

Q. ¿Cómo habilitar la alta disponibilidad para mi servidor migrado automáticamente?

A. De manera predeterminada, la migración automática configura la migración a una instancia que no es de alta disponibilidad. Dado que la alta disponibilidad solo se puede habilitar en tiempo de creación del servidor, debe habilitar la alta disponibilidad antes de la migración automática programada mediante la opción de edición de programación de migración automática en el portal. La alta disponibilidad solo se puede habilitar para una SKU de uso general\optimizada para memoria en el servidor flexible de destino, ya que la migración de SKU básica a ampliable no admite la configuración de alta disponibilidad.

Q. ¿Veré una diferencia de precios en mi posible traslado del servidor único básico de MySQL al servidor flexible de MySQL?

A Algunos servidores pueden ver un pequeño aumento del precio después de la migración (los costes estimados se pueden ver seleccionando la opción de edición de programación de migración automática en el portal), ya que el límite de almacenamiento mínimo en ambas ofertas es diferente (5 GiB en servidor único; 20 GiB en servidor flexible) y el coste de almacenamiento ($0,1 en servidor único; $0,115 en servidor flexible) para el servidor flexible es ligeramente superior al servidor único. En el caso de los servidores afectados, este aumento de precios en el servidor flexible proporciona un mejor rendimiento en comparación con el servidor único.

Contenido relacionado

• Administración de un servidor flexible de Azure Database for MySQL mediante Azure Portal.