Maintenance planifiée dans Azure Database pour MySQL : Serveur flexible

  • Article

S’APPLIQUE À : Azure Database pour MySQL - Serveur flexible

Azure Database pour MySQL : Serveur flexible effectue une maintenance périodique pour garantir la sécurité, la stabilité et la mise à jour de votre base de données managée. Au cours de la maintenance, le serveur récupère des fonctionnalités, des mises à jour et des correctifs.

Important

Évitez toutes les opérations du serveur (modifications, modifications de la configuration, démarrage/arrêt du serveur) pendant la maintenance du serveur flexible Azure Database pour MySQL. Ces activités peuvent entraîner des résultats imprévisibles, affectant la stabilité et les performances du serveur. Attendez que la maintenance s’achève avant d’effectuer des opérations du serveur.

Sélectionner une fenêtre de maintenance

Vous pouvez planifier la maintenance pour un jour spécifique de la semaine et d’une fenêtre de temps dans ce jour. Vous pouvez aussi laisser le système choisir un jour et une heure pour vous automatiquement. Dans les deux cas, le système vous alerte sept jours avant d’exécuter une opération de maintenance. Le système indique également quand la maintenance est démarrée et quand elle est terminée.

Les notifications relatives à la maintenance planifiée à venir peuvent être :

  • Envoyées par e-mail à une adresse spécifique.
  • Envoyées par e-mail à un rôle Azure Resource Manager.
  • Envoyées dans un message texte (SMS) à des appareils mobiles.
  • Envoyées en tant que notification à une application Azure.
  • Remises sous forme de message vocal.

Quand vous spécifiez des préférences de planification de la maintenance, vous pouvez choisir un jour de la semaine et une fenêtre de temps. Si vous n’en spécifiez pas, le système choisit des heures entre 23 h 00 et 7 h dans le fuseau horaire de la région de votre serveur. Vous pouvez définir différentes planifications pour chaque serveur flexible dans votre abonnement Azure.

Important

Normalement, il faut compter au moins 30 jours entre les événements de maintenance planifiés réussis pour un serveur.

Toutefois, dans le cas d’une mise à jour critique urgente comme une vulnérabilité grave, la fenêtre de notification peut être inférieure à sept jours. La mise à jour critique peut être appliquée à votre serveur même si une maintenance planifiée réussie a été effectuée au cours des 30 derniers jours.

Vous pouvez mettre à jour les paramètres de planification à tout moment. Si une maintenance est planifiée pour votre serveur flexible et que vous mettez à jour les préférences de planification, le déploiement actuel va être effectué comme prévu et la modification des paramètres de planification prendra effet dès la fin de l’opération pour la maintenance planifiée suivante.

Vous pouvez définir une planification gérée par le système ou une planification personnalisée pour chaque serveur flexible dans votre abonnement Azure.

  • Avec une planification personnalisée, vous pouvez spécifier votre fenêtre de maintenance pour le serveur en sélectionnant le jour de la semaine et une fenêtre d’une heure.
  • Avec la planification gérée par le système, le système choisit une fenêtre d’une heure comprise entre 23h et 7h dans le fuseau horaire de la région de votre serveur.

Important

Auparavant, un écart de déploiement de 7 jours entre les planifications gérées par le système et les planifications gérées sur mesure était maintenu. En raison de l’évolution des demandes de maintenance et de l’introduction de la fonctionnalité de replanification de maintenance (préversion publique), nous ne pouvons plus garantir cet intervalle de 7 jours.

Dans de rares cas, l’événement de maintenance peut être annulé par le système ou ne peut pas se terminer correctement. Si la mise à jour échoue, la mise à jour est annulée et la version précédente des fichiers binaires est restaurée. Dans ces scénarios d’échec de la mise à jour, il est néanmoins possible que le serveur redémarre pendant la fenêtre de maintenance. Si la mise à jour a été annulée ou a échoué, le système crée une notification concernant l’événement de maintenance annulée ou en échec qui vous en avertit. La tentative suivante d’effectuer l’opération de maintenance sera planifiée en fonction de vos paramètres de planification actuels et vous recevrez une notification cinq jours à l’avance.

Maintenance avec temps d’arrêt quasi nul (préversion publique)

La fonctionnalité « Maintenance avec temps d’arrêt quasi nul » du serveur flexible Azure Database pour MySQL est un développement révolutionnaire pour les serveurs HA (à haute disponibilité). Cette fonctionnalité est conçue pour réduire considérablement les temps d’arrêt liés à la maintenance, de sorte que dans la plupart des cas, ceux-ci ne dépassent pas 40 à 60 secondes. Cette fonctionnalité est essentielle pour les entreprises qui demandent une haute disponibilité et une interruption minimale dans leurs opérations de base de données.

Attentes précises en matière de temps d’arrêt

  • Durée du temps d’arrêt : dans la plupart des cas, le temps d’arrêt pendant la maintenance varie de 10 à 30 secondes.
  • Considérations supplémentaires : Après un événement de basculement, il existe une période de durée de vie (TTL) DNS inhérente d’environ 30 secondes. Cette période n’est pas directement contrôlée par le processus de maintenance, mais elle fait partie intégrante du comportement des DNS. Ainsi, du point de vue d’un client, le temps d’arrêt total rencontré pendant la maintenance peut être compris entre 40 et 60 secondes.

Limitations et conditions préalables

Pour obtenir les performances optimales promises par cette fonctionnalité, certaines conditions et limitations doivent être notées :

  • Clés primaires dans toutes les tables : s’assurer que chaque table a une clé primaire est essentiel. L’absence de clés primaires peut augmenter considérablement le décalage de la réplication, ce qui a un impact sur le temps d’arrêt.
  • Faible charge de travail pendant les périodes de maintenance : les périodes de maintenance doivent coïncider avec les heures de faible charge de travail sur le serveur pour garantir que le temps d’arrêt reste minimal. Nous vous encourageons à utiliser la fonctionnalité de fenêtre de maintenance personnalisée pour planifier la maintenance pendant les heures creuses.

Replanification de la maintenance (préversion publique)

Important

La fonctionnalité de replanification de la maintenance est actuellement en préversion. Elle est soumise à des limitations et à un développement constant. Nous apprécions vos commentaires pour nous permettre d’améliorer cette fonctionnalité. Veuillez noter que cette fonctionnalité n’est pas disponible pour des serveurs utilisant la référence SKU burstable.

La fonctionnalité de replanification de maintenance vous permet de mieux contrôler le calendrier des activités de maintenance sur votre instance de serveur flexible Azure Database pour MySQL. Après avoir reçu une notification de maintenance, vous pouvez la replanifier à une heure plus pratique, qu’elle ait été gérée par le système ou de manière personnalisée.

Notifications et paramètres de replanification

La replanification n’est pas limitée à des créneaux horaires fixes; elle dépend des heures autorisées les plus anciennes et les plus récentes dans le cycle de maintenance actuel. Lors de la replanification, une notification est envoyée pour confirmer les modifications, qui suit les stratégies de notification standard.

Observations et limitations

Tenez compte des éléments suivants lors de l’utilisation de cette fonctionnalité :

  • Contraintes de demande : il est possible que votre maintenance replanifiée soit annulée en raison d’un nombre élevé d’activités de maintenance qui se produisent simultanément dans la même région.
  • Période de verrouillage : la replanification n’est pas disponible 15 minutes avant l’heure de maintenance initialement planifiée afin de maintenir la fiabilité du service.

Il n’existe pas de limitation quant au nombre de fois où une maintenance peut être replanifiée : tant que la maintenance n’est pas passée à l’état « En préparation », vous pouvez toujours replanifier votre maintenance à un autre moment.

Remarque

Nous vous recommandons de surveiller étroitement les notifications pendant la phase de préversion pour tenir compte d’ajustements éventuels.

Utilisez cette fonctionnalité pour éviter des interruptions pendant des opérations critiques de bases de données. Nous vous encourageons à nous faire part de vos commentaires à mesure que nous poursuivons le développement de cette fonctionnalité.

Étapes suivantes