Aide sur la récupération d’urgence - Base de données Azure SQL

  • Article

S’applique à Azure SQL Database

La base de données Azure SQL offre une garantie de haute disponibilité d’au moins 99,99 % pour prendre en charge une grande variété d’applications, y compris les applications critiques, qui doivent toujours être disponibles. La base de données Azure SQL dispose également de fonctionnalités clés en main de continuité d’activité qui vous permettent d’effectuer une récupération d’urgence rapide en cas de panne régionale. Cet article contient des informations précieuses à consulter avant le déploiement de l’application.

Bien que nous nous efforcions continuellement de fournir une haute disponibilité, il arrive parfois que le service de base de données Azure SQL subisse des pannes qui provoquent l’indisponibilité de votre base de données et affectent donc votre application. Lorsque notre analyse du service détecte des problèmes qui provoquent des erreurs de connectivité généralisées, des défaillances ou des problèmes de performances, le service déclare automatiquement une panne pour vous tenir informé.

Interruption de service

En cas de panne du service de la base de données Azure SQL, vous trouverez des détails supplémentaires liés à la panne aux endroits suivants :

  • Bannière Portail Azure

    Si votre abonnement est identifié comme concerné, il y a une alerte de panne d’un problème de service dans votre portail Azure Notifications :

    A screenshot from the Azure portal of a notification of an Azure SQL Database service issue.

  • Aide + support ou Support + résolution des problèmes

    Lorsque vous créez un ticket de support à partir de Aide + support ou Support + dépannage, vous trouvez des informations sur les problèmes qui ont un impact sur vos ressources. Sélectionnez Afficher les détails sur la panne pour plus d’informations et un résumé de l’impact. Il y a également une alerte dans la page Nouvelle demande de support.

    A screenshot of the Help+Support page showing a notification of an active service health issue..

  • Service de contrôle d’intégrité

    La page Service Health du Portail Azure contient des informations sur l’état du centre de données Azure à l’échelle mondiale. Recherchez « Intégrité des services » dans la barre de recherche du Portail Azure, puis affichez Problèmes de service dans la catégorie Événements actifs. Vous pouvez également afficher l’intégrité des ressources individuelles dans la page Intégrité des ressources de n’importe quelle ressource sous le menu Aide. Voici un exemple de capture d’écran de la page Intégrité des services, avec des informations sur un problème de service actif en Asie Sud-Est :

    A screenshot of the Azure portal Service Health page during a service issue in Southeast Asia, showing the Issue and a map of affected resources.

  • Notification par e-mail

    Si vous avez configuré des alertes, une notification par e-mail est envoyée de azure-noreply@microsoft.com lorsqu’une panne de service a un impact sur votre abonnement et vos ressources. Le corps de l’e-mail commence généralement par « L’alerte du journal d’activité ... a été déclenchée par un problème de service pour l’abonnement Azure... ». Pour plus d’informations sur les alertes d’intégrité du service, consultez Recevoir des alertes de journal d’activité sur les notifications de service Azure à l’aide du Portail Azure.

Quand lancer la récupération d’urgence pendant une panne

En cas de panne de service impactant les ressources de l’application, envisagez les actions suivantes :

  • Les équipes Azure mettent tous les efforts en œuvre pour restaurer le service aussi rapidement que possible, mais cela peut parfois prendre plusieurs heures. Si votre application peut tolérer des temps d’arrêt importants, vous pouvez simplement attendre que le service soit rétabli. Dans ce cas, aucune action n’est requise de votre part. Affichez l’intégrité des ressources individuelles dans la page Intégrité des ressources de n’importe quelle ressource sous le menu Aide. Reportez-vous à la page Intégrité des ressources pour les mises à jour et les informations les plus récentes concernant une panne. Une fois le service rétabli dans la région, la disponibilité de votre application est restaurée.

  • La récupération vers une autre région Azure peut nécessiter la modification des chaînes de connexion d’application ou l’utilisation de la redirection DNS et peut entraîner une perte de données permanente. Par conséquent, la récupération d’urgence ne doit être effectuée que lorsque la durée de panne approche de l’objectif de temps de récupération (RTO) de votre application. Lorsque l’application est déployée en production, vous devez effectuer une analyse régulière de l’intégrité de l’application et affirmer que la récupération est justifiée uniquement en cas d’échec de connectivité prolongé entre la couche Application et la base de données. En fonction de la tolérance de votre application aux temps d’arrêt et de la responsabilité éventuelle de l’entreprise, vous pouvez décider si vous souhaitez attendre que le service soit récupéré ou lancer la récupération d’urgence vous-même.

Conseils sur la récupération après panne

Si la panne de la base de données Azure SQL dans une région n’a pas été atténuée pendant une période prolongée et affecte le contrat de niveau de service (contrat SLA) de votre application, envisager les étapes suivantes :

Basculement (aucune perte de données) vers un serveur secondaire géorépliqué

Si les groupes de géoréplication active ou de basculement automatique sont activés, vérifiez si l’état des ressources de base de données primaire et secondaire est En ligne dans le Portail Azure. Si c’est le cas, le plan de données pour les bases de données primaire et secondaire est sain. Lancez un basculement de groupes de géoréplication active ou de basculement vers la région secondaire à l’aide du Portail Azure, T-SQL, PowerShell ou Azure CLI.

Remarque

Un basculement nécessite une synchronisation complète des données avant de changer de rôle et n’entraîne pas de perte de données. Selon le type de panne de service, il n’existe aucune garantie que le basculement sans perte de données aboutira, mais il vaut la peine d’essayer comme première option de récupération.

Utilisez les liens suivants pour initier un basculement :

Technology Méthode Étapes
Géo-réplication active PowerShell Basculement vers la géoréplication secondaire via PowerShell
T-SQL Basculement vers la géoréplication secondaire via T-SQL
Groupes de basculement Azure CLI Basculement vers un serveur secondaire via Azure CLI
Portail Azure Basculement vers un serveur secondaire via le Portail Azure
PowerShell Basculement vers un serveur secondaire via PowerShell

Basculement forcé (perte de données potentiel) vers un serveur secondaire géorépliqué

Si le basculement ne se termine pas correctement et rencontre des erreurs ou si l’état de la base de données primaire n’est pasEn ligne, envisagez soigneusement un basculement forcé avec une perte de données potentielle dans la région secondaire.

Utilisez les liens suivants pour initier un basculement forcé :

Technology Méthode Étapes
Géo-réplication active Azure CLI Basculement forcé vers la géoréplication secondaire à l’aide de Azure CLI
Portail Azure Basculement forcé vers la géoréplication secondaire à l’aide du portail Azure
PowerShell Basculement forcé vers la géoréplication secondaire à l’aide de PowerShell
T-SQL Basculement forcé vers la géoréplication secondaire à l’aide de T-SQL
groupes de basculement Portail Azure Basculement forcé vers un serveur secondaire à l’aide du Portail Azure, mais sélectionnez Basculement forcé.
Azure CLI Basculement forcé vers un serveur secondaire à l’aide d’Azure CLI mais utilisez --allow-data-loss
PowerShell Basculement forcé vers un serveur secondaire à l’aide de PowerShell mais utilisez -AllowDataLoss

La géorestauration

Si vous n’avez pas activé la géoréplication active ou les groupes de basculement, vous pouvez utiliser la géorestauration en dernier recours pour récupérer après une panne. La géo-restauration utilise des sauvegardes géo-répliquées comme source. Vous pouvez restaurer une base de données sur n’importe quel serveur logique dans n’importe quelle région Azure à partir de la dernière sauvegarde géo-répliquée. Vous pouvez demander une géo-restauration même si une panne a rendu la base de données ou la région entière inaccessibles.

Pour plus d’informations sur les géorestaurations à l’aide d’Azure CLI, le Portail Azure, PowerShell ou l’API REST, consultez géorestauration de base de données Azure SQL.

Configurer votre base de données après récupération

Si vous utilisez le basculement géographique ou la géorestauration pour récupérer après une panne, vous devez vous assurer que la connectivité à la nouvelle base de données est correctement configurée pour permettre à l’application de reprendre un fonctionnement normal. Voici une liste de contrôle de tâches pour vous aider à remettre votre base de données restaurée en service.

Important

Il est recommandé d’effectuer des exercices périodiques de votre stratégie de récupération d’urgence pour vérifier la tolérance de l’application, ainsi que tous les aspects opérationnels de la procédure de récupération. Les autres couches de votre infrastructure d’application peuvent nécessiter une reconfiguration. Pour plus d’informations sur les étapes d’architecture résiliente, consultez la liste de vérification de haute disponibilité et récupération d’urgence Azure SQL Database.

Mettre à jour les chaînes de connexion

  • Si vous utilisez la géoréplication active ou la géorestauration, vous devez vous assurer que la connectivité aux nouvelles bases de données est correctement configurée pour permettre à l’application de reprendre un fonctionnement normal. Comme votre base de données restaurée se trouve sur un autre serveur, vous devez mettre à jour la chaîne de connexion de votre application de sorte qu’elle pointe vers celui-ci. Pour plus d’informations sur la modification des chaînes de connexion, consultez le langage de développement approprié pour votre bibliothèque de connectivité.
  • Si vous utilisez des groupes de basculement pour récupérer après une panne et utiliser des écouteurs en lecture-écriture et en lecture seule dans les chaînes de connexion de votre application, aucune autre action n’est nécessaire, car les connexions sont automatiquement dirigées vers le nouveau serveur principal.

Configurer les règles de pare-feu

Vous devez vous assurer que les règles de pare-feu configurées sur le serveur et sur la base de données correspondent à celles du serveur principal et de la base de données primaire. Pour plus d’informations, consultez Procédure : Configurer des paramètres du pare-feu (Azure SQL Database)

Configurer les identifiants de connexion et les utilisateurs de la base de données

Créez les connexions d’accès qui doivent être présentes dans la base de données master sur le nouveau serveur principal, puis vérifiez que ces connexions disposent des autorisations appropriées dans la base de données master, le cas échéant. Pour plus d’informations, consultez Sécurité Azure SQL Database après la récupération d’urgence.

Configurer les alertes de télémétrie

Vous devez vous assurer que vos paramètres de règles d’alerte existants sont mis à jour de manière à mapper à la nouvelle base de données primaires et à l’autre serveur. Pour en savoir plus, voir Réception de notifications d’alerte et Suivi de l’intégrité du service.

Activer la fonction d’audit

Si la fonction d’audit doit accéder à votre base de données, vous devez l’activer après la restauration de la base de données. Pour plus d’informations, consultez Audit Azure SQL pour Azure SQL Database.

Étapes suivantes