Compartir vía

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

  • Artículo

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

Importante

Algunas instancias de servidor único pueden requerir entradas obligatorias para realizar una migración automática correcta en contexto. Revise los detalles de la migración en la hoja Migración de Azure Portal para proporcionar esas entradas. Si no se proporcionan entradas obligatorias 2 días antes de la migración programada, se volverá a programar la migración a una fecha posterior.

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 y sin características complejas (réplica de lectura, red virtual, Cifrado de doble infraestructura, punto de conexión de servicio o reglas de red virtual) 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 para la SKU optimizada para uso general y memoria y hasta 30 minutos para la SKU básica. 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 SKU básica, la instancia programada se migrará con una ventana de tiempo de inactividad de hasta 30 minutos. La instancia se migrará a una SKU de uso general superior para garantizar una migración correcta y se escalará verticalmente a la SKU ampliable en 24-48 horas. Si después de la migración a la SKU ampliable, la instancia se queda sin créditos debido a una carga de trabajo intensiva de la CPU, considere la posibilidad de actualizar a la SKU de uso general en la instancia de servidor flexible.

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 sin características complejas habilitadas (Réplica de lectura, Red virtual, Cifrado de doble infraestructura, punto de conexión de servicio o reglas de red virtual), ahora puede designarse (si aún no está programada por el servicio) para la migración automática enviando los detalles del servidor mediante una incidencia de soporte técnico de Azure.

Para que el servidor no apto para la migración automática sea apto para la migración automática, sigue estos pasos:

  • 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.
  • 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 tiene réplicas de lectura, quita las réplicas de lectura. Puedes configurar réplicas de lectura después de la migración automática.
  • Si el servidor tiene habilitados los puntos de conexión de servicio (reglas de red virtual) o la configuración de red virtual, considera la posibilidad de quitarlos o pasar a la característica Private Link en la instancia de servidor único.
  • Si el servidor tiene habilitado el cifrado de infraestructura doble, considera la posibilidad de pasar a la característica Clave administrada por el cliente (CMK) en la instancia de servidor único.

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 y configuración de la programación y los detalles de la 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 bloquea 2 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 la instancia de servidor único tiene uno o varios de Private Link, la clave administrada por el cliente (CMK) y el administrador de Microsoft Entra habilitados, la migración automática local requiere entradas obligatorias para los puntos de conexión privados, CMK y administrador de Microsoft Entra para migrarse de la instancia de servidor único a la instancia de servidor flexible de destino. Las entradas del usuario deben proporcionarse 2 días antes de la ventana de migración programada. Si no se proporcionan las entradas de usuario antes de que se bloqueen los detalles de la migración, la migración se volverá a programar a un momento dado posterior. Después de proporcionar todas las entradas, asegúrese de Guardar la configuración en el Asistente para la migración automática. Pasos para proporcionar la entrada del usuario:

    • Vaya a la Hoja de migración la instancia de servidor único y seleccione Editar migración programada.
    • En la sección Detalles de la migración automática haga clic en el botón Autenticar para autenticar y guardar la conexión de la API de ARM para migrar el servidor.
    • Si el servidor tiene Administrador de Microsoft Entra configurado, puede proporcionar entradas en la sección Administrador de Microsoft Entra en el Asistente para la migración automática:
      • La migración del administrador de Microsoft Entra para el servidor de destino requiere que se agregue una identidad a Azure Database for MySQL: servidor flexible. La identidad requiere que se concedan los siguientes privilegios: User.Read.All, GroupMember.Read.All y Application.Read.All. Seleccione una identidad administrada asignada por el usuario adecuada y conceda los permisos adecuados siguiendo los pasos indicados aquí.
    • Si el servidor tiene configurada Clave administrada por el cliente, puede proporcionar las entradas en la sección Cifrado de datos del asistente de migración automática:
      • La migración del cifrado de claves administradas por el cliente requiere que se agregue una Identidad a Azure Database for MySQL: servidor flexible. Seleccione una identidad administrada asignada por el usuario adecuada. La clave o identificador de clave enumerados se migraría del servidor de origen al servidor de destino y se le deberían conceder los siguientes privilegios: Obtener, Ajustar clave, Desencapsular clave con el fin de acceder al almacén de claves.
    • Si el servidor único tiene puntos de conexión privados, realiza los siguientes pasos obligatorios al revisar la programación de migración al menos 2 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.
        • La migración automática no admite la zona DNS privado personalizado. La zona DNS privado debe ser privatelink.mysql.database.azure.com.
        • Los puntos de conexión privados método de aprobación de conexión deben establecerse como aprobación automática y no la aprobación manual. La migración automática no admite puntos de conexión privados de aprobación manual.
      • Asegúrate de que tienes acceso al rol de colaborador de nivel de suscripción o de grupo de recursos para evitar cualquier problema de permisos durante la autenticación.
      • Active la casilla de confirmación después de realizar las comprobaciones de requisitos previos enumerados para migrar puntos de conexión privados.

    Nota:

    Si las entradas obligatorias para la migración no se proporcionan al menos 2 días antes de la migración programada, la migración se vuelve a programar a una fecha posterior.

    Nota:

    En el caso de la instancia de servidor único con puntos de conexión privados, elimine la instancia de origen de servidor único después de la validación de la migración. Si no se realiza ninguna operación de eliminación del servidor, la instancia de origen se mantiene hasta 14 días después de los cuales el servicio la eliminará.

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.
  • Los parámetros, los ajustes, la configuración y las reglas de firewall de la instancia de servidor único no deben actualizarse durante los 2 días previos a la migración automática programada.
  • 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.
  • En el caso de la instancia de servidor único con puntos de conexión privados, elimine la instancia de origen de servidor único después de la validación de la migración. Si no se realiza ninguna operación de eliminación del servidor, la instancia de origen se mantiene hasta 14 días después de los cuales el servicio la eliminará.
  • 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 bloquean 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