Configurer un groupe de basculement pour Azure SQL Managed Instance
S’applique à : 
Azure SQL Managed Instance
Cet article explique comment configurer un groupe de basculement pour Azure SQL Managed Instance à l’aide du portail Azure et d’Azure PowerShell.
Pour qu’un script PowerShell de bout en bout crée les deux instances dans un groupe de basculement, consultez Ajouter une instance à un groupe de basculement avec PowerShell.
Prérequis
Pour configurer un groupe de basculement, vous devez déjà disposer d’une instance SQL Managed Instance que vous avez l’intention d’utiliser comme instance principale. Consultez la section Créer une instance pour commencer.
Exigences de configuration
Pour configurer un groupe de basculement entre une instance SQL Managed Instance principale et une instance secondaire, tenez compte des exigences suivantes :
- L’instance gérée secondaire doit être vide, sans aucune base de données utilisateur.
- Les deux instances doivent avoir le même niveau de service et la même capacité de stockage. Bien que cela ne soit pas obligatoire, il est fortement recommandé que les deux instances aient la même taille de calcul afin que l’instance secondaire puisse traiter durablement les modifications répliquées à partir de l’instance principale, y compris pendant les périodes de pic d’activité.
- La plage d’adresses IP pour le réseau virtuel de l’instance principale ne doit pas chevaucher la plage d’adresses du réseau virtuel pour l’instance gérée secondaire ou avec tout autre réseau virtuel appairé avec le réseau virtuel principal ou secondaire.
- Les deux instances doivent se trouver dans la même zone DNS. Lorsque vous créez votre instance secondaire gérée, vous devez spécifier l’ID de la zone DNS de l’instance principale. Si vous ne le faites pas, l’ID de zone est généré sous forme de chaîne aléatoire lors de la création de la première instance dans chaque réseau virtuel, et le même ID est attribué à toutes les autres instances dans le même sous-réseau. Une fois attribué, la zone DNS ne peut pas être modifiée.
- Les règles de groupes de sécurité réseau (NSG) pour les sous-réseaux des deux instances doivent avoir des connexions TCP entrantes et sortantes ouvertes pour le port 5022 et la plage de ports 11000-11999 pour faciliter la communication entre les deux instances.
- Pour des raisons de performance, les instances gérées doivent être déployées dans des régions jumelées. Les instances gérées qui résident dans des régions jumelées géographiquement bénéficient d’une vitesse de géoréplication sensiblement supérieure à celle de la géoréplication entre régions non jumelées.
- Les deux instances doivent utiliser la même stratégie de mise à jour.
Créer l’instance secondaire
Lorsque vous créez l’instance secondaire, vous devez utiliser un réseau virtuel qui a un espace d’adressage IP qui ne chevauche pas la plage d’espace d’adressage IP de l’instance principale. En outre, lorsque vous configurez la nouvelle instance secondaire, vous devez spécifier l’ID de zone de l’instance principale.
Vous pouvez configurer le réseau virtuel secondaire et créer l’instance secondaire à l’aide du portail Azure et de PowerShell.
Création d’un réseau virtuel
Pour créer un réseau virtuel pour votre instance secondaire dans le portail Azure, procédez comme suit :
Vérifiez l’espace d’adressage de l’instance principale. Accédez à la ressource de réseau virtuel pour l’instance principale dans le portail Azure et, sous Paramètres, sélectionnez Espace d’adressage. Vérifiez la plage sous Plage d’adresses :
Créez un nouveau réseau virtuel que vous prévoyez d’utiliser pour l’instance secondaire en accédant à la page Créer un réseau virtuel.
Sous l’onglet Informations de base de la page Créer un réseau virtuel :
- Sélectionnez le groupe de ressources que vous envisagez d’utiliser pour l’instance secondaire. Créez-en un nouveau s’il n’existe pas encore.
- Donnez un nom à votre réseau virtuel, par exemple
vnet-sql-mi-secondary. - Sélectionnez une région associée à la région où se trouve l’instance principale.
Sous l’onglet Adresses IP de la page Créer un réseau virtuel :
- Utilisez Supprimer l’espace d’adressage pour supprimer l’espace d’adressage IPv4 existant.
- Une fois l’espace d’adressage supprimé, sélectionnez Ajouter un espace d’adressage IPv4 pour ajouter un nouvel espace, puis fournissez un espace d’adressage IP différent de l’espace d’adressage utilisé par le réseau virtuel de l’instance principale. Par exemple, si votre instance principale actuelle utilise un espace d’adressage de 10.0.0.16, entrez
10.1.0.0/16pour l’espace d’adressage du réseau virtuel que vous avez l’intention d’utiliser pour l’instance secondaire. - Utilisez + Ajouter un sous-réseau pour ajouter un sous-réseau par défaut avec des valeurs par défaut.
- Utilisez + Ajouter un sous-réseau pour ajouter un sous-réseau vide nommé
ManagedInstancequi sera dédié à l’instance secondaire, en utilisant une plage d’adresses différente du sous-réseau par défaut. Par exemple, si votre instance principale utilise une plage d’adresses de 10.0.0.0 – 10.0.255.255, indiquez une plage de sous-réseaux de10.1.1.0 - 10.1.1.255pour le sous-réseau de l’instance secondaire.
Utilisez Vérifier + Créer pour passer en revue vos paramètres, puis utilisez Créer pour créer votre nouveau réseau virtuel.
Créer une instance secondaire
Une fois que votre réseau virtuel est prêt, suivez ces étapes pour créer votre instance secondaire dans le portail Azure :
Accédez à Créer une Azure SQL Managed Instance dans le Portail Azure.
Dans l’onglet Bases de la page Créer Create Azure SQL Managed Instance :
- Choisissez une région pour votre instance secondaire qui est associée à l’instance principale.
- Choisissez un niveau de service correspondant à celui de l’instance principale.
Sous l’onglet Mise en réseau de la page Créer une instance Azure SQL Managed Instance, utilisez la liste déroulante sous Réseau virtuel/sous-réseau pour sélectionner le réseau virtuel et le sous-réseau que vous avez précédemment créés :
Sous l’onglet Paramètres supplémentaires de la page Créer une instance Azure SQL Managed Instance, sélectionnez Oui pour Utiliser comme secondaire de basculement, puis choisissez l’instance principale appropriée dans la liste déroulante.
Configurez le reste de l’instance en fonction des besoins de votre entreprise, puis créez-la en cliquant sur Vérifier + Créer.
Établir la connectivité entre les instances
Pour un flux de trafic de géoréplication ininterrompu, vous devez établir la connectivité entre les sous-réseaux du réseau virtuel qui hébergent les instances principale et secondaire. Il existe plusieurs façons de connecter des instances gérées situées dans des régions Azure différentes :
- Appairage global de réseaux virtuels
- Azure ExpressRoute
- Passerelles VPN
Un appairage de réseaux virtuels est recommandé comme un moyen solide d’établir la connectivité entre les instances dans un groupe de basculement. L’appairage de réseaux virtuels fournit une connexion privée à faible latence et à bande passante élevée entre des réseaux virtuels appairés à l’aide de l’infrastructure principale de Microsoft. Aucun chiffrement supplémentaire, aucune connexion Internet publique, ni passerelle ne sont nécessaires pour que les réseaux virtuels appairés communiquent.
Important
Les autres façons de connecter des instances impliquant des appareils réseau supplémentaires peuvent compliquer la résolution des problèmes de connectivité ou de vitesse de réplication, ce qui peut nécessiter une implication active des administrateurs réseau et éventuellement prolonger considérablement le temps de résolution.
Si vous utilisez un mécanisme pour établir la connectivité entre les instances autre que l’appairage de réseaux virtuels mondial recommandé, vous devez vérifier ce qui suit :
- L’appareil réseau, comme les pare-feu ou les appliances virtuelles de réseau (NVA), ne bloque pas le trafic sur les connexions entrantes et sortantes pour le port 5022 (TCP) et la plage de ports 11000-11999.
- Le routage est correctement configuré et que le routage asymétrique est évité.
- Si vous déployez des groupes de basculement dans une topologie de réseau en étoile inter-région, pour éviter les problèmes de connectivité et de vitesse de réplication, le trafic de réplication doit circuler directement entre les deux sous-réseaux de l’instance gérée au lieu d’être dirigé via les réseaux hub.
Cet article vous guide pour configurer l’appairage de réseaux virtuels mondial entre les réseaux des deux instances en utilisant le portail Azure et PowerShell.
Dans le portail Azure, accédez à la ressource Réseau virtuel pour votre instance gérée principale.
Sélectionnez Peerings sous Paramètres pour ouvrir la page Peerings, puis utilisez + Ajouter dans la barre de commandes pour ouvrir la page Ajouter un peering.
Sur la page Ajouter un peering, entrez ou sélectionnez des valeurs pour les paramètres suivants :
Paramètres Description Résumé du réseau virtuel distant Nom du lien de peering Le nom du peering doit être unique dans le réseau virtuel. Cet article utilise Fog-peering.Modèle de déploiement de réseau virtuel Sélectionnez Resource Manager. Je connais mon ID de ressource Vous pouvez ne pas cocher cette case, sauf si vous connaissez l’ID de la ressource. Abonnement Sélectionnez l’abonnement dans la liste déroulante. Réseau virtuel Sélectionnez le réseau virtuel de l’instance secondaire dans la liste déroulante. Paramètres d’appairage de réseaux virtuels distants Autoriser le « réseau virtuel secondaire » à accéder au « réseau virtuel principal » Cochez la case pour autoriser la communication entre les deux réseaux. L’activation de la communication entre les réseaux virtuels permet aux ressources connectées à ceux-ci de communiquer entre elles avec les mêmes bande passante et latence que si elles étaient connectées au même réseau virtuel. Toute communication entre les ressources des deux réseaux virtuels passe par le réseau privé Azure. Autoriser le « réseau virtuel secondaire » à recevoir le trafic transféré du « réseau virtuel principal » Vous pouvez cocher ou décocher cette case, l’une ou l’autre fonctionne pour ce guide. Pour plus d’informations, consultez Créer un peering. Autoriser la passerelle ou le serveur de routes du « réseau virtuel secondaire » à transférer le trafic vers le « réseau virtuel principal » Vous pouvez cocher ou décocher cette case, l’une ou l’autre fonctionne pour ce guide. Pour plus d’informations, consultez Créer un peering. Autoriser le « réseau virtuel secondaire » à utiliser la passerelle ou le serveur de routes distant du « réseau virtuel principal » Laissez cette case désactivée. Pour plus d’informations sur les autres options disponibles, consultez Créer un peering. Résumé du réseau virtuel local Nom du lien de peering Le nom du même « peering » utilisé pour le réseau virtuel distant. Cet article utilise Fog-peering.Autoriser le « réseau virtuel principal » à accéder au « réseau virtuel secondaire » Cochez la case pour autoriser la communication entre les deux réseaux. L’activation de la communication entre les réseaux virtuels permet aux ressources connectées à ceux-ci de communiquer entre elles avec les mêmes bande passante et latence que si elles étaient connectées au même réseau virtuel. Toute communication entre les ressources des deux réseaux virtuels passe par le réseau privé Azure. Autoriser le « réseau virtuel principal » à recevoir le trafic transféré du « réseau virtuel secondaire » Vous pouvez cocher ou décocher cette case, l’une ou l’autre fonctionne pour ce guide. Pour plus d’informations, consultez Créer un peering. Autoriser la passerelle ou le serveur de routes du « réseau virtuel principal » à transférer le trafic vers le « réseau virtuel secondaire » Vous pouvez cocher ou décocher cette case, l’une ou l’autre fonctionne pour ce guide. Pour plus d’informations, consultez Créer un peering. Autoriser le « réseau virtuel principal » à utiliser la passerelle ou le serveur de routes distant du « réseau virtuel secondaire » Laissez cette case désactivée. Pour plus d’informations sur les autres options disponibles, consultez Créer un peering. Utilisez Ajouter pour configurer le peering avec le réseau virtuel que vous avez sélectionné, et revenez automatiquement à la page Peerings, qui montre que les deux réseaux sont connectés :
Configurer les ports et les règles NSG
Quel que soit le mécanisme de connectivité choisi entre les deux instances, vos réseaux doivent répondre aux exigences suivantes pour le flux du trafic de géoréplication :
- La table de route et les groupes de sécurité réseau attribués aux sous-réseaux de l’instance managée ne sont pas partagés entre les deux réseaux virtuels appairés.
- Les règles du groupe de sécurité réseau (NSG) sur les deux sous-réseaux qui hébergent chaque instance autorisent le trafic entrant et sortant vers l’autre instance sur le port 5022 et la plage de ports 11000-11999.
Vous pouvez configurer vos règles de communication de port et de NSG en utilisant le portail Azure et PowerShell.
Pour ouvrir les ports du groupe de sécurité réseau (NSG) dans le portail Azure, procédez comme suit :
Accédez à la ressource Groupe de sécurité réseau de l’instance principale.
Sous Paramètres, sélectionnez Règles de sécurité de trafic entrant. Vérifiez si vous avez déjà des règles qui autorisent le trafic pour le port 5022 et la plage 11000-11999. Si c’est le cas et que la source répond aux besoins de votre entreprise, ignorez cette étape. Si les règles n’existent pas, ou si vous voulez utiliser une source différente (comme l’adresse IP plus sécurisée), supprimez la règle existante, puis sélectionnez + Ajouter dans la barre de commandes pour ouvrir la page Ajouter une règle de sécurité de trafic entrant :
Sur la page Ajouter une règle de sécurité de trafic entrant, entrez ou sélectionnez des valeurs pour les paramètres suivants :
Paramètres Valeur recommandée Description Source Adresses IP ou étiquette de service Le filtre pour la source de la communication. L’adresse IP est la plus sécurisée et est recommandée pour les environnements de production. L’étiquette de service est appropriée pour les environnements hors production. Balise du service source Si vous avez sélectionné Étiquette de service comme source, indiquez VirtualNetworkcomme étiquette source.Les étiquettes par défaut sont des identifiants prédéfinis qui représentent une catégorie d’adresses IP. L’étiquette VirtualNetwork désigne tous les espaces d’adressage de réseau virtuel et local. Adresses IP sources Si vous avez sélectionné Adresses IP comme source, indiquez l’adresse IP de l’instance secondaire. Fournissez une plage d’adresses en utilisant la notation CIDR (par exemple 192.168.99.0/24 ou 2001:1234::/64), ou une adresse IP (par exemple 192.168.99.0 ou 2001:1234::). Vous pouvez également fournir une liste d’adresses IP ou de plages d’adresses séparées par des virgules, en utilisant IPv4 ou IPv6. Plages de ports source 5022 Cela permet de spécifier les ports sur lesquels le trafic sera autorisé par cette règle. Service Custom Le service spécifie la plage de ports et le protocole de destination pour cette règle. Plages de ports de destination 5022 Cela permet de spécifier les ports sur lesquels le trafic sera autorisé par cette règle. Ce port doit correspondre à la plage de ports source. Action Autoriser Autorise la communication sur le port spécifié. Protocole TCP Détermine le protocole de communication du port. Priorité 1200 Les règles sont traitées dans l’ordre de priorité ; plus le nombre est petit, plus la priorité est élevée. Nom allow_geodr_inbound nom de la règle. Description Facultatif Vous pouvez choisir de fournir une description ou de laisser ce champ vide. Sélectionnez Ajouter pour enregistrer vos paramètres et ajouter votre nouvelle règle.
Répétez ces étapes pour ajouter une autre règle de sécurité de trafic entrant pour la plage de ports
11000-11999avec un nom tel que allow_redirect_inbound et une priorité légèrement supérieure à celle de la règle 5022, telle que1100.Sous Paramètres, sélectionnez Règles de sécurité de trafic sortant. Vérifiez si vous avez déjà des règles qui autorisent le trafic pour le port 5022 et la plage 11000-11999. Si c’est le cas et que la source répond aux besoins de votre entreprise, ignorez cette étape. Si les règles n’existent pas, ou si vous voulez utiliser une source différente (telle que l’adresse IP plus sécurisée), supprimez la règle existante, puis sélectionnez + Ajouter dans la barre de commandes pour ouvrir la page Ajouter une règle de sécurité de trafic sortant.
Dans la page Ajouter une règle de sécurité de trafic sortant, utilisez la même configuration pour le port 5022 et la plage
11000-11999que pour les ports de trafic entrant.Accédez au groupe de sécurité réseau de l’instance secondaire et répétez ces étapes de manière à ce que les deux groupes de sécurité réseau disposent des règles suivantes :
- Autoriser le trafic entrant sur le port 5022
- Autoriser le trafic entrant sur la plage de ports
11000-11999 - Autoriser le trafic sortant sur le port 5022
- Autoriser le trafic sortant sur la plage de ports
11000-11999
Créer le groupe de basculement
Créez le groupe de basculement pour vos instances gérées à l’aide du portail Azure ou de PowerShell.
Créez le groupe de basculement pour vos instances gérées SQL à l’aide du portail Azure ou de PowerShell.
Dans le menu de gauche du Portail Azure, sélectionnez Azure SQL. Si Azure SQL ne figure pas dans la liste, sélectionnez Tous les services, puis tapez « Azure SQL » dans la zone de recherche. (Facultatif) Sélectionnez l’étoile en regard d’Azure SQL pour l’ajouter en tant qu’élément favori dans le volet de navigation de gauche.
Sélectionnez l’instance managée principale que vous souhaitez ajouter au groupe de basculement.
Sous Gestion des données, sélectionnez Groupes de basculement, puis utilisez Ajouter un groupe pour ouvrir la page Groupe de basculement d’instance :
Sur la page Groupe de basculement d’instance :
- L’Instance gérée principale est présélectionnée.
- Sous Nom du groupe de basculement, saisissez un nom pour le groupe de basculement.
- Sous Instance gérée secondaire, sélectionnez l’instance gérée que vous voulez utiliser comme secondaire dans le groupe de basculement.
- Choisissez une stratégie de basculement en lecture/écriture dans la liste déroulante. Manuel est recommandé pour vous permettre de contrôler le basculement.
- Laissez Activer les droits de basculement sur Désactivé, sauf si vous avez l’intention d’utiliser ce réplica uniquement pour la récupération d’urgence.
- Utilisez Créer pour enregistrer vos paramètres et créer votre groupe de basculement.
Une fois que le déploiement du groupe de basculement a commencé, vous êtes redirigé vers la page Groupes de basculement. La page est actualisée pour vous montrer le nouveau groupe de basculement une fois le déploiement terminé.
Test de basculement
Testez le basculement de votre groupe de basculement à l’aide du portail Azure ou de PowerShell.
Remarque
Si les instances se trouvent dans différents abonnements ou groupes de ressources, initiez le basculement à partir de l’instance secondaire.
Testez le basculement de votre groupe de basculement à l’aide du portail Azure.
Accédez à l’instance gérée principale ou secondaire dans le Portail Azure.
Sous Gestion des données, sélectionnez Groupes de basculement.
Dans la page Groupes de basculement, notez quelle instance est l’instance principale et quelle instance est l’instance secondaire.
Dans la page Groupes de basculement, sélectionnez Basculement dans la barre de commande. Sélectionnez Oui dans l’avertissement concernant la déconnexion des sessions TDS et notez les implications en termes de licence.
Dans la page Groupes de basculement, une fois que le basculement a réussi, les instances échangent les rôles de sorte que l’instance secondaire précédente devient la nouvelle instance principale et que l’instance principale précédente devient la nouvelle instance secondaire.
Important
Si les rôles n’ont pas changé, vérifiez la connectivité entre les instances et les règles de groupe de sécurité réseau et de pare-feu associées. Ne passez à l’étape suivante qu’après la permutation des rôles.
(Facultatif) Dans la page Groupes de basculement, utilisez Basculement pour inverser les rôles afin que l’instance principale d’origine redevienne l’instance principale.
Localiser le point de terminaison de l’écouteur
Une fois votre groupe de basculement configuré, mettez à jour la chaîne de connexion de votre application pour qu’elle pointe vers le point de terminaison de l’écouteur en lecture et en écriture afin que votre application continue à se connecter à l’instance principale, quelle qu’elle soit, après le basculement. En utilisant le point de terminaison de l’écouteur, vous n’avez pas besoin de mettre à jour manuellement votre chaîne de connexion chaque fois que votre groupe de basculement bascule, car le trafic est toujours acheminé vers le serveur principal actuel. Vous pouvez également pointer la charge de travail en lecture seule vers le point de terminaison de l’écouteur en lecture seule.
Pour localiser le point de terminaison de l’écouteur dans le portail Azure, accédez à votre instance SQL Managed Instance et, sous Gestion des données, sélectionnez Groupes de basculement.
Faites défiler vers le bas pour trouver les points de terminaison de l’écouteur :
- Le point de terminaison de l’écouteur en lecture et en écriture, sous la forme de
fog-name.dns-zone.database.windows.net, achemine le trafic vers l’instance principale. - Le point de terminaison de l’écouteur en lecture seule, sous la forme de
fog-name.secondary.dns-zone.database.windows.net, achemine le trafic vers l’instance secondaire.
Créer un groupe de basculement entre des instances de différents abonnements
Vous pouvez créer un groupe de basculement entre des SQL Managed Instances dans deux abonnements différents, à condition que les abonnements soient associés au même locataire Microsoft Entra.
- Lorsque vous utilisez l’API PowerShell, vous pouvez le faire en spécifiant le paramètre
PartnerSubscriptionIdpour l’instance SQL Managed Instance secondaire. - Lors de l’utilisation de l’API REST, chaque ID d’instance inclus dans le paramètre
properties.managedInstancePairspeut avoir son propre ID d’abonnement. - Le portail Azure ne prend pas en charge la création de groupes de basculement sur différents abonnements.
Important
Le portail Azure ne prend pas en charge la création de groupes de basculement sur différents abonnements. Pour les groupes de basculement sur différents abonnements et/ou groupes de ressources, le basculement ne peut pas être lancé manuellement en utilisant le portail Azure depuis l’instance SQL Managed Instance principale. Initiez-le plutôt à partir de l’instance géosecondaire.
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.
Modifier la région secondaire
Supposons que l’instance A est l’instance principale, que l’instance B est l’instance secondaire existante et que l’instance C est la nouvelle instance secondaire dans la troisième région. Pour faire la transition, suivez ces étapes :
- Créez l’instance C avec la même taille que A et dans la même zone DNS.
- Supprimez le groupe de basculement entre les instances A et B. À ce stade, les tentatives de connexion commencent à échouer car les alias SQL des écouteurs du groupe de basculement ont été supprimés et la passerelle ne reconnaît pas le nom du groupe de basculement. Les bases de données secondaires sont déconnectées des bases de données primaires et deviennent des bases de données en lecture-écriture.
- Créez un groupe de basculement avec le même nom entre l’instance A et l’instance C. Suivez les instructions du guide à la configuration du groupe de basculement. Il s’agit d’une opération de taille de données qui se termine dès lors que toutes les bases de données de l’instance A ont été amorcées et synchronisées.
- Si vous n’en avez plus besoin, supprimez l’instance B pour éviter des frais inutiles.
Notes
Après l’étape 2 et tant que l’étape 3 n’est par terminée, les bases de données de l’instance A restent non protégées contre une défaillance irrémédiable de l’instance A.
Modifier la région primaire
Supposons que l’instance A est l’instance principale, que l’instance B est l’instance secondaire existante et que l’instance C est la nouvelle instance principale dans la troisième région. Pour faire la transition, suivez ces étapes :
- Créez l’instance C avec la même taille que B et dans la même zone DNS.
- Initiez un basculement manuel à partir de l’instance B pour en faire la nouvelle instance principale. L’instance A devient automatiquement la nouvelle instance secondaire.
- Supprimez le groupe de basculement entre les instances A et B. À ce stade, les tentatives de connexion à l’aide de points de terminaison de groupe de basculement échouent. Les bases de données secondaires sur A sont déconnectées des bases de données primaires et deviennent des bases de données en lecture-écriture.
- Créez un groupe de basculement portant le même nom entre les instances B et C. Il s’agit d’une opération de taille des données qui se termine lorsque toutes les bases de données de l’instance B sont amorcées et synchronisées avec l’instance C. À ce stade, les tentatives d’ouverture de session cessent d’échouer.
- Basculer manuellement pour commuter l’instance C vers le rôle primaire. L’instance B devient automatiquement la nouvelle instance secondaire.
- Si vous n’en avez plus besoin, supprimez l’instance A pour éviter des frais inutiles.
Attention
Après l’étape 3 et tant que l’étape 4 n’est par terminée, les bases de données de l’instance A restent non protégées contre une défaillance irrémédiable de l’instance A.
Important
Une fois le groupe de basculement supprimé, les enregistrements DNS des points de terminaison de l’écouteur sont également supprimés. À ce stade, il existe une probabilité non nulle qu’une personne crée un groupe de basculement avec le même nom. Étant donné que les noms de groupe de basculement doivent être globalement uniques, vous ne pourrez pas réutiliser le même nom. Pour réduire au minimum ce risque, n’utilisez pas des noms de groupe de basculement génériques.
Modifier la stratégie de mise à jour
Les instances d’un groupe de basculement doivent avoir des stratégies de mise à jour correspondantes. Pour activer la stratégie de mise à jour permanente sur les instances qui font partie d’un groupe de basculement, activez d’abord la stratégie de mise à jour permanente sur l’instance secondaire, attendez que la modification prenne effet, puis mettez à jour la stratégie pour l’instance principale.
Lors de la modification de la stratégie de mise à jour sur l’instance principale du groupe de basculement, l’instance bascule vers un autre nœud local (similaire aux opérations de gestion sur les instances qui ne font pas partie d’un groupe de basculement), elle ne provoque pas le basculement du groupe de basculement, en conservant l’instance principale dans le rôle principal.
Attention
Une fois que la stratégie de mise à jour est modifiée en Toujours à jour, il n’est plus possible de revenir à la stratégie de mise à jour de SQL Server 2022.
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 mettre à l’échelle les instances primaires et secondaires à une taille de calcul différente, supérieure ou inférieure (scale-up ou scale-down), au sein du même niveau de service ou vers un autre niveau de service. Lors du scale-up au sein du même niveau de service, commencez par la base de données géo-secondaire, puis terminez avec la base de données primaire. Lors du scale-down au sein du même niveau de service, inversez l’ordre : commencez par la base de données primaire, puis terminez par la base de données secondaire. Suivez la même séquence lorsque vous mettez à l’échelle une instance vers un autre niveau de service.
Cette séquence est recommandée dans le but d’éviter les problèmes de surcharge des bases de données secondaires avec une référence SKU inférieure, qui doivent alors être alimentées à nouveau lors de la mise à niveau ou du passage à une version antérieure.
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).
Le rôle Collaborateur SQL Managed Instance, limité aux groupes de ressources du serveur principal et de l’instance managée secondaire, est suffisant pour effectuer toutes les opérations de gestion sur les groupes de basculement.
Le tableau suivant fournit une vue granulaire des autorisations minimales requises et leurs niveaux d’étendue minimal requis respectifs pour les opérations de gestion sur les groupes de basculement :
| Opération de gestion | Permission | Portée |
|---|---|---|
| Créer/Mettre à jour un groupe de basculement | Microsoft.Sql/locations/instanceFailoverGroups/write |
Groupes de ressources d’une instance managée principale et secondaire |
| Créer/Mettre à jour un groupe de basculement | Microsoft.Sql/managedInstances/write |
Instance managée principale et secondaire |
| Faire basculer un groupe de basculement | Microsoft.Sql/locations/instanceFailoverGroups/failover/action |
Groupes de ressources d’une instance managée principale et secondaire |
| Forcer le groupe de basculement de basculement | Microsoft.Sql/locations/instanceFailoverGroups/forceFailoverAllowDataLoss/action |
Groupes de ressources d’une instance managée principale et secondaire |
| Suppression d’un groupe de basculement | Microsoft.Sql/locations/instanceFailoverGroups/delete |
Groupes de ressources d’une instance managée principale et secondaire |
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.
- Un groupe de basculement ne peut pas être créé entre deux instances appartenant à différents locataires Azure.
- La création d’un groupe de basculement entre deux instances dans des groupes de ressources ou des abonnements différents n’est prise en charge qu’avec Azure PowerShell, ou l’API REST, et non avec le portail Azure ou l’Azure CLI. Une fois le groupe de basculement créé, il est visible sur le portail Azure et toutes les opérations sont prises en charge sur le portail Azure ou à l’aide d’Azure CLI. Le basculement doit être initié à partir de l’instance secondaire.
- La création d’un groupe d’administration avec une instance configurée avec un lien d’instance gérée n’est actuellement pas prise en charge.
- 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 n’est 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.
- Pour les instances à l’intérieur d’un groupe de basculement, la modification du niveau de service vers ou depuis le niveau Usage général nouvelle génération n’est pas prise en charge. Vous devez d’abord supprimer le groupe de basculement avant de modifier l’une ou l’autre réplica, puis recréer le groupe de basculement une fois que la modification a pris effet.
- Les instances managées SQL d’un groupe de basculement doivent avoir la même stratégie de mise à jour, bien qu’il soit possible de modifier la stratégie de mise à jour pour les instances au sein d’un groupe de basculement.
Gérer programmatiquement des groupes de basculement
Les groupes de basculement 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. Les groupes de basculement comprennent un ensemble d’API Azure Resource Manager pour la gestion, notamment API REST de base de données Azure SQL et Azure PowerShell cmdlets. 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 |