Vue d’ensemble de la continuité de l’activité avec la base de données Azure SQL
S’applique à : 
Base de données Azure SQL Base de données SQL dans Fabric
Cet article fournit une vue d’ensemble des capacités de continuité d’activité et reprise d’activité de la base de données Azure SQL, en décrivant les options et les recommandations pour récupérer des événements perturbateurs qui pourraient entraîner une perte de données ou rendre votre base de données et votre application indisponibles. Découvrez la procédure à suivre lorsqu’une erreur d’un utilisateur ou d’une application affecte l’intégrité des données, lorsqu’une zone de disponibilité Azure subit une panne ou que votre application nécessite une maintenance.
Vue d’ensemble
La Continuité d’activité dans la base de données Azure SQL fait référence aux mécanismes, stratégies et procédures qui permettent à votre entreprise de continuer à fonctionner en cas de perturbation en fournissant disponibilité, haute disponibilité et récupération d’urgence.
Dans la plupart des cas, SQL Database gère les événements perturbateurs qui peuvent se produire dans un environnement cloud et préserve l’exécution de vos applications et processus métier. Toutefois, il existe certains événements perturbants où la prévention peut prendre un certain temps, comme :
- Un utilisateur supprime ou met à jour accidentellement une ligne dans une table.
- Un attaquant a réussi à supprimer des données ou à éliminer une base de données.
- Un événement catastrophique naturel neutralise un centre de données ou une zone de disponibilité ou une région.
- Une rare panne de centre de données, de zone de disponibilité ou de région causée par un changement de configuration, un bogue logiciel ou une défaillance de composant matériel.
Disponibilité
Une base de données Azure SQL est fournie avec une résilience de base et une promesse de fiabilité qui les protège contre les défaillances logicielles ou matérielles. Les sauvegardes de base de données sont automatisées pour protéger vos données contre la corruption ou la suppression accidentelle. En tant que paaS (Platform-as-a-service), le service Base de données Azure SQL fournit une disponibilité en tant que fonctionnalité hors service avec un contrat SLA de disponibilité de 99,99 %.
Haute disponibilité
Pour obtenir une haute disponibilité dans l’environnement cloud Azure, activez la redondance de zone afin que la base de données, ou le pool élastique, utilise des zones de disponibilité pour s’assurer que la résilience de la base de données, ou du pool élastique, est résiliente aux défaillances zonales. De nombreuses régions Azure fournissent des zones de disponibilité, qui sont des groupes séparés de centres de données au sein d’une région qui dispose d’une alimentation indépendante, d’un refroidissement et d’une infrastructure réseau. Les zones de disponibilité sont conçues pour fournir des services régionaux, une capacité et une haute disponibilité dans les zones restantes si une zone rencontre une panne. En activant la redondance de zone, la base de données ou le pool élastique est résiliente aux défaillances matérielles et logicielles zonales et la récupération est transparente pour les applications. Lorsque la haute disponibilité est activée, le service Base de données Azure SQL est en mesure de fournir un contrat SLA de disponibilité plus élevé de 99,995 %.
Récupération d’urgence
Pour obtenir une disponibilité et une redondance plus élevées entre les régions, vous pouvez activer les fonctionnalités de récupération d’urgence pour récupérer rapidement la base de données à partir d’une défaillance régionale catastrophique. Les options de récupération d’urgence pour une base de données Azure SQL :
- La géoréplication active vous permet de créer une base de données secondaire synchronisée accessible en lecture en permanence pour une base de données primaire.
- Les groupes de basculement, en plus d’assurer une synchronisation continue entre une base de données primaire et une base de données secondaire, vous permettent également de gérer la réplication et le basculement de certaines ou de toutes les bases de données d’un serveur logique vers un serveur logique secondaire situé dans une autre région. Les groupes de basculement fournissent des points de terminaison de l’écouteur en lecture seule et en lecture seule qui restent inchangés afin de mettre à jour les chaîne de connexion d’application après le basculement n’est pas nécessaire.
- La géorestauration vous permet de récupérer à partir d’une panne régionale en effectuant une restauration à partir de sauvegardes géorépliquées lorsque vous ne pouvez pas accéder à votre base de données dans la région primaire en créant une base de données sur n’importe quel serveur existant dans n’importe quelle région Azure.
Le tableau suivant compare les groupes de géoréplication et de basculement actifs, deux options de récupération d’urgence pour la base de données Azure SQL :
| Géoréplication active | Groupes de basculement | |
|---|---|---|
| Synchronisation de données continue entre le serveur principal et le secondaire | Oui | Oui |
| Basculement simultanément de plusieurs bases de données | Non | Oui |
| La Chaîne de connection reste inchangée après le basculement | Non | Oui |
| Prise en charge de l’échelle lecture | Oui | Oui |
| Réplicas multiples | Oui | Non |
| Peut être dans la même région que l’élément principal | Oui | Non |
Fonctionnalités garantissant la continuité d’activité
Du point de vue de la base de données, il existe quatre scénarios d’interruption potentiels. Le tableau suivant répertorie les fonctionnalités de continuité d’activité SQL Database que vous pouvez utiliser pour atténuer un scénario de perturbation potentielle d’activité :
| Scénario d’interruption d’activité | Fonctionnalité de continuité des activités |
|---|---|
| Des défaillances matérielles ou logicielles locales affectant le nœud de base de données. | Pour atténuer des défaillances matérielles et logicielles locales, SQL Database inclut une architecture de disponibilité qui garantit une récupération automatique de ces défaillances jusqu’à une disponibilité SLA de 99,99 %. |
| Une suppression ou une altération des données se produit, généralement à la suite d’un bogue d’application ou d’une erreur humaine. Ces défaillances sont spécifiques à l’application et ne peuvent généralement pas être détectées par le service de base de données. | Pour protéger votre entreprise contre la perte de données, SQL Database crée automatiquement des sauvegardes de bases de données complètes (toutes les semaines), des sauvegardes de bases de données différentielles (toutes les 12 ou 24 heures) et des sauvegardes de fichiers journaux (toutes les 5 à 10 minutes). Par défaut, les sauvegardes sont stockées dans le stockage géoredondant pendant sept jours pour tous les niveaux de service. Tous les niveaux de service, à l’exception du Support de base, prennent en charge une période de rétention des sauvegardes configurable pour la restauration à un instant dans le passé (PITR) jusqu’à 35 jours. Vous pouvez restaurer une base de données supprimée au point où sa suppression s’est produite si le serveur n’a pas été supprimé ou si vous avez configuré une conservation à long terme (LTR). |
| Une panne rare de centre de données ou de zone de disponibilité, peut-être causée par un événement d’urgence naturelle, une modification de configuration, un bogue logiciel ou une défaillance de composant matériel. | Pour atténuer la panne au niveau du centre de données ou de la zone de disponibilité, activez la redondance de zone pour la base de donnée ou le pool élastique afin d’utiliser les Zones de disponibilité Azure et de fournir une redondance entre plusieurs zones physiques au sein d’une région Azure. L’activation de la redondance de zone garantit que la base de données ou le pool élastique est résiliente aux défaillances zonales avec jusqu’à 99,995 % de contrat SLA de haute disponibilité. |
| Une panne de région rare impactant toutes les zones de disponibilité et les centres de données qui le composent, peut-être causées par un événement catastrophique naturel. | Pour atténuer une panne à l’échelle de la région, activez la récupération d’urgence à l’aide de l’une des options suivantes : - Options de synchronisation de données continues telles que les groupes de basculement (recommandé) ou la géoréplication active qui vous permettent de créer des réplicas dans une région secondaire pour le basculement. - Configuration de l’option de redondance du stockage de sauvegarde sur stockage de sauvegarde géoredondant pour utiliser la géorestauration. |
RTO et RPO
Lorsque vous élaborez votre plan de continuité d’activité, comprenez le délai maximum acceptable avant que l’application ne se rétablisse complètement après l’événement perturbateur. Le délai de récupération complète d’une application s’appelle l’objectif de délai de récupération (RTO, Recovery Time Objective). Comprenez également la période maximale de mise à jour des données récentes (intervalle de temps) que l’application peut tolérer de perdre lorsqu’elle se remet d’un événement perturbateur non planifié. La perte de données potentielle est appelée l’objectif de point de récupération (RPO, Recovery Point Objective).
Le tableau suivant compare l’objectif de point de récupération (RPO) et l’objectif de délai de récupération (RTO) de chaque option de continuité d’activité :
| Options de continuité d’activité | RTO (temps d’arrêt) | RPO (perte de données) |
|---|---|---|
| Haute disponibilité (utilisation de la redondance de zone) |
En général, moins de 30 secondes | 0 |
| Récupération d’urgence (utilisation de groupes de basculement avec une stratégie de basculement gérée par le client ou une géoréplication active) |
En général, moins de 60 secondes | Égal ou supérieur à 0 (Dépend des modifications de données avant l’événement perturbant qui n’a pas été répliqué) |
| Récupération d’urgence (en utilisant la géo-restauration) |
En général, minutes ou heures | En général, minutes ou heures |
Listes de contrôle de continuité d’activité
Pour obtenir des recommandations prescriptives pour optimiser la disponibilité et obtenir une continuité d’activité plus élevée, reportez-vous aux points suivants :
- Liste de contrôle de disponibilité
- Liste de contrôle de haute disponibilité
- Liste de contrôle de la récupération d’urgence
Préparer une panne régionale
Quelles que soient les fonctionnalités de continuité d’activité que vous utilisez, vous devez préparer la base de données secondaire dans une autre région. Si vous ne vous préparez pas correctement, la mise en ligne de vos applications après un basculement ou une récupération prend plus de temps et nécessite probablement également un dépannage, ce qui peut retarder le RTO. Suivez la liste de contrôle pour préparer le secondaire pour une panne régionale.
Restaurer une base de données dans la même région Azure
Vous pouvez utiliser des sauvegardes de base de données automatiques pour restaurer une base de données à un point dans le temps passé. Vous pouvez ainsi récupérer suite à des altérations de données dues à des erreurs humaines. La restauration à un instant dans le passé (PITR) permet de créer une base de données sur le même serveur qui représente l’état des données avant le dommage. Pour la plupart des bases de données, les opérations de restauration durent moins de 12 heures. La récupération d’une base de données très volumineuse ou très active peut prendre plus de temps. Pour plus d’informations, consultez Temps de récupération de la base de données.
Si la période de rétention maximale de la base de données prise en charge associée à la restauration à un instant dans le passé n’est pas suffisante pour votre application, vous pouvez la rallonger en configurant une stratégie de conservation à long terme (LTR) pour la ou les bases de données. Pour plus d’informations, consultez Conservation des sauvegardes à long terme.
Mettre à niveau une application avec un temps d’arrêt minimal
Parfois, une application doit être déconnectée en raison d’une maintenance, par exemple, une mise à niveau. Gestion des mises à niveau des applications explique comment utiliser la géo-réplication active pour activer les mises à niveau propagées de votre application cloud afin de réduire le temps d’arrêt pendant les mises à niveau et de fournir un chemin de récupération en cas de problème.
Réduire les coûts avec un réplica en attente
Si votre réplica secondaire n'est utilisé que pour la récupération d'urgence (DR) et n'a pas de charge de travail en lecture ou en écriture, vous pouvez réduire les coûts de licence en désignant la base de données comme base de données en attente lorsque vous configurez une nouvelle relation de géoréplication active.
Pour en savoir plus, reportez-vous au réplica en attente sans licence.
Étapes suivantes
Pour des considérations sur la conception d’application, consultez les articles Concevoir une application pour la récupération d’urgence dans le cloud et Stratégies de récupération d’urgence avec un pool élastique.
Évaluez l’Aide sur la récupération d'urgence Azure SQL Database et la liste de vérification de haute disponibilité et récupération d’urgence Azure SQL Database.