Vue d'ensemble des groupes de basculement automatique et meilleures pratiques (Azure SQL Managed Instance)

S’applique à : Azure SQL Managed Instance

Les groupes de basculement automatique vous permettent de gérer la réplication et le basculement de toutes les bases de données utilisateur d’une instance gérée vers une autre région Azure. Cet article se concentre sur l'utilisation de la fonction de groupe de basculement automatique avec Azure SQL Managed Instance 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 Managed Instance. Pour Azure SQL Database, consultez Groupes de basculement automatique dans SQL Database.

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 permet à toutes les bases de données utilisateur d'une instance gérée de basculer en tant qu'unité vers une autre région Azure si l'instance gérée primaire devient indisponible en raison d'une panne de la région primaire. Comme les groupes de basculement pour SQL Managed Instance contiennent toutes les bases de données utilisateur dans l'instance, un seul groupe de basculement peut être configuré sur une instance.

    Important

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

  • Primaire

    L’instance gérée qui héberge les bases de données primaires dans le groupe de basculement.

  • Secondaire

    L’instance gérée 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.

  • Zone DNS

    ID unique qui est généré automatiquement lorsqu’une instance SQL Managed Instance est créée. Un certificat multidomaine (SAN) est approvisionné pour cette instance afin d’authentifier les connexions clientes effectuées auprès de toutes les instances présentes dans la même zone DNS. Les deux instances gérées d’un même groupe de basculement doivent partager la zone DNS.

  • É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 une instance SQL Managed Instance, l’enregistrement DNS CNAME pour l’URL de l’écouteur est formé comme suit : <fog-name>.<zone_id>.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 une instance SQL Managed Instance, l’enregistrement DNS CNAME pour l’URL de l’écouteur est formé comme suit : <fog-name>.secondary.<zone_id>.database.windows.net.

  • 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)

    Notes

    Si une base de données contient des objets OLTP en mémoire, les bases de données primaires et les bases de données de géo-réplica secondaires cibles doivent avoir des niveaux de service correspondants, car les objets OLTP en mémoire sont toujours hydratés en mémoire. Un niveau de service inférieur sur la base de données de géo-réplica cible peut entraîner des problèmes de manque de mémoire. Si cela se produit, le réplica de base de données géo-secondaire affecté peut être placé en mode lecture seule limité, appelé mode point de contrôle OLTP en mémoire uniquement. Les requêtes de table en lecture seule sont autorisées, mais les requêtes de table OLTP en lecture seule ne sont pas autorisées sur le réplica de base de données géo-secondaire affecté. Le basculement planifié est bloqué si tous les réplicas de la base de données géo-secondaire sont en mode point de contrôle uniquement. Le basculement non planifié peut échouer en raison de problèmes de manque de mémoire. Pour éviter cela, mettez à niveau le niveau de service de la base de données secondaire pour correspondre à la base de données primaire pendant le basculement planifié ou l’extraction. Les mises à niveau de niveau de service peuvent être des opérations dépendant de la taille des données, et peuvent prendre un certain temps.

  • 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

Le groupe de basculement automatique doit être configuré sur l’instance primaire, qu’il connectera à l’instance secondaire dans une autre région Azure. Toutes les bases de données utilisateur de l’instance seront répliquées sur l’instance secondaire. Les bases de données système telles que MASTER et msdb ne seront pas répliquées.

Le diagramme suivant illustre la configuration standard d’une application cloud géoredondante avec une instance managée et un groupe de basculement automatique :

Diagramme de groupe de basculement automatique pour SQL MI

Si votre application utilise SQL Managed Instance comme niveau de données, suivez les directives générales et les meilleures pratiques décrites dans cet article lors de la conception des éléments en rapport avec la continuité d’activité.

Création de l’instance géorépliquée secondaire

Pour garantir une connectivité ininterrompue à l’instance SQL Managed Instance principale après le basculement, les instances principale et secondaire doivent se trouver dans la même zone DNS. Cela garantit que le même certificat multidomaine (SAN) peut être utilisé pour authentifier les connexions clientes avec les deux instances du groupe de basculement. Lorsque votre application est prête pour le déploiement en production, créez une instance SQL Managed Instance secondaire dans une autre région et assurez-vous qu’elle partage la même zone DNS que l’instance SQL Managed Instance principale. Vous pouvez y parvenir en spécifiant un paramètre facultatif au moment de la création. Si vous utilisez PowerShell ou l’API REST, le nom du paramètre facultatif est DNSZonePartner. Le nom du champ facultatif correspondant dans le portail Azure est Instance managée principale.

Important

La première instance gérée créée dans le sous-réseau détermine la zone DNS pour toutes les instances suivantes de ce même sous-réseau. Cela signifie que deux instances d'un même sous-réseau ne peuvent pas appartenir à des zones DNS différentes.

Pour plus d’informations sur la création de l’instance SQL Managed Instance secondaire dans la même zone DNS que l’instance principale, voir Créer une instance managée secondaire.

Utiliser des régions jumelées

Déployez les deux instances managées dans des régions jumelées pour des raisons de performances. Les groupes de basculement SQL Managed Instance dans les régions jumelées offrent de meilleures performances par rapport aux régions non jumelées.

Activer et optimiser le flux de trafic de géoréplication entre les instances

La connectivité entre les sous-réseaux de réseau virtuel hébergeant les instances principale et secondaire doit être établie et gérée pour un flux de trafic de géoréplication ininterrompu. Il existe plusieurs façons de fournir une connectivité entre les instances parmi lesquelles vous pouvez choisir en fonction de la topologie et des stratégies de votre réseau :

Important

Le peering de réseaux virtuels globaux est la méthode recommandée pour établir la connectivité entre deux instances dans un groupe de basculement. Il fournit une connexion privée à faible latence et à bande passante élevée entre les réseaux virtuels appairés à l’aide de l’infrastructure principale de Microsoft. Aucun chiffrement supplémentaire et aucune connexion Internet publique, ni passerelle ne sont nécessaires pour que les réseaux virtuels d’homologues communiquent. Le peering de réseaux virtuels globaux est pris en charge pour les instances hébergées dans des sous-réseaux créés après le 22/09/2020. Pour pouvoir utiliser l’appairage de réseaux virtuels mondiaux pour des instances gérées par SQL hébergées dans des sous-réseaux créés avant le 22/09/2020, envisagez de configurer une fenêtre de maintenance autre que la fenêtre par défaut sur les instances, car cela déplacera les instances dans de nouveaux clusters virtuels prenant en charge l’appairage de réseaux virtuels mondiaux.

Quel que soit le mécanisme de connectivité, il existe des exigences qui doivent être remplies pour que le trafic de géoréplication soit acheminé :

  • Les règles de groupe de sécurité réseau sur le sous-réseau hébergeant l’instance principale autorisent :
    • Le trafic entrant sur le port 5022 et la plage de ports 11000-11999 à partir du sous-réseau hébergeant l’instance secondaire.
    • Le trafic sortant sur le port 5022 et plage de ports 11000-11999 vers le sous-réseau hébergeant l’instance secondaire.
  • Les règles de groupe de sécurité réseau sur le sous-réseau hébergeant l’instance secondaire autorisent :
    • Le trafic entrant sur le port 5022 et la plage de ports 11000-11999 à partir du sous-réseau hébergeant l’instance principale.
    • Le trafic sortant sur le port 5022 et plage de ports 11000-11999 vers le sous-réseau hébergeant l’instance principale.
  • Les plages d’adresses IP des réseaux virtuels hébergeant les instances principale et secondaire ne doivent pas se chevaucher.
  • Il n’existe aucun chevauchement indirect de la plage d’adresses IP entre les réseaux virtuels hébergeant les instances principale et secondaire et les autres réseaux virtuels auxquels ils sont appairés via le peering de réseaux virtuels locaux ou d’autres moyens

En outre, si vous utilisez d’autres mécanismes pour fournir une connectivité entre les instances que le peering de réseaux virtuels globaux recommandé, vous devez vérifier ce qui suit :

  • Aucun appareil réseau utilisé, comme les pare-feu ou les appliances virtuelles réseau, ne bloque le trafic décrit ci-dessus.
  • Le routage est correctement configuré et que le routage asymétrique est évité.
  • Si vous déployez des groupes de basculement automatique dans une topologie de réseau Hub-and-spoke inter-région, le trafic de réplication doit circuler directement entre les deux sous-réseaux d’instance gérée au lieu d’être redirigé via les réseaux hub. Cela vous aidera à éviter les problèmes de connectivité et de vitesse de réplication.

Important

D’autres moyens de fournir une connectivité entre les instances impliquant des appareils de mise en réseau supplémentaires peuvent rendre le processus de dépannage en cas de problèmes de connectivité ou de vitesse de réplication très difficile, et nécessiter la participation active des administrateurs réseau et prolonger considérablement le temps de résolution.

Amorçage initial

Lors de l’établissement d’un groupe de basculement entre des instances managées, il existe une phase d’amorçage initiale avant le démarrage de la réplication des données. La phase d’amorçage initiale est la partie de 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 à l’amorçage initial dépend de la taille des données, du nombre de bases de données répliquées, de l’intensité de la charge de travail sur les bases de données primaires et de la vitesse de la liaison entre les réseaux virtuels hébergeant les instances principales et secondaires qui dépend principalement de la façon dont la connectivité est établie. Dans des circonstances normales et lorsque la connectivité est établie à l’aide du peering de réseaux virtuels globaux recommandé, la vitesse d’amorçage est de 360 Go par heure pour SQL Managed Instance. L’amorçage est effectué pour un lot de bases de données utilisateur en parallèle, pas nécessairement pour toutes les bases de données en même temps. Plusieurs lots peuvent être nécessaires s’il existe de nombreuses bases de données hébergées sur l’instance.

Si la vitesse de la liaison entre les deux instances est plus lente que nécessaire, la durée de l’amorçage risque d’être sensiblement perturbée. Vous pouvez utiliser la vitesse d’amorçage indiquée, ainsi que le nombre de bases de données, la taille totale des données et la vitesse de liaison pour estimer la durée de la phase d’amorçage initiale avant le début de la réplication des données. Par exemple, pour une base de données individuelle de 100 Go, la phase d’amorçage initiale prendrait environ 1,2 heure si la liaison est en mesure d’envoyer (push) 84 Go par heure, et si aucune autre base de données n’est en cours d’amorçage. Si la liaison ne peut transférer que 10 Go par heure, l’amorçage d’une base de données de 100 Go prendra environ 10 heures. S’il faut répliquer plusieurs bases de données, l’amorçage est effectué en parallèle et, lorsqu’il est associé à une vitesse de liaison lente, la phase d’amorçage initiale peut prendre beaucoup plus de temps. Cela est particulièrement vrai si l’amorçage parallèle des données de toutes les bases de données est supérieur à la bande passante de liaison disponible.

Important

Dans le cas d’une liaison à très faible vitesse ou occupée qui fait que la phase d’amorçage initiale prend des jours, la création d’un groupe de basculement peut se prolonger. Le processus de création sera automatiquement annulé après 6 jours.

Gérer le géobasculement dans une instance géosecondaire

Le groupe de basculement gère le géobasculement de toutes les bases de données sur l’instance managée principale. Lorsqu’un groupe est créé, chaque base de données de l’instance est automatiquement géorépliquée sur l’instance géosecondaire. Vous ne pouvez pas utiliser les groupes de basculement pour lancer le basculement partiel d’un sous-ensemble de bases de données.

Important

Si une base de données est abandonnée sur l’instance managée principale, elle est auss abandonnée automatiquement sur l’instance managée géosecondaire.

Utiliser l’écouteur en lecture-écriture (instance managée principale)

Pour les charges de travail en lecture-écriture, utilisez <fog-name>.zone_id.database.windows.net comme nom de serveur. Les connexions seront automatiquement dirigées vers la base de données primaire. Ce nom ne change pas après le basculement. Le géobasculement implique la mise à jour de l’enregistrement DNS de façon à ce que les nouvelles connexions clientes soient acheminées vers le nouveau serveur primaire seulement après l’actualisation du cache DNS. Étant donné que l’instance secondaire partage la même zone DNS que l’instance principale, l’application cliente peut se reconnecter à l’aide du même certificat SAN côté serveur. Les connexions clientes existantes doivent être arrêtées, puis recréées pour être acheminées vers le nouveau serveur principal. L’écouteur en lecture/écriture et l’écouteur en lecture seule ne peuvent pas être joints via le point de terminaison public pour une instance gérée.

Utiliser l'écouteur en lecture seule (instance managée 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 l’instance géosecondaire. Pour vous connecter directement à l’instance géosecondaire, utilisez <fog-name>.secondary.<zone_id>.database.windows.net comme nom de serveur.

Dans le niveau Critique pour l’entreprise, SQL Managed Instance 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 dans la chaîne de connexion. Lorsque vous avez configuré une instance géorépliquée secondaire, 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 primaire, utilisez ApplicationIntent=ReadOnly et <fog-name>.<zone_id>.database.windows.net.
  • Pour vous connecter à un réplica en lecture seule à l’emplacement secondaire, utilisez ApplicationIntent=ReadOnly et <fog-name>.secondary.<zone_id>.database.windows.net.

L’écouteur en lecture/écriture et l’écouteur en lecture seule ne peuvent pas être joints via le point de terminaison public pour une instance gérée.

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 secondaire, la latence entre les composants dépendants peut augmenter. Vérifiez que tous les composants de l’application sont redondants dans la région secondaire et basculez les composants de l’application en même temps que la base de données afin que les performances de l’application ne soient pas affectées par une latence inter-régionale plus élevée.

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. Le basculement est différé pendant la période que vous spécifiez à l’aide du paramètre GracePeriodWithDataLossHours. Si vous avez configuré la stratégie de basculement automatique, préparez-vous à une perte de données. En général, en cas de panne, Azure favorise la disponibilité. 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.

Mise à jour DNS

La mise à jour DNS de l’écouteur en lecture-écriture se produit immédiatement après que le basculement est initié. Cette opération n’entraîne pas de perte de données. Toutefois, le processus de basculement des rôles des bases de données peut prendre jusqu’à 5 minutes dans des conditions normales. En attendant, certaines bases de données de la nouvelle instance principale resteront en lecture seule. Si un basculement est initié à l’aide de PowerShell, l’opération permettant de basculer le rôle de réplica principal est synchrone. S’il est initié à l’aide du portail Azure, l’interface utilisateur indiquera la progression. S’il est démarré à l’aide de l’API REST, utilisez le mécanisme d’interrogation standard d’Azure Resource Manager pour en surveiller la progression.

Important

Utilisez le basculement planifié manuel pour ramener le réplica principal à l’emplacement d’origine une fois que la panne qui a provoqué le géobasculement est réparée.

Activer les scénarios dépendant des objets des bases de données système

Les bases de données système ne sont pas répliquées vers l’instance secondaire dans un groupe de basculement. Pour permettre les scénarios qui dépendent des objets des bases de données système, assurez-vous de créer les mêmes objets sur l’instance secondaire et de les maintenir synchronisés avec ceux de l’instance primaire.

Par exemple, si vous envisagez d’utiliser les mêmes connexions sur l’instance secondaire, veillez à les créer avec un ID de sécurité identique.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Pour en savoir plus, consultez Réplication des connexions et des tâches de l’agent.

Synchronisation des propriétés des instances et des instances de stratégies de rétention

Les instances d’un groupe de basculement restent des ressources Azure distinctes, et aucune modification apportée à la configuration de l’instance primaire n’est automatiquement répliquée sur l’instance secondaire. Veillez à effectuer toutes les modifications pertinentes à la fois sur l’instance primaire et sur l’instance secondaire. Par exemple, si vous modifiez la redondance du stockage de sauvegarde ou la stratégie de rétention des sauvegardes à long terme sur l’instance primaire, veillez à la modifier également sur l’instance secondaire.

Mise à l’échelle des instances

Vous pouvez faire un scale-up ou scale-down de l’instance primaire et secondaire à une taille de calcul différente au sein du même niveau de service. 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 une instance à un niveau de service supérieur ou inférieur, cette recommandation s’applique.

La 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.

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 SQL Managed Instance, notez 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.

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.

État du groupe de basculement

Le groupe de basculement automatique signale son état qui décrit l’état actuel de la réplication des données :

  • Amorçage : Amorçage initial a lieu après la création du groupe de basculement, jusqu’à ce que toutes les bases de données utilisateur soient initialisées sur l’instance secondaire. Impossible de démarrer le processus de basculement lorsque le groupe de basculement automatique est dans l’état d’amorçage, car les bases de données utilisateur ne sont pas encore copiées vers l’instance secondaire.
  • Synchronisation : état habituel du groupe de basculement automatique. Cela signifie que les modifications de données sur l’instance principale sont répliquées de façon asynchrone sur l’instance secondaire. Cet état ne garantit pas que les données sont entièrement synchronisées à tout moment. Des modifications de données de la base de données principale peuvent toujours être répliquées sur la base de données secondaire en raison de la nature asynchrone du processus de réplication entre les instances dans le groupe de basculement automatique. Les basculements automatiques et manuels peuvent être lancés alors que le groupe de basculement automatique est dans l’état Synchronisation en cours.
  • Basculement en cours : cet état indique qu’un processus de basculement automatique ou manuel est en cours. Aucune modification du groupe de basculement ou des basculements supplémentaires ne peut être lancée lorsque le groupe de basculement automatique est dans cet état.

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 Managed Instance 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 Managed Instance.

Limites

Notez les limitations suivantes :

  • Il n’est pas possible de créer des groupes de basculement entre deux instances 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.
  • Un groupe de basculement contient exactement deux instances managées. L’ajout d’instances supplémentaires au groupe de basculement n’est pas pris en charge.
  • Une instance ne peut participer qu’à un seul groupe de basculement à tout moment.
  • 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 devez supprimer temporairement le groupe de basculement pour pouvoir renommer une base de données.
  • Les bases de données système ne sont pas répliquées vers l’instance secondaire dans un groupe de basculement. Par conséquent, les scénarios qui dépendent des objets des bases de données système (tels que les identifiants de serveurs ou des travaux d’agent) requièrent que les objets soient créés manuellement sur les instances secondaires et soient également synchronisés manuellement après toute modification apportée à l’instance principale. La seule exception est la clé principale de Service (SMK) pour SQL Managed Instance, qui est répliquée automatiquement vers l’instance secondaire lors de la création du groupe de basculement. Toutefois, toute modification ultérieure de SMK sur l’instance principale ne sera pas répliquée vers l’instance secondaire. Pour en savoir plus, découvrez comment activer les scénarios dépendant des objets des bases de données système.
  • Les groupes de basculement ne peuvent pas être créés entre des instances si l’un d’eux se trouve dans un pool d’instances.

Gérer programmatiquement des groupes de basculement

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-AzSqlDatabaseInstanceFailoverGroup Cette commande crée un groupe de basculement et l’enregistre dans les instances principale et secondaire
Set-AzSqlDatabaseInstanceFailoverGroup Modifie la configuration d’un groupe de basculement
Get-AzSqlDatabaseInstanceFailoverGroup Récupère la configuration d’un groupe de basculement
Switch-AzSqlDatabaseInstanceFailoverGroup Déclenche le basculement d’un groupe de basculement vers l’instance secondaire
Remove-AzSqlDatabaseInstanceFailoverGroup Supprime un groupe de basculement

Étapes suivantes