Partager via

Fiabilité dans Azure SQL Database

Azure SQL Database est un moteur de base de données PaaS (Platform as a Service) complètement managé qui prend en charge la plupart des fonctions de gestion de base de données telles que la mise à niveau, la mise à jour corrective, les sauvegardes et la surveillance sans intervention de l’utilisateur.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Azure SQL Database résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il décrit également comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes, comment gérer la maintenance du service et met en évidence certaines informations clés sur le contrat de niveau de service Azure SQL Database (SLA).

Recommandations concernant le déploiement de production

Pour en savoir plus sur le déploiement d’Azure SQL Database pour prendre en charge les exigences de fiabilité de votre solution et sur la façon dont la fiabilité affecte d’autres aspects de votre architecture, consultez les meilleures pratiques d’architecture pour Azure SQL Database dans Azure Well-Architected Framework.

Vue d’ensemble de l’architecture de fiabilité

SQL Database s’exécute sur le dernier moteur de base de données SQL Server stable du système d’exploitation Windows, y compris tous les correctifs applicables.

SQL Database obtient la redondance en stockant trois copies de vos données dans un seul centre de données de la région primaire par défaut. Cette approche protège vos données si une défaillance localisée se produit, telle qu’une défaillance réseau à petite échelle ou une panne d’alimentation, ainsi que pendant les événements suivants :

  • Opérations de gestion initiées par le client qui entraînent un bref temps d’arrêt

  • Opérations de maintenance de service

  • Problèmes et pannes de centre de données, où le centre de données comporte les composants suivants :

    • Racks où les machines qui alimentent votre service fonctionnent

    • Machines physiques qui hébergent la machine virtuelle qui exécute le moteur SQL Database

  • Autres problèmes liés au moteur SQL Database

  • Autres pannes localisées non planifiées potentielles

SQL Database utilise Azure Service Fabric pour gérer la réplication de votre base de données.

La redondance est implémentée de différentes manières pour différents niveaux de service de SQL Database. Pour plus d’informations, consultez Disponibilité par le biais de la redondance - SQL Database.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

SQL Database gère automatiquement les tâches de maintenance critiques, telles que la mise à jour corrective, les sauvegardes, Windows et les mises à niveau du moteur SQL Database. Il gère également automatiquement les événements non planifiés tels que le matériel sous-jacent, les logiciels ou les défaillances réseau. SQL Database est conçu pour récupérer rapidement des défaillances critiques, ce qui garantit que vos données sont toujours disponibles. La plupart des utilisateurs ne remarquent pas que les mises à niveau sont effectuées en continu.

Lorsqu’une base de données est corrigée ou bascule, le temps d’arrêt n’est pas perturbant si vous utilisez une logique de nouvelle tentative dans votre application.

Vous pouvez tester la résilience de votre application aux erreurs temporaires en suivant les instructions de la section Test de résilience aux erreurs de l’application.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Vous pouvez créer une base de données unique ou un pool élastique redondant interzone. La redondance de zone garantit que votre base de données est résiliente à un grand ensemble d’échecs, y compris les pannes catastrophiques du centre de données, sans aucune modification de la logique d’application.

Pour le niveau de service Usage général, la redondance de zone garantit que les composants de calcul sans état et les composants de stockage de données avec état de SQL Database sont résilients à une panne de zone de disponibilité.

Pour les niveaux de service Premium, Critique pour l’entreprise et Hyperscale, la redondance de zone place les réplicas de votre base de données SQL sur plusieurs zones de disponibilité Azure dans votre région primaire. Pour éliminer un point de défaillance unique (SPOF), l’anneau de contrôle est également dupliqué sur plusieurs zones de disponibilité.

Pour afficher des informations sur la prise en charge des zones de disponibilité pour d’autres niveaux de service, veillez à sélectionner le niveau de service approprié au début de cette page.

Spécifications

Les niveaux de service De base et Standard ne prennent pas en charge la redondance de zone.

La redondance de zone est disponible pour les bases de données des niveaux de service Critique pour l’entreprise, Usage général et Hyperscale du modèle d’achat vCore, et uniquement le niveau de service Premium du modèle d’achat DTU.

Pour le niveau de service Usage général :

Pour les niveaux de service Premium et Critique pour l’entreprise :

Pour le niveau de service Hyperscale :

Pour afficher des informations sur la prise en charge des zones de disponibilité pour d’autres niveaux de service, veillez à sélectionner le niveau de service approprié au début de cette page.

Considérations

  • Latence: Les bases de données redondantes interzone ont des réplicas dans des centres de données distincts. La latence réseau ajoutée peut augmenter le temps de validation des transactions et affecter potentiellement les performances de certaines charges de travail OLTP (Online Transaction Processing). La plupart des applications ne sont pas sensibles à cette latence supplémentaire.

  • master base de données : lorsqu’une base de données avec une configuration redondante interzone est créée sur un serveur logique, la master base de données associée au serveur est également automatiquement rendue redondante interzone. Pour plus d’informations sur la façon de vérifier si votre master base de données est redondante interzone, consultez disponibilité redondante interzone de base de données.

Pour afficher des informations sur la prise en charge des zones de disponibilité pour d’autres niveaux de service, veillez à sélectionner le niveau de service approprié au début de cette page.

Coûts

Pour le niveau de service Général, des frais supplémentaires sont appliqués pour activer la redondance de zone pour la base de données SQL. Pour plus d’informations, consultez Tarification - SQL Database.

Les niveaux de service Premium et Critique pour l’entreprise fournissent plusieurs réplicas de votre base de données. Lorsque vous activez la redondance de zone, les réplicas sont distribués entre les zones de disponibilité. Cette distribution signifie qu’il n’existe aucun coût supplémentaire associé à l’activation de la redondance de zone sur votre base de données SQL lorsqu’elle se trouve dans le niveau de service Premium ou Critique pour l’entreprise.

Si vous activez plusieurs réplicas de votre base de données de niveau de service Hyperscale, vous pouvez activer la redondance de zone. Lorsque vous activez la redondance de zone, les réplicas sont distribués entre les zones de disponibilité. Cette distribution signifie qu’il n’existe aucun coût supplémentaire associé à l’activation de la redondance de zone sur votre base de données SQL lorsqu’elle se trouve dans le niveau de service Hyperscale, en supposant que vous avez plusieurs réplicas.

Pour afficher des informations sur la prise en charge des zones de disponibilité pour d’autres niveaux de service, veillez à sélectionner le niveau de service approprié au début de cette page.

Configurez la prise en charge des zones de disponibilité

Pour les niveaux de service Usage général, Premium et Critique pour l’entreprise :

  • Nouvelles ressources : Vous pouvez configurer une base de données de manière à ce qu’elle soit redondante interzone lorsque vous la créez. Pour plus d’informations, consultez Démarrage rapide : Créer une base de données unique - SQL Database.

  • Ressources existantes : Vous pouvez reconfigurer une base de données existante pour qu’elle soit redondante interzone. Pour plus d’informations, consultez Activer la redondance de zone - SQL Database.

    Toutes les opérations de mise à l’échelle des bases de données SQL, notamment l’activation de la redondance de zone, sont des opérations en ligne et nécessitent un temps d’arrêt minimal. Pour plus d’informations, consultez Mettre à l’échelle de façon dynamique les ressources de base de données avec un temps d’arrêt minimal.

  • Désactivez la redondance de zone : Vous pouvez désactiver la redondance de zone. Ce processus est une opération en ligne qui ressemble à une mise à niveau régulière de l’objectif des niveaux de service. À la fin du processus, la base de données est migrée d’un anneau redondant interzone vers un anneau à zone unique.

Pour le niveau de service Hyperscale :

  • Nouvelles ressources : Pour les bases de données Hyperscale et les pools élastiques, la redondance de zone doit être configurée lors de la création de la base de données. Pour plus d’informations, consultez Créer une base de données Hyperscale redondante interzone.

  • Migration ou désactivation de la redondance de zone : Pour activer ou désactiver la redondance de zone sur une base de données Hyperscale ou un pool élastique existant, vous devez le redéployer. Le processus ajoute un réplica secondaire afin d'assurer une haute disponibilité, et le place dans une autre zone de disponibilité.

    Pour plus d’informations, consultez Redéployer une base de données Hyperscale redondante interzone - SQL Database

Pour afficher des informations sur la prise en charge des zones de disponibilité pour d’autres niveaux de service, veillez à sélectionner le niveau de service approprié au début de cette page.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque les bases de données sont configurées pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles.

Pour le niveau de service Usage général :

  • Routage du trafic entre les zones : Les requêtes sont acheminées vers un nœud qui exécute votre couche de calcul de base de données SQL. Lorsque la redondance de zone est activée, ce nœud peut se trouver dans n’importe quelle zone de disponibilité.

  • Réplication des données entre les zones : Les fichiers de données et de journaux sont répliqués de manière synchrone entre les zones de disponibilité à l’aide de ZRS. Les opérations d’écriture ne sont pas considérées comme terminées tant que les données ne sont pas répliquées sur toutes les zones de disponibilité. Cette réplication synchrone garantit une cohérence forte et une perte de données nulle pendant les défaillances de zone. Toutefois, il peut entraîner une latence d’écriture légèrement plus élevée par rapport au stockage localement redondant (LRS).

Pour les niveaux de service Premium et Critique pour l’entreprise :

  • Routage du trafic entre les zones : les réplicas sont distribués parmi les zones de disponibilité, et l’un de ces réplicas est désigné comme réplica principal. Les demandes sont acheminées vers la réplique principale de votre base de données.

  • Réplication des données entre les zones : Le réplica principal pousse constamment des modifications aux réplicas secondaires de manière séquentielle pour s'assurer que les données sont persistantes sur un nombre suffisant de réplicas secondaires avant de valider chaque transaction. Ce processus garantit que si le réplica principal ou un réplica secondaire lisible ne sont plus disponibles pour une raison quelconque, un réplica entièrement synchronisé est toujours disponible pour un basculement. Lorsque la redondance régionale est activée, ces réplicas se trouvent dans différentes zones de disponibilité. Toutefois, le processus peut entraîner une latence d’écriture légèrement plus élevée en raison de la latence du réseau dans les zones de traversée.

Pour le niveau de service Hyperscale :

  • Routage du trafic entre les zones : les réplicas de base de données sont distribués parmi les zones de disponibilité, et l’un de ces réplicas est désigné comme réplica principal. Les demandes sont acheminées vers la réplique principale de votre base de données.

  • Réplication des données entre les zones : Le réplica de base de données principal envoie des modifications via un service de journal redondant interzone, qui réplique toutes les modifications de manière synchrone entre les zones de disponibilité. Les serveurs de pages se trouvent dans chaque zone de disponibilité et stockent l’état de la base de données. Ce processus garantit que si le réplica principal ou un réplica secondaire lisible ne sont plus disponibles pour une raison quelconque, un réplica entièrement synchronisé est toujours disponible pour un basculement. Toutefois, le processus peut entraîner une latence d’écriture légèrement plus élevée par rapport à LRS.

Pour afficher des informations sur la prise en charge des zones de disponibilité pour d’autres niveaux de service, veillez à sélectionner le niveau de service approprié au début de cette page.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsque les bases de données sont configurées pour la redondance de zone et qu’il existe une panne de zone de disponibilité.

  • Détection et réponse : SQL Database est responsable de la détection et de la réponse à une défaillance dans une zone de disponibilité. Vous n’avez rien à faire pour initier un failover de zone.
  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.
  • Demandes actives : Lorsqu’une zone de disponibilité est hors connexion, toutes les requêtes en cours de traitement dans la zone de disponibilité défectueuse sont arrêtées et doivent être retentées. Pour plus d’informations sur la façon de rendre vos applications résilientes à ces types de problèmes, consultez les instructions de résilience aux erreurs temporaires .

  • Réacheminement du trafic : Pour le niveau de service Usage général, SQL Database déplace le moteur de base de données vers un autre nœud de calcul sans état qui se trouve dans une autre zone de disponibilité et dispose d’une capacité libre suffisante. Une fois le basculement terminé, de nouvelles connexions sont automatiquement redirigées vers le nouveau nœud de calcul principal.

    Pour plus d’informations, consultez le niveau de service Usage général.

  • Réacheminement du trafic : Pour les niveaux de service Premium et Critique pour l’entreprise, SQL Database sélectionne un réplica dans une autre zone de disponibilité pour devenir le réplica principal. Une fois qu'une réplique secondaire devient la nouvelle réplique principale, une autre réplique secondaire est créée pour s'assurer que le cluster dispose d'un nombre suffisant de répliques pour maintenir un quorum. Une fois le basculement terminé, de nouvelles connexions sont automatiquement redirigées vers le nouveau réplica principal (ou le réplica secondaire lisible, en fonction de la chaîne de connexion).

    Pour plus d’informations, consultez les niveaux de service Premium et Critique pour l’entreprise.

  • Réacheminement du trafic : Pour le niveau de service Hyperscale, si le réplica principal a été perdu en raison de la panne de zone, SQL Database promeut l’un des réplicas à haute disponibilité dans une autre zone pour être le nouveau réplica principal.

    Pour plus d’informations, consultez Niveau de service Hyperscale.

  • Temps d’arrêt attendu : il peut y avoir un petit temps d’arrêt pendant un basculement de zone de disponibilité. Le temps d’arrêt est généralement inférieur à 30 secondes, que votre application doit tolérer s’il suit les conseils de résilience aux erreurs temporaires .

  • Perte de données attendue : Aucune perte de données n’est attendue lors d’un basculement de zone de disponibilité.

Pour afficher des informations sur la prise en charge des zones de disponibilité pour d’autres niveaux de service, veillez à sélectionner le niveau de service approprié au début de cette page.

Récupération de la zone

Lorsque la zone de disponibilité récupère, Azure Service Fabric crée automatiquement des réplicas de base de données dans la zone de disponibilité récupérée, supprime tous les réplicas temporaires créés dans les autres zones de disponibilité et reprend le routage normal du trafic vers votre base de données. Pour éviter toute interruption, la réplique principale ne revient pas automatiquement à la zone d'origine après la récupération de la zone.

Tester les pannes de zone

La plateforme SQL Database gère le routage du trafic, le basculement et les procédures de récupération entre zones pour les bases de données à redondance zonale. Cette fonctionnalité étant complètement managée, vous n’avez pas besoin de lancer ou de valider les processus de défaillance de zone de disponibilité. Toutefois, vous pouvez valider la gestion des défaillances et des basculements de votre application en suivant le processus décrit dans Tester la résilience des erreurs d’application.

Résilience aux défaillances à l’échelle de la région

Cette section fournit une vue d’ensemble de deux fonctionnalités connexes mais distinctes qui peuvent être utilisées pour la géoréplication multirégion de SQL Database :

La géoréplication active

La géoréplication active crée une base de données secondaire lisible en continu (parfois appelée géoréplica secondaire ou géoréplica) dans n’importe quelle région pour une base de données primaire unique. La géoréplication active peut créer des bases de données secondaires dans la même région, mais cette configuration ne fournit pas de protection contre une panne de région. Lorsque vous utilisez la géoréplication active pour obtenir une géoredondance, vous localisez la base de données secondaire dans une autre région que la base de données primaire.

Spécifications

Lorsque vous utilisez la géoréplication active, tenez compte des exigences suivantes :

  • Prise en charge de la région :la géoréplication active peut être activée dans toutes les régions Azure et ne vous oblige pas à utiliser des paires de régions Azure.

    Conseil / Astuce

    SQL Database suit une pratique de déploiement sécurisée dans laquelle Azure s’efforce de ne pas déployer de mises à jour sur des régions jumelées en même temps. Si vous configurez la géoréplication active pour utiliser des régions non souhaitées, définissez différentes fenêtres de maintenance pour les serveurs de chaque région. Cette approche permet de réduire le risque que les deux régions rencontrent des problèmes de connectivité causés par la maintenance en même temps.

  • Configuration: Le serveur principal et le géo-secondaire doivent avoir le même niveau de service et doivent avoir le même niveau de calcul, la taille de calcul et la redondance du stockage de sauvegarde.

  • Pare-feu: Le principal et le géo-secondaire doivent avoir les mêmes règles de pare-feu d’adresses IP.

  • Abonnements Azure : La géoréplication active est prise en charge pour les bases de données sur différents abonnements Azure.

Considérations

  • La géoréplication active est conçue pour fournir un basculement d’une base de données unique. Si vous devez effectuer un basculement de plusieurs bases de données, envisagez plutôt d'utiliser des groupes de basculement.

  • Étant donné que la géoréplication est asynchrone, la perte de données est possible lorsqu’un basculement se produit. Si vous devez éliminer la perte de données de la réplication asynchrone pendant les basculements, configurez votre application pour bloquer le thread appelant jusqu’à ce que la dernière transaction validée ait été transmise et renforcée dans le journal des transactions de la base de données secondaire. Cette approche nécessite un développement personnalisé et réduit les performances de votre application. Pour plus d’informations, consultez Empêcher la perte de données critiques.

  • Pour plus d’informations sur les limitations et les considérations, consultez Géoréplication active.

Coûts

Les bases de données secondaires sont facturées en tant que bases de données distinctes.

Si vous n’utilisez pas de base de données secondaire pour les charges de travail de lecture ou d’écriture, déterminez si vous pouvez la désigner comme réplica de secours pour réduire vos coûts.

Configurer la prise en charge multirégion

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre lorsqu’une base de données est configurée pour utiliser la géoréplication active et toutes les régions sont opérationnelles.

  • Routage du trafic entre les régions : Votre application doit être configurée pour envoyer des demandes en lecture-écriture à la base de données primaire. Vous pouvez éventuellement envoyer des requêtes en lecture seule à une base de données secondaire, ce qui permet de réduire l’impact des charges de travail en lecture seule sur votre base de données primaire.

  • Réplication des données entre les régions : La réplication entre les bases de données primaires et secondaires se produit de manière asynchrone, ce qui signifie qu’il peut y avoir un délai entre le moment où une modification est appliquée à la base de données primaire et lorsqu’elle est répliquée vers la base de données secondaire.

    Lorsque vous effectuez un basculement, vous décidez comment gérer la possibilité de perte de données.

Comportement lors d’une défaillance de région

Cette section décrit ce qu’il faut attendre lorsqu’une base de données est configurée pour utiliser la géoréplication active et qu’il existe une panne dans votre région primaire :

  • Détection et réponse : Vous êtes responsable de la détection de la panne d’une base de données ou d’une région et du déclenchement du basculement.
  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de région, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  • Demandes actives : Toutes les demandes actives pendant le basculement sont arrêtées et doivent être retentées.

  • Perte de données attendue : Si votre base de données principale est disponible, vous pouvez éventuellement effectuer un basculement sans perte de données. Le processus de basculement synchronise les données entre les bases de données primaires et secondaires avant de changer de rôle.

    Si votre base de données principale n’est pas disponible, vous devrez peut-être effectuer un basculement forcé, ce qui entraîne une perte de données. Vous pouvez estimer la quantité de perte de données en surveillant le décalage de réplication. Pour plus d’informations, consultez Surveiller SQL Database avec des métriques et des alertes.

  • Temps d’arrêt attendu : en règle générale, il y a jusqu’à 60 secondes de temps d’arrêt pendant un basculement. Assurez-vous que votre application gère les erreurs temporaires afin qu’elle puisse récupérer à partir de courtes périodes d’arrêt. En outre, la rapidité avec laquelle vous reconfigurez votre application pour vous connecter à la nouvelle base de données primaire affecte le temps d’arrêt que vous rencontrez.

  • Réacheminement du trafic : Vous êtes responsable de la reconfiguration de votre application pour envoyer des demandes à la nouvelle base de données primaire. Si vous avez besoin d’un basculement transparent, envisagez d’utiliser des groupes de basculement.

Récupération de région

Une fois la région primaire récupérée, vous pouvez effectuer manuellement une restauration automatique vers la région primaire en effectuant un autre basculement.

Tester les défaillances régionales

Vous pouvez simuler une interruption de service dans une région en déclenchant un basculement manuel à tout moment. Vous pouvez déclencher un basculement sans perte de données ou un basculement forcé.

Groupes de basculement

Les groupes de basculement s’appuient sur la géoréplication active. Avec les groupes de basculement, vous pouvez effectuer les opérations suivantes :

  • Répliquez un ensemble de bases de données à partir d’un serveur logique unique sur n’importe quelle combinaison de régions Azure.

  • Effectuez un basculement sur les bases de données en tant que groupe.

  • Utilisez des points de terminaison de connexion qui dirigent automatiquement les connexions au serveur principal.

Spécifications

  • Prise en charge des régions : Vous pouvez créer des groupes de basculement entre toutes les régions Azure. Il n'est pas nécessaire d'utiliser des paires de régions Azure.

    Conseil / Astuce

    Si vous configurez un groupe de basculement avec des régions non appairées, envisagez de définir différentes fenêtres de maintenance pour les serveurs de chaque région. Cette approche permet de réduire le risque que les deux régions rencontrent des problèmes de connectivité causés par la maintenance en même temps.

  • Configuration: Les bases de données secondaires d’un groupe de basculement doivent avoir le même niveau de service, le niveau de calcul, la taille de calcul, les règles de pare-feu d’adresses IP et la redondance du stockage de sauvegarde que la base de données primaire.

Considérations

  • Redondance de zone : Pour le niveau de service Hyperscale, si votre base de données principale a la redondance de zone activée, les bases de données secondaires ont la redondance de zone activée automatiquement.
  • Redondance de zone : Les bases de données secondaires n’ont pas de redondance de zone activée par défaut, mais vous pouvez l’activer ultérieurement.

  • Perte de données possible : Étant donné que la géoréplication est asynchrone, il est possible d’avoir une perte de données lorsqu’un basculement se produit. Si vous devez éliminer la perte de données de la réplication asynchrone pendant les basculements, vous pouvez configurer votre application pour bloquer le thread appelant jusqu’à ce que la dernière transaction validée ait été transmise et renforcée dans le journal des transactions de la base de données secondaire. Cette approche nécessite un développement personnalisé et réduit les performances de votre application. Pour plus d’informations, consultez Empêcher la perte de données critiques.

  • Pour plus d’informations sur les limitations et les considérations, consultez Groupes de basculement.

Coûts

Les bases de données secondaires sont facturées en tant que bases de données distinctes.

Si vous n’utilisez pas de base de données secondaire pour les charges de travail de lecture ou d’écriture, déterminez si vous pouvez la désigner comme réplica de secours pour réduire vos coûts.

Configurer la prise en charge multirégion

  • Activer les groupes de basculement : Vous configurez un groupe de basculement sur un serveur logique. Vous pouvez ajouter toutes les bases de données du serveur logique au groupe de basculement, ou sélectionner un sous-ensemble de bases de données à ajouter.

    Lorsque vous créez un groupe de basculement, vous sélectionnez la stratégie de basculement, qui spécifie qui est responsable de la détection d’une panne et de l’exécution d’un basculement. Vous pouvez configurer le basculement géré par le client, qui est recommandé, ou le basculement géré par Microsoft.

    Important

    Un basculement lancé par Microsoft est susceptible de se produire après un délai significatif, et est effectué sur la base du meilleur effort. Le basculement des bases de données peut se produire à un autre moment que le basculement des autres services Azure. Pour plus d’informations, consultez Configuration d'un groupe de basculement pour SQL Database.

    Après avoir configuré le groupe de basculement, l’étape d’amorçage initiale peut prendre un certain temps.

  • Désactivez les groupes de basculement : Vous pouvez supprimer une base de données individuelle d’un groupe de basculement, supprimer un groupe de basculement entier ou déplacer une base de données dans un autre groupe de basculement.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre lorsqu’une base de données est configurée au sein d’un groupe de basculement et que toutes les régions sont opérationnelles.

  • Routage du trafic entre les régions : pour les charges de travail en lecture-écriture et en lecture seule, les groupes de basculement fournissent deux points de terminaison d’écouteur où vous pouvez connecter vos applications. Utilisez les points de terminaison d’écouteur de groupe de basculement pour réduire le temps d’arrêt pendant les basculements. Pendant les opérations normales, le comportement de routage suivant se produit :

    • Le point de terminaison de l’écouteur en lecture-écriture achemine toutes les requêtes vers les bases de données primaires.

    • Le point de terminaison d’écouteur en lecture seule achemine toutes les requêtes vers une base de données secondaire lisible.

  • Réplication des données entre les régions : La géoréplication entre les bases de données primaires et secondaires se produit de façon asynchrone. Cette latence signifie qu’il peut y avoir un délai entre une modification appliquée à la base de données primaire et lorsqu’elle est répliquée vers la base de données secondaire.

    Lorsque vous effectuez un basculement, vous décidez comment gérer la possibilité de perte de données.

Comportement lors d’une défaillance de région

Cette section décrit ce qui doit être attendu lorsqu’une base de données est configurée dans un groupe de basculement et qu’il existe une panne dans votre région primaire :

  • La détection et la réponse dépendent de la stratégie de basculement que vous utilisez.

    • Basculement initié par le client : Vous êtes responsable de la détection de la panne d’une base de données ou d’une région et du déclenchement du basculement.

    • Basculement initié par Microsoft : Microsoft déclenche le basculement pour tous les groupes de basculement dans la région affectée. Microsoft s’attend à effectuer ce type de basculement uniquement dans des situations exceptionnelles. Ne vous fiez pas au basculement géré par Microsoft pour la plupart des solutions. Pour plus d’informations, consultez la stratégie de basculement gérée par Microsoft.

  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de région, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  • Demandes actives : Toutes les demandes actives pendant le basculement sont arrêtées et doivent être retentées.

  • Perte de données attendue : La perte de données dépend de la stratégie de basculement que vous utilisez.

    • Basculement initié par le client : Si votre base de données principale est disponible, vous pouvez éventuellement effectuer un basculement sans perte de données. Le processus de basculement synchronise les données entre les bases de données primaires et secondaires avant de changer de rôle.

      Si votre base de données principale n’est pas disponible, vous devrez peut-être effectuer un basculement forcé, ce qui entraîne une perte de données. Vous pouvez estimer la quantité de perte de données en surveillant le décalage de réplication. Pour plus d’informations, consultez Surveiller SQL Database avec des métriques et des alertes.

    • Basculement initié par Microsoft : Un basculement géré par Microsoft n’est déclenché que dans des situations exceptionnelles. Les basculements gérés par Microsoft sont des basculements forcés, ce qui signifie que certaines pertes de données sont attendues. Vous ne pouvez pas contrôler la quantité de perte de données que vous pouvez rencontrer.

  • Temps d’arrêt attendu : Le temps d’arrêt dépend de la stratégie de basculement que vous utilisez.

    • Basculement initié par le client : Il existe généralement jusqu’à 60 secondes de temps d’arrêt pendant un basculement. Assurez-vous que votre application gère les erreurs temporaires afin qu’elle puisse récupérer à partir de courtes périodes d’arrêt.

    • Basculement initié par Microsoft : Vous pouvez spécifier une période de grâce qui détermine la durée pendant laquelle Microsoft doit attendre avant de lancer le basculement. La période de grâce minimale est d’une heure. Toutefois, le temps de réponse Microsoft sera probablement plusieurs heures au moins.

  • Réacheminement du trafic : pendant le basculement, SQL Database met à jour les points de terminaison d’écouteur en lecture-écriture et en lecture seule pour diriger le trafic vers les nouvelles bases de données primaires et secondaires en fonction des besoins.

    Si la nouvelle base de données secondaire (précédemment la base de données primaire) n’est pas disponible, le point de terminaison d’écouteur en lecture seule ne peut pas se connecter tant que le nouveau serveur secondaire n’est pas disponible.

Récupération de région

Vous êtes responsable du retour en arrière vers la région primaire si nécessaire. Vous pouvez effectuer manuellement une réversibilité vers la région primaire en exécutant un basculement géré par le client.

Même si Microsoft a lancé le basculement automatique d’origine, vous êtes toujours responsable du rebasculement vers la région précédente, si vous choisissez de le faire.

Tester les défaillances régionales

Vous pouvez simuler une interruption de service dans une région en déclenchant un basculement manuel à tout moment. Vous pouvez déclencher un basculement sans perte de données ou un basculement forcé.

Sauvegarde et restauration

Effectuez des sauvegardes de vos bases de données pour vous protéger contre différents risques, notamment la perte de données. Les sauvegardes peuvent être restaurées pour récupérer à partir d’une perte de données accidentelle, d’une altération ou d’autres problèmes. Les sauvegardes diffèrent de la redondance de zone, de la géoréplication active ou des groupes de basculement, et elles ont des objectifs différents. Pour plus d’informations, consultez Redondance, réplication et sauvegarde.

SQL Database fournit des sauvegardes automatiques de vos bases de données. Pour plus d’informations sur la fréquence de sauvegarde, ce qui peut affecter la quantité de perte de données si vous devez effectuer une restauration à partir d’une sauvegarde, consultez Sauvegardes automatisées dans SQL Database.

Stockage de sauvegarde

Vous pouvez choisir de stocker vos sauvegardes automatisées dans LRS ou ZRS. Si vous utilisez une région jumelée, vous pouvez choisir de répliquer vos sauvegardes automatisées dans la région jumelée à l’aide du stockage géoredondant. Cette fonctionnalité permet la géorestauration de vos sauvegardes dans la région jumelée. Pour plus d’informations, consultez Sauvegardes automatisées dans SQL Database.

Si vous utilisez une région non souhaitée ou si vous devez répliquer des sauvegardes dans une région autre que la région jumelée, envisagez d’exporter la base de données et de stocker le fichier exporté dans un compte de stockage qui utilise la réplication d’objets blob pour répliquer sur un compte de stockage dans une autre région. Pour plus d’informations, consultez Exporter une base de données.

Résilience à la maintenance du service

Quand SQL Database effectue la maintenance de vos bases de données et de vos pools élastiques, il peut basculer automatiquement votre base de données vers un réplica secondaire. Les applications clientes peuvent constater de brèves interruptions de connectivité lorsqu’un basculement se produit. Vos applications clientes doivent suivre les instructions de résilience aux erreurs temporaires pour réduire les effets.

SQL Database vous permet de spécifier une fenêtre de maintenance généralement utilisée pour les mises à niveau de service et d’autres opérations de maintenance. La configuration d’une fenêtre de maintenance peut vous aider à réduire les effets secondaires, tels que les basculements automatiques, pendant vos heures de travail. Vous pouvez également recevoir une notification préalable de maintenance planifiée.

La plateforme gère automatiquement les passerelles utilisées pour le traitement des connexions à SQL Database. Les mises à niveau ou les opérations de maintenance peuvent également entraîner de brèves interruptions de connectivité que les clients peuvent réessayer.

Pour plus d’informations, consultez la fenêtre Maintenance dans SQL Database.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Le contrat de niveau de service (SLA) pour SQL Database décrit la disponibilité attendue du service et le point de récupération et le temps de récupération attendus pour la géoréplication active.

Lorsque vous déployez une base de données redondante entre zones ou un pool élastique et que vous utilisez un niveau de service pris en charge, le SLA de disponibilité est supérieur.

Contenu connexe

  • Last updated on