Partager via

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

  • Article

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

Le serveur flexible Azure Database pour MySQL effectue une maintenance périodique pour garantir la sécurité, la stabilité et la mise à jour de votre base de données géré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.

Cycle de maintenance

Maintenance de routine

Notre cycle de maintenance standard est programmé au moins tous les 30 jours. Cette période nous permet d'assurer la stabilité et la performance du système tout en minimisant la perturbation de vos services.

Maintenance critique

Dans certains cas, comme la nécessité de déployer des correctifs de sécurité urgents ou des mises à jour essentielles au maintien de la disponibilité et de l'intégrité des données, la maintenance peut être effectuée plus fréquemment. Ces exceptions sont faites pour sauvegarder vos données et assurer le fonctionnement continu de vos services.

Détails concernant la localisation de la maintenance

Pour plus de détails sur le contenu de chaque mise à jour de maintenance, veuillez vous référer à nos notes de mise à jour. Ces notes fournissent des informations complètes sur les mises à jour appliquées pendant la maintenance, ce qui vous permet de comprendre et de vous préparer à tout changement ayant un impact sur votre environnement.

Remarque

Tous les serveurs ne font pas nécessairement l'objet d'une maintenance lors des mises à jour programmées, qu'il s'agisse de maintenance de routine ou de maintenance critique. L'équipe Azure MySQL utilise des critères spécifiques pour déterminer quels serveurs nécessitent une maintenance. Cette approche sélective garantit que la maintenance est à la fois efficace et essentielle, adaptée aux besoins uniques de chaque environnement de serveur, et minimise le temps d'arrêt de votre production.

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.

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

À compter du 31 août 2024, Azure Database pour MySQL ne prendra plus en charge les fenêtres de maintenance personnalisées pour les instances de référence SKU Burstable. Cette modification est due à la nécessité de simplifier les processus de maintenance et de garantir des performances optimales. De plus, notre analyse indique que le nombre d’utilisateurs se servant des fenêtres de maintenance personnalisées sur des références SKU Burstable est minimal. Les instances de référence SKU Burstable existantes avec des configurations de fenêtre de maintenance personnalisée restent inchangées. Toutefois, les utilisateurs ne pourront pas modifier ces paramètres de fenêtre de maintenance personnalisée à l’avenir.

Pour les clients nécessitant des fenêtres de maintenance personnalisées, nous vous recommandons de procéder à la mise à niveau vers des références SKU Usage général ou Critique pour l’entreprise pour continuer à utiliser cette fonctionnalité.

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.
  • Garanties quant au temps d’arrêt : nous nous efforçons de garder le temps d’arrêt pour maintenance aussi court que possible, mais nous ne garantissons pas qu’il sera toujours inférieur à 60 secondes dans toutes les circonstances. Différents facteurs, comme un charge de travail élevée ou des configurations de serveur spécifiques, peuvent entraîner un temps d’arrêt plus long. Dans le pire des scénarios, les temps d’arrêt peuvent être similaires à ceux d’un serveur autonome.

Maintenance replanifiée

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, qui s’étendent généralement du premier au dernier jour de la fenêtre de maintenance pour la région. 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.
  • Limitation de replanification Si un trop grand nombre de serveurs dans la même région sont planifiés pour la maintenance pendant la même période, les demandes de replanification peuvent échouer. Les utilisateurs recevront une notification d’erreur si cela se produit et seront invités à choisir un autre créneau horaire. La maintenance replanifiée a peu de chances d’être annulée.

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é.

Forum aux questions

Q : Pourquoi certains de mes serveurs ont-ils reçu des notifications de maintenance alors que d’autres ne les ont pas reçues ?

R : Les heures de début de maintenance diffèrent entre les régions, de sorte que des serveurs situés dans des régions différentes peuvent recevoir des notifications de maintenance à des moments différents.

Q : Pourquoi certains serveurs de la même région ont-ils reçu des notifications de maintenance alors que d’autres ne les ont pas reçues ?

R : Cela peut être dû au fait que les serveurs qui n’ont pas reçu de notifications ont été créés plus récemment et que le système a déterminé qu’ils n’ont pas encore besoin de maintenance.

Q : Puis-je refuser la maintenance planifiée ?

R : Non, la désactivation de la maintenance planifiée n’est pas autorisée. Cependant, vous pouvez utiliser la fonctionnalité de replanification de la maintenance pour ajuster la chronologie ou activer la fonctionnalité Haute disponibilité pour réduire les temps d’arrêt. Comme il s’agit d’un produit de base de données PaaS, il est essentiel d’effectuer une maintenance en temps opportun pour garantir la sécurité et la fiabilité de votre base de données.

Étapes suivantes