Vue d'ensemble des groupes de basculement automatique & meilleures pratiques (Azure SQL Database)

S’APPLIQUE À : Azure SQL Database

Les groupes de basculement automatique vous permettent de gérer la réplication et le basculement de tout ou partie des bases de données sur un serveur logique vers une autre région. Cet article se concentre sur l'utilisation de la fonction de groupe de basculement automatique avec Azure SQL Database et sur certaines meilleures pratiques.

Pour commencer, consultez Configurer le groupe de basculement automatique. Pour une expérience de bout en bout, consultez le Tutoriel sur les groupes de basculement automatique.

Notes

  • Cet article parle des groupes de basculement automatique pour Azure SQL Database. Pour Azure SQL Managed Instance, consultez Groupes de basculement automatique dans Azure SQL Managed Instance.
  • Les groupes de basculement automatique prennent en charge la géoréplication de toutes les bases de données du groupe vers un seul serveur secondaire situé dans une autre région. Si vous avez besoin de créer plusieurs réplicas géo-secondaires Azure SQL Database (dans des régions identiques ou différentes) pour le même réplica principal, utilisez la géoréplication active.

Vue d’ensemble

Les groupes de basculement automatique vous permettent de gérer la réplication et le basculement d’un groupe de bases de données sur un serveur, ou de toutes les bases de données utilisateur d’une instance gérée vers une autre région Azure. Il s’agit d’une abstraction déclarative sur la fonctionnalité de géoréplication active, conçue pour simplifier le déploiement et la gestion des bases de données géorépliquées à l’échelle.

Basculement automatique

Vous pouvez déclencher le géobasculement manuellement, ou le déléguer au service Azure via une stratégie définie par l’utilisateur. Cette dernière option vous permet de récupérer automatiquement plusieurs bases de données associées dans une région secondaire, après une défaillance grave ou tout autre événement non planifié entraînant une perte totale ou partielle de la disponibilité de l’instance SQL Database ou SQL Managed Instance dans la région primaire. En règle générale, il s’agit de pannes qui ne peuvent pas être atténuées automatiquement par l’infrastructure de haute disponibilité intégrée. Les déclencheurs de géobasculement peuvent être, par exemple, un incident provoqué par un anneau de locataire ou un anneau de contrôle ayant cessé de fonctionner en raison d’une fuite de mémoire du noyau du système d’exploitation sur des nœuds de calcul. Pour plus d’informations, consultez Haute disponibilité d’Azure SQL.

Déplacer des charges de travail en lecture seule

Pour réduire le trafic vers vos bases de données primaires, vous pouvez également utiliser les bases de données secondaires dans un groupe de basculement pour décharger les charges de travail en lecture seule. Utilisez l'écouteur en lecture seule pour diriger le trafic en lecture seule vers une base de données secondaire lisible.

Redirection de point de terminaison

Les groupes de basculement automatique fournissent des points de terminaison d’écouteur de lecture-écriture et de lecture seule qui restent inchangés pendant les géobasculements. Cela signifie que vous ne devez pas modifier la chaîne de connexion de votre application après un géobasculement car les connexions sont automatiquement acheminées vers la base de données primaire actuelle. Que vous utilisiez l’activation manuelle ou automatique du basculement, un géobasculement bascule toutes les bases de données secondaires du groupe dans le rôle principal. Une fois le géobasculement terminé, l’enregistrement DNS est automatiquement mis à jour pour rediriger les points de terminaison vers la nouvelle région. Pour effectuer un géobasculement des données d’objectif de point et de délai de récupération, consultez Vue d’ensemble de la continuité de l’activité.

Récupération d’une application

Pour arriver à une continuité d’activité totale, l’ajout d’une redondance de base de données régionale n’est qu’une partie de la solution. La récupération d’une application (service) de bout en bout après une défaillance catastrophique implique la récupération de tous les composants constituant le service et tous les services dépendants. En voici quelques exemples : logiciel client (il peut s’agir par exemple d’un navigateur avec un code JavaScript personnalisé), serveurs web frontaux, ressources de stockage et DNS. Il est essentiel que tous les composants résistent aux mêmes défaillances et redeviennent disponibles dans l’objectif de délai de récupération (RTO) de votre application. Par conséquent, vous devez identifier tous les services dépendants et comprendre les garanties et les fonctionnalités qu’ils fournissent. Ensuite, vous devez prendre les mesures appropriées pour vous assurer que votre service fonctionne pendant le basculement des services dont il dépend.

Terminologie et fonctionnalités

  • Groupe de basculement (FOG)

    Un groupe de basculement est un groupe nommé de bases de données gérées par un même serveur qui peut basculer entièrement vers une autre région Azure lorsqu’une partie ou la totalité des bases de données primaires devient indisponible en raison d’une panne dans la région primaire.

    Important

    Le nom du groupe de basculement doit être unique à l’échelle globale dans le domaine .database.windows.net.

  • Serveurs

    Une partie ou la totalité des bases de données utilisateur d’un serveur logique peut être placée dans un groupe de basculement. En outre, un serveur prend en charge plusieurs groupes de basculement sur un seul serveur.

  • Primaire

    Le serveur qui héberge les bases de données primaires dans le groupe de basculement.

  • Secondaire

    Le serveur qui héberge les bases de données secondaires dans le groupe de basculement. Le serveur logique secondaire ne peut pas être situé dans la même région Azure que le serveur logique primaire.

  • Ajouter des bases de données uniques au groupe de basculement

    Vous pouvez placer plusieurs bases de données uniques sur le même serveur, dans le même groupe de basculement. Si vous ajoutez une base de données unique au groupe de basculement, une base de données secondaire de la même édition et de la même taille de calcul est automatiquement créée sur le serveur secondaire que vous avez spécifié à la création du groupe de basculement. Si vous ajoutez une base de données qui présente déjà une base de données secondaire dans le serveur secondaire, ce lien de géoréplication est hérité par le groupe. Lors de l’ajout d’une base de données qui présente déjà une base de données secondaire sur un serveur qui ne fait pas partie du groupe de basculement, une nouvelle base de données secondaire est créée sur le serveur secondaire.

    Important

    Assurez-vous que le serveur secondaire ne dispose pas d’une base de données portant le même nom, sauf s’il s’agit d’une base de données secondaire existante.

  • Ajouter des bases de données d’un pool élastique au groupe de basculement

    Vous pouvez placer une partie ou la totalité des bases de données d’un pool élastique dans le même groupe de basculement. Si la base de données primaire se trouve dans un pool élastique, la base de données secondaire est automatiquement créée dans le pool élastique du même nom (pool secondaire). Vérifiez que le serveur secondaire contient un pool élastique portant exactement le même nom et offrant une capacité disponible suffisante pour héberger les bases de données secondaires qui seront créées par le groupe de basculement. Si vous ajoutez une base de données dans le pool qui présente déjà une base de données secondaire dans le pool secondaire, ce lien de géoréplication est hérité par le groupe. Si vous ajoutez une base de données qui présente déjà une base de données secondaire sur un serveur ne faisant pas partie du groupe de basculement, une nouvelle base de données secondaire est créée dans le pool secondaire.

  • Écouteur en lecture-écriture du groupe de basculement

    Un enregistrement DNS CNAME qui pointe vers le serveur primaire actuel. Il est généré automatiquement lorsque le groupe de basculement est créé, et permet à la charge de travail en lecture-écriture de se reconnecter en toute transparence au serveur primaire une fois modifié après le basculement. Lorsque le groupe de basculement est créé sur un serveur, l’enregistrement DNS CNAME pour l’URL de l’écouteur est formé comme suit : <fog-name>.database.windows.net.

  • Écouteur en lecture seule du groupe de basculement

    Un enregistrement DNS CNAME qui pointe vers le serveur secondaire actuel. Il est créé automatiquement lorsque le groupe de basculement est créé et permet à la charge de travail SQL en lecture seule de se connecter en toute transparence au serveur secondaire une fois modifié après le basculement. Lorsque le groupe de basculement est créé sur un serveur, l’enregistrement DNS CNAME pour l’URL de l’écouteur est formé comme suit : <fog-name>.secondary.database.windows.net.

  • Plusieurs groupes de basculement

    Vous pouvez configurer plusieurs groupes de basculement pour la même paire de serveurs afin de contrôler l’étendue des géobasculements. Chaque groupe bascule indépendamment. Si l’application par base de données de votre locataire est déployée dans plusieurs régions et utilise des pools élastiques, vous pouvez utiliser cette fonctionnalité pour mélanger des bases de données primaires et secondaires dans chaque pool. De cette façon, vous pouvez réduire l’impact d’une panne à seulement certaines bases de données de locataire.

  • Stratégie de basculement automatique

    Par défaut, un groupe de basculement est configuré avec une stratégie de basculement automatique. Le système déclenche un géobasculement dès que la panne est détectée et que la période de grâce a expiré. Le système doit vérifier que la panne ne peut pas être atténuée par l’infrastructure de haute disponibilité intégrée, par exemple en raison de l’échelle de l’impact. Si vous souhaitez contrôler le workflow du géobasculement à partir de l’application ou manuellement, vous pouvez désactiver la stratégie de basculement automatique.

    Notes

    Compte tenu du fait que la vérification de l’étendue de la panne et que la rapidité avec laquelle elle peut être atténuée impliquent des actions humaines, la période de grâce ne peut pas être fixée en dessous d’une heure. Cette limitation s’applique à toutes les bases de données du groupe de basculement, quel que soit l’état de la synchronisation de leurs données.

  • Stratégie de basculement en lecture seule

    Par défaut, le basculement de l’écouteur en lecture seule est désactivé. Il garantit que les performances du serveur principal ne sont pas affectées lorsque le serveur secondaire est hors connexion. Toutefois, cela signifie également que les sessions en lecture seule ne seront pas en mesure de se connecter tant que le serveur secondaire n’aura pas été récupérée. Si vous ne pouvez pas tolérer des temps d’arrêt pour les sessions en lecture seule et que vous pouvez utiliser le serveur principal pour le trafic en lecture seule et en lecture-écriture au prix d’une dégradation potentielle des performances du serveur principal, vous pouvez activer le basculement pour l’écouteur en lecture seule en configurant la propriété AllowReadOnlyFailoverToPrimary. Dans ce cas, le trafic en lecture seule est automatiquement redirigé vers le serveur principal si le serveur secondaire est indisponible.

    Notes

    La propriété AllowReadOnlyFailoverToPrimary n’a d’effet que si la stratégie de basculement automatique est activée et qu’un géobasculement automatique a été déclenché. Dans ce cas, si la propriété est définie sur True, le nouveau serveur principal servira les sessions en lecture-écriture et en lecture seule.

  • Basculement planifié

    Le basculement planifié effectue une synchronisation des données complète entre les bases de données primaire et secondaire avant que la seconde ne bascule dans le rôle primaire. Cela empêche toute perte de données. Le basculement planifié des appareils est utilisé dans les scénarios suivants :

    • Simuler des récupérations d’urgence en production lorsque la perte de données n’est pas acceptable
    • Déplacer les bases de données vers une autre région
    • Renvoyer les bases de données vers la région primaire une fois la panne éliminée (restauration automatique)
  • Basculement non planifié

    Le basculement non planifié ou forcé bascule immédiatement la base de données secondaire vers le rôle primaire sans attendre que les modifications récentes soient propagées à partir de la base de données primaire. Cette opération peut occasionner une perte de données. Le basculement non planifié est utilisé comme méthode de récupération pendant les pannes, lorsque la base de données primaire n’est pas accessible. Lorsque la panne est atténuée, l’ancienne base de données primaire se reconnecte automatiquement et devient une nouvelle base de données secondaire. Un basculement planifié peut être exécuté pour la restauration automatique, en retournant les réplicas à leurs rôles primaires et secondaires d’origine.

  • Basculement manuel

    Vous pouvez lancer manuellement un géobasculement quand vous voulez, quelle que soit la configuration du basculement automatique. Pendant une panne qui a un impact sur le serveur principal, si la stratégie de basculement automatique n’est pas configuré, un basculement manuel est nécessaire pour que le rôle secondaire devienne primaire. Vous pouvez lancer un basculement forcé (non planifié) ou convivial (planifié). Un basculement convivial n’est possible que lorsque l’ancien rôle primaire est accessible et peut être utilisé pour déplacer la base de données primaire vers la région secondaire sans perte de données. Une fois le basculement terminé, les enregistrements DNS sont automatiquement mis à jour pour garantir la connexion au nouveau serveur principal.

  • Période de grâce avec perte de données

    Comme les données sont répliquées vers la base de données secondaire à l’aide d’une réplication asynchrone, un géobasculement automatique peut entraîner une perte de données. Vous pouvez personnaliser la stratégie de basculement automatique en fonction de la tolérance de votre application aux pertes de données. En configurant GracePeriodWithDataLossHours, vous pouvez contrôler le délai observé par le système avant d’initier un basculement qui est susceptible d’entraîner une perte de données.

Architecture du groupe de basculement

Un groupe de basculement dans Azure SQL Database peut inclure une ou plusieurs bases de données, généralement utilisées par la même application. Lorsque vous utilisez des groupes de basculement automatique avec une stratégie de basculement automatique, toute panne qui affecte une ou plusieurs des bases de données du groupe donnera lieu à un géobasculement automatique.

Le groupe de basculement automatique doit être configuré sur le serveur primaire, qu’il connectera au serveur secondaire dans une autre région Azure. Les groupes peuvent inclure une partie ou la totalité des bases de données dans ces serveurs. Le diagramme suivant illustre la configuration standard d’une application cloud géoredondante avec plusieurs bases de données et un groupe de basculement automatique.

Diagram shows a typical configuration of a geo-redundant cloud application using multiple databases and auto-failover group.

Lorsque vous concevez un service en tenant compte de la continuité des activités, suivez les recommandations générales et les meilleures pratiques décrites dans cet article. Lors de la configuration d’un groupe de basculement, assurez-vous que l’authentification et l’accès réseau sur le réplica secondaire sont configurés pour fonctionner correctement après le géobasculement, lorsque le réplica géosecondaire devient le nouveau réplica primaire. Pour plus d’informations, consultez Gestion de la sécurité de la base de données SQL Azure après la récupération d’urgence. Pour plus d’informations sur la conception de solutions pour la récupération d’urgence, consultez la page Designing Cloud Solutions for Disaster Recovery Using active geo-replication (Conception de solutions cloud pour la récupération d’urgence à l’aide de la géo-réplication active).

Pour plus d’informations sur l’utilisation de la limite de restauration dans le temps avec les groupes de basculement, voir Limite de restauration dans le temps.

Amorçage initial

Lorsque vous ajoutez des bases de données ou des pools élastiques à un groupe de basculement, il y a d’abord une phase d’amorçage initiale avant le démarrage de la réplication des données. La phase d’amorçage initiale est l’opération la plus longue et la plus coûteuse. Une fois l’amorçage initial terminé, les données sont synchronisées, puis seules les modifications de données ultérieures sont répliquées. Le temps nécessaire à la réalisation de l’amorçage initial dépend de la taille de vos données, du nombre de bases de données répliquées, de la charge sur les bases de données primaires et de la vitesse de la liaison entre les bases de données principales et secondaires. Dans des circonstances normales, la vitesse d’amorçage possible peut atteindre 500 Go par heure pour SQL Database. L’amorçage est effectué pour toutes les bases de données en parallèle.

Utiliser différents groupes de basculement pour différentes bases de données de basculement

Un ou plusieurs groupes de basculement peuvent être créés entre deux serveurs situés dans des régions différentes (serveurs principal et serveur secondaire). Chaque groupe peut inclure une ou plusieurs bases de données qui sont récupérées ensemble dans le cas où une partie ou la totalité des bases de données primaires deviennent indisponibles en raison d’une panne dans la région principale. La création d’un groupe de basculement crée des bases de données géosecondaires avec le même objectif de service que la base de données primaire. Si vous ajoutez une relation de géoréplication existante à un groupe de basculement, vérifiez que la base de données géosecondaire est configurée avec le même niveau de service et la même taille de calcul que la base de données primaire.

Utiliser l’écouteur en lecture-écriture (primaire)

Pour les charges de travail en lecture-écriture, utilisez <fog-name>.database.windows.net comme nom de serveur dans la chaîne de connexion. Les connexions seront automatiquement dirigées vers la base de données primaire. Ce nom ne change pas après le basculement. Notez que le basculement implique la mise à jour de l’enregistrement DNS de façon à ce que les connexions clients soient redirigées vers le nouveau serveur primaire seulement après l’actualisation du cache DNS. La durée de vie (TTL) de l’enregistrement DNS des écouteurs principal et secondaire est de 30 secondes.

Utiliser l'écouteur en lecture seule (secondaire)

Si vous avez des charges de travail en lecture seule isolées logiquement qui sont tolérantes à la latence des données, vous pouvez les exécuter sur la base de données géosecondaire. Pour les sessions en lecture seule, utilisez <fog-name>.secondary.database.windows.net comme nom de serveur dans la chaîne de connexion. Les connexions seront automatiquement dirigées vers la base de données géosecondaire. Il est également recommandé d’indiquer une intention de lecture dans la chaîne de connexion à l’aide de ApplicationIntent=ReadOnly.

Dans les niveaux de service Premium, Critique pour l’entreprise et Hyperscale, Azure SQL Database prend en charge l’utilisation de réplicas en lecture seule pour décharger des charges de travail de requête en lecture seule, en utilisant le paramètre ApplicationIntent=ReadOnly dans la chaîne de connexion. Lorsque vous avez configuré une base de données géosecondaire, vous pouvez utiliser cette fonction pour vous connecter à un réplica en lecture seule à l’emplacement primaire ou à l’emplacement géorépliqué :

  • Pour vous connecter à un réplica en lecture seule à l’emplacement secondaire, utilisez ApplicationIntent=ReadOnly et <fog-name>.secondary.database.windows.net.

Dégradation potentielle des performances après le basculement

Une application Azure classique fait appel à plusieurs services Azure et inclut plusieurs composants. Le géobasculement automatique du groupe de basculement est déclenché en fonction de l’état des seuls composants Azure SQL. Il peut arriver que les autres services Azure de la région primaire ne soient pas affectés par la panne et que leurs composants soient toujours disponibles dans cette région. Une fois que les bases de données primaires ont basculé vers la région (DR) secondaire, la latence entre les composants dépendants peut augmenter. Pour éviter l’impact d’une latence plus élevée sur les performances de l’application, vérifiez la redondance de tous les composants de l’application dans la région DR, suivez ces instructions de sécurité réseau et orchestrez le géobasculement des composants d’application concernés avec la base de données.

Perte potentielle de données après le basculement

Si une panne se produit dans la région primaire, les transactions récentes risquent de ne pas pouvoir être répliquées sur la base de données géosecondaire. Si la stratégie de basculement automatique est configurée, le système attend la période que vous avez spécifiée via GracePeriodWithDataLossHours avant de lancer un géobasculement automatique. La valeur par défaut est 1 heure. Cela favorise la disponibilité de la base de données au détriment de l’absence de perte de données. Si vous définissez GracePeriodWithDataLossHours avec un nombre plus élevé, par exemple 24 heures, ou si vous désactivez le géobasculement automatique,cela vous permet de réduire le risque d’une perte de données au détriment de la disponibilité de la base de données.

Important

Les pools élastiques avec 800 DTU ou moins ou 8 vCores ou moins et plus de 250 bases de données peuvent rencontrer des problèmes, notamment des géobasculements planifiés plus longs et une dégradation des performances. Ces problèmes sont davantage susceptibles de se produire pour les charges de travail gourmandes en écriture, quand les géoréplicas sont géographiquement très éloignés, ou quand plusieurs géoréplicas secondaires sont utilisés pour chaque base de données. Un symptôme de ces problèmes est une augmentation du décalage de la géoréplication au fil du temps, ce qui peut entraîner une perte de données plus importante en cas de panne. Ce décalage peut être surveillé avec sys.dm_geo_replication_link_status. Si ces problèmes se produisent, l’atténuation consiste à mettre à l’échelle le pool pour avoir plus de DTU ou de vCores, ou à réduire le nombre de bases de données géorépliquées dans le pool.

Groupes de basculement et sécurité réseau

Pour certaines applications, les règles de sécurité demandent que l’accès réseau à la couche données soit limité à un ou plusieurs composants spécifiques, tels qu’une machine virtuelle, un service web, etc. Cette condition présente des défis pour la conception de la continuité de l’activité et l’utilisation de groupes de basculement. Tenez compte des options suivantes lors de l’implémentation d’un accès restreint.

Utiliser des groupes de basculement et des points de terminaison de service de réseau virtuel

Si vous utilisez des règles et points de terminaison de service de réseau virtuel pour restreindre l’accès à votre base de données dans SQL Database, n’oubliez pas que chaque point de terminaison de service de réseau virtuel s’applique à une seule région Azure. Le point de terminaison ne permet pas à d’autres régions d’accepter les communications provenant du sous-réseau. Par conséquent, seules les applications client déployées dans la même région peuvent se connecter à la base de données primaire. Comme un géobasculement entraîne la redirection des sessions du client SQL Database vers un serveur dans une autre région (secondaire), ces sessions échouent si elles proviennent d’un client situé en dehors de cette région. Pour cette raison, la stratégie de basculement automatique ne peut pas être activée si les instances ou serveurs participants sont inclus dans les règles de réseau virtuel. Pour prendre en charge le basculement manuel, effectuez les étapes suivantes :

  1. Provisionnez les copies redondantes des composants front-end de votre application (service web, machines virtuelles, etc.) dans la région secondaire.
  2. Configurez les règles de réseau virtuel individuellement pour les serveurs primaire et secondaire.
  3. Activez le basculement front-end à l’aide d’une configuration Traffic Manager.
  4. Lancez un géobasculement manuel quand la panne est détectée. Cette option est optimisée pour les applications qui requièrent une latence constante entre le frontend et la couche Données, et prend en charge la récupération quand le frontend et/ou la couche Données sont affectés par la panne.

Notes

Si vous utilisez l’écouteur en lecture seule pour équilibrer une charge de travail en lecture seule, vérifiez que cette charge de travail est exécutée dans une machine virtuelle ou une autre ressource dans la région secondaire pour qu’elle puisse se connecter à la base de données secondaire.

Utiliser des groupes de basculement et des règles de pare-feu

Si votre plan de continuité d’activité nécessite un basculement à l’aide de groupes avec basculement automatique, vous pouvez restreindre l’accès à votre base de données dans SQL Database, en utilisant des règles de pare-feu d’IP publiques. Pour prendre en charge le basculement automatique, effectuez les étapes suivantes :

  1. Créez une adresse IP publique.
  2. Créez un équilibreur de charge public et affectez-lui l’adresse IP publique.
  3. Créez un réseau virtuel et les machines virtuelles pour vos composants front-end.
  4. Créez un groupe de sécurité réseau et configurez les connexions entrantes.
  5. Vérifiez que les connexions sortantes sont ouvertes pour Azure SQL Database dans une région en utilisant une Sql.<Region>étiquette de service.
  6. Créez une règle de pare-feu SQL Database pour autoriser le trafic entrant à partir de l’adresse IP publique que vous créez à l’étape 1.

Pour plus d’informations sur la configuration de l’accès sortant et l’adresse IP à utiliser dans les règles de pare-feu, voir Connexions sortantes de l’équilibreur de charge.

La configuration ci-dessus garantit qu’un géobasculement automatique ne bloque pas les connexions à partir des composants front-end et part du principe que l’application peut tolérer la plus longue latence entre le front-end et la couche Données.

Important

Pour garantir la continuité d’activité lors de pannes régionales, vous devez vérifier la redondance géographique pour les composants front-end et les bases de données.

Mettre à l’échelle une base de données primaire

Vous pouvez effectuer un scale-up/down sur une base de données primaire avec une taille de calcul différente (au sein du même niveau de service) sans déconnecter les bases de données géosecondaires. Lors du scale-up, nous vous recommandons de commencer par la base de données géosecondaire, puis de terminer avec la base de données primaire. Lors du scale-down, inversez l’ordre : commencez par la base de données primaire, puis terminez par la base de données secondaire. Quand vous faites passer la base de données à un niveau de service supérieur ou inférieur, cette recommandation s’applique.

Cette séquence est recommandée dans le but spécifique d’éviter le problème de surcharge des bases de données géosecondaires avec une référence SKU inférieure. Celles-ci doivent alors être alimentées à nouveau lors du passage à une version inférieure ou supérieure. Vous pouvez également éviter le problème en attribuant un accès en lecture seule à la base de données primaire, ce qui peut cependant nuire à toutes les charges de travail en lecture-écriture qui y sont associées.

Notes

Si vous avez créé une base de données géosecondaire dans le cadre de la configuration du groupe de basculement, il n’est pas recommandé d’effectuer un scale-down dessus. En effet, votre couche Données pourrait manquer de capacité pour traiter votre charge de travail normale après un géobasculement.

Empêcher la perte de données critiques

En raison de la latence élevée des réseaux étendus, la géoréplication utilise un mécanisme de réplication asynchrone. La réplication asynchrone rend la possibilité de perte de données inévitable en cas de défaillance de la base de données primaire. Pour protéger les transactions critiques d’une perte de données, le développeur d’applications peut appeler la procédure stockée sp_wait_for_database_copy_sync immédiatement après la validation de la transaction. L’appel de sp_wait_for_database_copy_sync bloque 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. Toutefois, il n’attend pas que les transactions transmises soient relues (réeffectuées) sur la base de données secondaire. sp_wait_for_database_copy_sync est limité à un lien de géoréplication spécifique. Tout utilisateur disposant de droits de connexion à la base de données primaire peut appeler cette procédure.

Notes

sp_wait_for_database_copy_sync empêche la perte de données après un géobasculement pour des transactions spécifiques, mais ne garantit pas une synchronisation complète pour l’accès en lecture. Le délai causé par un appel de procédure sp_wait_for_database_copy_sync peut être significatif et dépend de la taille du journal des transactions pas encore transmis à la base de données primaire au moment de l’appel.

Autorisations

Les autorisations pour un groupe de basculement sont gérées via un contrôle d’accès en fonction du rôle Azure (Azure RBAC).

L’accès en écriture à RBAC Azure est nécessaire pour créer et gérer des groupes de basculement. Le rôle Contributeur SQL Server dispose des autorisations nécessaires pour gérer des groupes de basculement.

Pour obtenir des étendues d’autorisation spécifiques, consultez l’article sur la façon de configurer des groupes de basculement automatique dans Azure SQL Database.

Limites

Notez les limitations suivantes :

  • Il n’est pas possible de créer des groupes de basculement entre deux serveurs au sein de la même région Azure.
  • Les groupes de basculement ne peuvent pas être renommés. Vous devrez supprimer le groupe puis le recréer sous un autre nom.
  • Le renommage de base de données n’est pas pris en charge pour les bases de données situées dans un groupe de basculement. Vous devrez supprimer temporairement le groupe de basculement pour pouvoir renommer une base de données ou supprimer la base de données du groupe de basculement.

Gérer programmatiquement des groupes de basculement

Comme indiqué plus haut, les groupes de basculement automatique peuvent aussi être gérés programmatiquement en utilisant Azure PowerShell, Azure CLI et l’API REST. Les tableaux ci-dessous décrivent l’ensemble des commandes disponibles. La géoréplication active comprend un ensemble d’API Azure Resource Manager pour la gestion, notamment l’API REST Azure SQL Database et les applets de commande Azure PowerShell. Ces API nécessitent l’utilisation de groupes de ressources et la prise en charge du contrôle d’accès en fonction du rôle (RBAC). Pour plus d’informations sur l’implémentation de rôles d’accès, consultez la page sur le contrôle d’accès en fonction du rôle Azure (RBAC Azure).

Applet de commande Description
New-AzSqlDatabaseFailoverGroup Cette commande crée un groupe de basculement et l’enregistre dans les serveurs primaire et secondaire
Remove-AzSqlDatabaseFailoverGroup Supprime un groupe de basculement du serveur
Get-AzSqlDatabaseFailoverGroup Récupère la configuration d’un groupe de basculement
Set-AzSqlDatabaseFailoverGroup Modifie la configuration d’un groupe de basculement
Switch-AzSqlDatabaseFailoverGroup Déclenche le basculement d’un groupe de basculement vers le serveur secondaire
Add-AzSqlDatabaseToFailoverGroup Ajoute une ou plusieurs bases de données à un groupe de basculement

Étapes suivantes