Aide sur la récupération d’urgence - Base de données Azure SQL
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 de continuité d'activité clés en main que vous pouvez utiliser pour une récupération d'urgence 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 :
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.
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 :
Notification par e-mail
Si vous avez configuré des alertes, une notification par e-mail est envoyée de
azure-noreply@microsoft.comlorsqu’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.Métrique de disponibilité
Vous pouvez surveiller et configurer les alertes de la métrique de disponibilité de la base de données Azure SQL dans le 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 pas En 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 la base de données secondaires correspondent à celles qui ont été configurées sur le serveur et la base de données primaires. Pour plus d’informations, consultez Comment : Configurer les paramètres du pare-feu.
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 la sécurité 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 l'audit est configuré sur le serveur principal, il doit être identique sur le serveur secondaire. Pour plus d’informations, consultez également Audit.
Contenu connexe
Pour en savoir plus, consultez :
- Scénarios de continuité.
- Sauvegardes automatisées
- Restaurez une base de données à partir des sauvegardes initiées par le service.
- Pour plus d’informations sur les options de récupération plus rapides, consultez Géoréplication active et groupes de basculement.
- Évaluez le guide de récupération d'urgence et la Liste de contrôle haute disponibilité et récupération d'urgence.