Compartir a través de

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.

Ciclo de mantenimiento

Mantenimiento de rutina

Nuestro ciclo de mantenimiento estándar se programa con menos frecuencia que cada 30 días. Este período nos permite garantizar la estabilidad y el rendimiento del sistema a la vez que se minimiza la interrupción de los servicios.

Mantenimiento crítico

En determinados escenarios, como la necesidad de implementar correcciones de seguridad urgentes o actualizaciones críticas para mantener la disponibilidad y la integridad de los datos, el mantenimiento puede realizarse con más frecuencia. Estas excepciones se realizan para proteger los datos y garantizar el funcionamiento continuo de los servicios.

Buscar detalles de mantenimiento

Para obtener detalles específicos acerca de lo que implica cada actualización de mantenimiento, consulte nuestras notas de la versión. Estas notas proporcionan información completa sobre las actualizaciones aplicadas durante el mantenimiento, lo que le permite comprender y prepararse para cualquier cambio que afecte a su entorno.

Nota:

No todos los servidores se someten necesariamente a mantenimiento durante las actualizaciones programadas, ya sean rutinas o críticas. El equipo de Azure MySQL emplea criterios específicos para determinar qué servidores requieren mantenimiento. Este enfoque selectivo garantiza que el mantenimiento sea eficaz y esencial, adaptado a las necesidades únicas de cada entorno de servidor y minimice el tiempo de inactividad de la producción.

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.

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

A partir del 31 de agosto de 2024, Azure Database for MySQL ya no admitirá ventanas de mantenimiento personalizadas para instancias de SKU ampliables. Este cambio se debe a la necesidad de simplificar los procesos de mantenimiento, garantizar un rendimiento óptimo y nuestro análisis que indica que el número de usuarios que usan ventanas de mantenimiento personalizadas en SKU ampliables es mínima. Las instancias de SKU ampliables existentes con configuraciones de ventana de mantenimiento personalizadas no se verán afectadas; sin embargo, los usuarios no podrán modificar esta configuración de ventana de mantenimiento personalizada al avanzar.

Para los clientes que requieren ventanas de mantenimiento personalizadas, se recomienda actualizar a SKU de uso general o Crítico para la empresa para seguir usando esta característica.

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.
  • Garantías de tiempo de inactividad: si bien nos esforzamos por mantener el tiempo de inactividad por mantenimiento lo más bajo posible, no garantizamos que siempre sea inferior a 60 segundos en todas las circunstancias. Varios factores, como configuraciones de servidor específicas o cargas de trabajo elevadas, pueden provocar un tiempo de inactividad más largo. En el peor de los casos, el tiempo de inactividad podría ser similar al de un servidor independiente.

Reprogramación de mantenimiento

La característica de reprogramación de mantenimiento le concede un mayor control sobre el tiempo de las actividades de mantenimiento en la instancia de Azure Database for MySQL: servidor flexible. 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, lo que suele abarcar por norma general desde el primero al último día de la ventana de mantenimiento de la región. 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.
  • Limitación de reprogramación Si hay demasiados servidores en la misma región programados para el mantenimiento durante el mismo tiempo, es posible que se produzca un error en las solicitudes de reprogramación. Los usuarios recibirán una notificación de error si esto ocurre; se recomienda elegir un espacio de tiempo alternativo. Es poco probable que se cancele el mantenimiento reprogramado correctamente.

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.

Preguntas más frecuentes

P: ¿Por qué algunos de mis servidores recibieron notificaciones de mantenimiento mientras que otras no?

R: Las horas de inicio de mantenimiento difieren entre regiones, por lo que los servidores de diferentes regiones pueden recibir notificaciones de mantenimiento en momentos diferentes.

P: ¿Por qué algunos servidores de la misma región recibieron notificaciones de mantenimiento mientras que otros no?

R: Esto podría deberse a que los servidores que no recibieron notificaciones se crearon más recientemente y el sistema determinó que aún no requieren mantenimiento.

P: ¿Puedo cancelar el mantenimiento programado?

R: No, no se permite cancelar el mantenimiento programado. Sin embargo, puede usar la característica de reprogramación de mantenimiento para ajustar el tiempo o habilitar la característica de alta disponibilidad (HA) para minimizar el tiempo de inactividad. Como producto de base de datos de PaaS, es esencial realizar un mantenimiento oportuno para garantizar la seguridad y confiabilidad de la base de datos.

Pasos siguientes