Mantenimiento programado de Azure Database for MySQL: servidor flexible

  • Artículo

SE APLICA A: Azure Database for MySQL: Servidor flexible

Azure Database for MySQL: servidor flexible realiza un mantenimiento periódico para conservar la base de datos administrada protegida, estable y actualizada. Durante el mantenimiento, el servidor obtiene nuevas características, actualizaciones y revisiones.

Importante

Evite todas las operaciones del servidor (modificaciones, cambios de configuración, inicio o detención del servidor) durante el mantenimiento de Azure Database for MySQL Flexible Server. La participación en estas actividades puede dar lugar a resultados impredecibles, lo que puede afectar al rendimiento y la estabilidad del servidor. Espere hasta que finalice el mantenimiento antes de realizar operaciones de servidor.

Selección de una ventana de mantenimiento

Puede programar el mantenimiento durante un día concreto de la semana y una ventana de tiempo dentro de ese día. También puede dejar que el sistema elija un día y una hora de esa ventana de tiempo automáticamente. En cualquier caso, el sistema avisa siete días antes de llevar a cabo ningún mantenimiento. El sistema también comunica cuándo se ha iniciado el mantenimiento y cuándo ha finalizado correctamente.

Las notificaciones sobre el próximo mantenimiento programado se pueden:

  • Enviar por correo electrónico a una dirección concreta
  • Enviar por correo electrónico a un rol de Azure Resource Manager
  • Enviar en un mensaje de texto (SMS) a dispositivos móviles
  • Insertar como una notificación en una aplicación de Azure
  • Entregar como un mensaje de voz

A la hora de especificar las preferencias de la programación de mantenimiento, puede elegir un día de la semana y una ventana de tiempo. Si no lo hace, el sistema elige horas entre las 23:00 y las 7:00 de la hora de la región del servidor. Puede definir diferentes programaciones para cada servidor flexible de la suscripción de Azure.

Importante

Normalmente, hay al menos 30 días entre los eventos de mantenimiento programado correctos de un servidor.

Sin embargo, en el caso de una actualización de emergencia crítica, como una vulnerabilidad grave, la ventana de notificación podría ser inferior a siete días. La actualización crítica se puede aplicar al servidor aunque se haya realizado un mantenimiento programado correcto durante los últimos 30 días.

Se puede actualizar la configuración de programación en cualquier momento. Si hay un mantenimiento programado para el servidor flexible y se actualizan las preferencias de programación, el lanzamiento actual continuará según lo programado, y el cambio de configuración de programación se aplicará cuando finalice correctamente para el siguiente mantenimiento programado.

Puede definir una programación administrada por el sistema o una programación personalizada para cada servidor flexible de la suscripción a Azure.

  • Con la programación personalizada, puede elegir el día de la semana y una ventana de una hora para la ventana de mantenimiento del servidor.
  • Con la programación administrada por el sistema, el sistema elegirá cualquier ventana de una hora entre las 23:00 y las 7:00 según la hora de la región del servidor.

Importante

Anteriormente, se mantuvo una brecha de implementación de 7 días entre las programaciones administradas por el sistema y administradas por el sistema. Debido a las demandas de mantenimiento en constante evolución y a la introducción de la característica de reprogramación de mantenimiento (versión preliminar pública), ya no podemos garantizar esta brecha de 7 días.

En raras ocasiones, el sistema puede cancelar el evento de mantenimiento, o bien este puede no completarse correctamente. Si se produce un error en la actualización, esta se revertirá y se restaurará la versión anterior de los archivos binarios. En estos escenarios de actualización con errores, es posible que el servidor se reinicie durante la ventana de mantenimiento. Si se produce un error en la actualización o se cancela, el sistema creará una notificación sobre el evento de mantenimiento con errores o cancelado, respectivamente, para notificárselo. El siguiente intento de mantenimiento se programará según la configuración de programación actual, y el usuario recibirá una notificación al respecto con cinco días de antelación.

Mantenimiento con tiempo de inactividad casi nulo (versión preliminar pública)

La característica "Mantenimiento de tiempo de inactividad casi nula" del servidor flexible de Azure Database for MySQL es un desarrollo innovador para servidores habilitados HA (alta disponibilidad). Esta característica está diseñada para reducir considerablemente el tiempo de inactividad del mantenimiento, lo que garantiza que, en la mayoría de los casos, se espera que el tiempo de inactividad de mantenimiento esté comprendido entre 40 y 60 segundos. Esta funcionalidad es fundamental para las empresas que exigen alta disponibilidad y una interrupción mínima en sus operaciones de base de datos.

Expectativas precisas de tiempo de inactividad

  • Duración del tiempo de inactividad: en la mayoría de los casos, el tiempo de inactividad durante el mantenimiento oscila entre 10 y 30 segundos.
  • Consideraciones adicionales: después de un evento de conmutación por error, hay un período de tiempo de vida (TTL) de DNS inherente de aproximadamente 30 segundos. Este período no se controla directamente mediante el proceso de mantenimiento, pero es una parte estándar del comportamiento de DNS. Por lo tanto, desde la perspectiva de un cliente, el tiempo de inactividad total experimentado durante el mantenimiento podría estar en el intervalo de 40 a 60 segundos.

Limitaciones y requisitos previos

Para lograr el rendimiento óptimo prometido por esta característica, se deben tener en cuenta ciertas condiciones y limitaciones:

  • Claves principales de todas las tablas: asegurarse de que cada tabla tiene una clave principal es fundamental. La falta de claves principales puede aumentar significativamente el retraso de replicación, lo que afecta al tiempo de inactividad.
  • Carga de trabajo baja durante los tiempos de mantenimiento: los períodos de mantenimiento deben coincidir con los tiempos de baja carga de trabajo en el servidor para asegurarse de que el tiempo de inactividad sigue siendo mínimo. Le recomendamos que use la característica ventana de mantenimiento personalizada para programar el mantenimiento durante las horas de poca actividad.

Reprogramación del mantenimiento (versión preliminar pública)

Importante

La característica de reprogramación de mantenimiento está actualmente en versión preliminar. Está sujeto a limitaciones y desarrollo continuo. Valoramos sus comentarios para ayudar a mejorar esta característica. Tenga en cuenta que esta característica no está disponible para los servidores que usan la SKU ampliable.

La característica dereprogramación de mantenimiento le concede un mayor control sobre el tiempo de las actividades de mantenimiento en la instancia del servidor flexible de Azure Database for MySQL. Después de recibir una notificación de mantenimiento, puede volver a programarla a un momento más conveniente, independientemente de si se ha administrado el sistema o el personalizado.

Volver a programar parámetros y notificaciones

La reprogramación no se limita a las ranuras de tiempo fijas; depende de los tiempos más antiguos y más recientes permitidos en el ciclo de mantenimiento actual. Tras la reprogramación, se enviará una notificación para confirmar los cambios siguiendo las directivas de notificación estándar.

Consideraciones y limitaciones

Tenga en cuenta lo siguiente al usar esta característica:

  • Restricciones de demanda: es posible que se cancele el mantenimiento programado debido a un gran número de actividades de mantenimiento que se producen simultáneamente en la misma región.
  • Período de bloqueo: la reprogramación no está disponible 15 minutos antes del tiempo de mantenimiento programado inicialmente para mantener la confiabilidad del servicio.

No hay ninguna limitación en cuanto al número de veces que se puede volver a programar un mantenimiento; siempre y cuando este no haya entrado en estado "En preparación", puede programarlo para otro momento.

Nota:

Se recomienda supervisar las notificaciones estrechamente durante la fase de versión preliminar para dar cabida a posibles ajustes.

Use esta característica para evitar interrupciones durante las operaciones críticas de la base de datos. Animamos sus comentarios a medida que seguimos desarrollando esta funcionalidad.

Pasos siguientes