Planifier les événements de maintenance Azure dans Azure SQL Database et Azure SQL Managed Instance

  • Article

S’applique à : Azure SQL DatabaseAzure SQL Managed Instance

Apprenez à anticiper les événements de maintenance planifiée sur votre base de données dans Azure SQL Database et Azure SQL Managed Instance.

Qu’est-ce qu’un événement de maintenance planifiée ?

Pour assurer la sécurité, la conformité, la stabilité et les performances des services Azure SQL Database et Azure SQL Managed Instance, des mises à jour sont effectuées presque en permanence via les composants du service. Grâce à l’architecture de service moderne et robuste, ainsi qu’à des technologies novatrices telles que de la mise à jour corrective à chaud, la majorité des mises à jour sont entièrement transparentes et sans incidence en termes de disponibilité des services. Néanmoins, quelques rares types de mises à jour entraînent des interruptions de service courtes et nécessitent un traitement spécial.

Pendant les maintenances planifiées, les membres du quorum de base de données passent hors connexion l’un après l’autre. Ce comportement permet d’avoir un réplica principal chargé de répondre. Pour les bases de données Critique pour l’entreprise et Premium, au moins un réplica secondaire est également en ligne pour éviter tout temps d’arrêt du client.

Lorsque le réplica principal doit être mis hors ligne, un processus de reconfiguration se produit.

  • Pour les bases de données Critique pour l’entreprise et Premium, l’un des réplicas secondaires devient le nouveau réplica principal.
  • Pour les bases de données Usage général, Standard et De base, le réplica principal est déplacé vers un autre nœud de calcul sans état avec une capacité libre suffisante.

Que se passe-t-il pendant un événement de maintenance planifiée ?

L’événement de maintenance peut produire une ou plusieurs reconfigurations, selon la constellation des réplicas principaux et secondaires au début de l’événement de maintenance. En moyenne, il se produit 1,7 reconfiguration par événement de maintenance planifiée. Les reconfigurations se terminent généralement dans les 30 secondes. La moyenne est de huit secondes. Si elle est déjà connectée, votre application doit se reconnecter au nouveau réplica principal de votre base de données.

Si une nouvelle connexion est tentée pendant que la base de données est en cours de reconfiguration avant que le nouveau réplica principal ne soit en ligne, vous obtenez l’erreur 40613 (base de données non disponible) : Database '{databasename}' on server '{servername}' is not currently available. Please retry the connection later. Si votre base de données est en cours d’exécution, cette requête est interrompue lors d’une reconfiguration et doit être redémarrée.

Fonctionnalité de fenêtre de maintenance

La fonctionnalité de fenêtre de maintenance permet de configurer des planifications de fenêtre de maintenance prévisibles pour les bases de données Azure SQL et les instances managées SQL éligibles. Les Notifications préalables de la fenêtre de maintenance sont disponibles pour les bases de données configurées pour utiliser une fenêtre de maintenance autre que celle par défaut.

  • Pour Azure SQL Database, les fenêtres de maintenance et les notifications préalables pour les fenêtres de maintenance sont généralement disponibles.
  • Pour Azure SQL Managed Instance, les fenêtres de maintenance sont généralement disponibles, mais les notifications préalables sont une fonctionnalité d'évaluation.

Comment simuler un événement de maintenance planifiée ?

Assurez-vous que votre application cliente est résiliente aux événements de maintenance avant de la déployer en production.

Les tests réduisent le risque de défaillance des applications et contribuent à leur disponibilité pour les utilisateurs finaux. Vous pouvez tester le comportement de votre application cliente lors des événements de maintenance planifiée en testant la résilience de l'application aux défaillances via PowerShell, l'interface de ligne de commande (CLI) ou l'API REST.

Pour Azure SQL Managed Instance, examinez également la possibilité d'initier un basculement manuel. Un basculement manuel produit un comportement identique à celui d'un événement de maintenance qui met le réplica principal hors connexion.

Logique de nouvelle tentative

Toute application de production cliente qui se connecte à un service de base de données cloud doit implémenter une logique de nouvelle tentative de connexion robuste. Une logique de nouvelle tentative automatique appropriée permet de rendre les reconfigurations aussi transparentes que possible pour les utilisateurs finaux.

Alerte Service Health

Si vous souhaitez recevoir des alertes pour les problèmes de service ou les activités de maintenance planifiée, vous pouvez utiliser des alertes Service Health dans le portail Azure avec le type d’événement et les groupes d’actions appropriés. Pour plus d’informations, consultez Recevoir des alertes sur les notifications de service Azure.

Intégrité des ressources

Si votre base de données subit des échecs de connexion, examinez la fenêtre Intégrité des ressources dans le portail Azure pour connaître l’état actuel. La section Health History (Historique d’intégrité) contient le motif du temps d’arrêt pour chaque événement (le cas échéant).

Contenu connexe