Étendre un groupe de disponibilité Always On vers Azure SQL Managed Instance (aperçu)

S’applique à :Azure SQL Managed Instance

Cet article vous apprend comment étendre un groupe de disponibilité Always On avec plusieurs bases de données entre SQL Server et Azure SQL Managed Instance via le lien Managed Instance en utilisant SQL Server Management Studio (SSMS), PowerShell ou Azure CLI.

Cet article traite du mode liaison multi-bases de données, qui réplique toutes les bases de données d’un groupe de disponibilité via un seul lien. Le mode liaison à base de données unique réplique une base de données par lien.

Overview

Lorsque vous étendez un groupe de disponibilité Always On entre SQL Server et Azure SQL Managed Instance, vous créez un lien qui réplique plusieurs bases de données dans un groupe de disponibilité vers la réplique cible. Le lien utilise un groupe de disponibilité distribué pour répliquer les modifications en quasi-temps réel de la réplique primaire actuelle vers des copies de base de données en lecture seule sur la réplique secondaire. Cela garantit que les copies en lecture seule sur le secondaire restent up-todate avec le primaire.

Vous pouvez utiliser un groupe de disponibilité existant ou commencer avec des bases de données autonomes. Lorsque vous sélectionnez des bases de données autonomes dans SSMS, l’assistant crée un groupe de disponibilité à nœud unique sur le primaire initial et réplique les bases de données sélectionnées via un seul lien.

Soit SQL Server, soit Azure SQL Managed Instance peuvent être les premiers principaux. La création du lien depuis SQL Managed Instance nécessite SQL Server 2022 ou SQL Server 2025 avec la mise à jour cumulative requise et une politique de mise à jour SQL Managed Instance correspondante. Les exemples de création dans cet article commencent par SQL Server. Ils ne décrivent pas la procédure de création à partir de SQL Managed Instance. Le basculement avec inversion de rôle entre SQL Server et Azure SQL Managed Instance est pris en charge pour les instances configurées avec des politiques de mise à jour correspondantes.

Prise en charge

Les exigences suivantes s’appliquent à l’extension d’un groupe de disponibilité via un lien multi-bases de données lors de la prévisualisation. SQL Server sur Windows et Linux est pris en charge. Vous devez installer la mise à jour cumulative (CU) requise. Les versions plus anciennes ne supportent pas cette fonctionnalité.

Tenez compte des éléments suivants :

• L’édition standard n’est pas prise en charge car les groupes de disponibilité de base ne prennent en charge qu’une seule base de données.
• SQL Server 2019 et les versions antérieures ne sont pas prises en charge pour le mode lien multi-bases de données car elles manquent de la technologie requise introduite dans SQL Server 2022.
• Pour créer le lien à partir de SQL Managed Instance ou inverser de nouveau les rôles vers SQL Server, votre instance gérée SQL doit utiliser la stratégie de mise à jour qui correspond à votre version de SQL Server. Pour la réplication unidirectionnelle et le basculement depuis SQL Server, la politique de mise à jour de destination doit correspondre, voire supérieure, à votre version SQL Server.
  • SQL Server 2022 prend en charge la réplication vers des instances configurées avec les politiques SQL Server 2022, SQL Server 2025 et Always-up-to-date.
  • SQL Server 2025 prend en charge la réplication vers des instances configurées avec les politiques SQL Server 2025 et Always-up-to-date, mais pas SQL Server 2022. Vous ne pouvez pas répliquer les données ni revenir en arrière vers SQL Server après le basculement si les stratégies ne correspondent pas.

Pour les versions et éditions de SQL Server prenant en charge les liens à base de données unique, voir la prise en charge des versions de liens Managed Instance.

Prerequisites

Pour étendre votre groupe de disponibilité entre SQL Server et Azure SQL Managed Instance, vous avez besoin des prérequis suivants :

• Un abonnement Azure actif. Si vous n’en avez pas, créez un compte gratuit.
• Une version et une édition SQL Server prises en charge avec la mise à jour de service requise installée. Vous pouvez utiliser un groupe de disponibilité Always On existant ou des bases de données autonomes que SSMS place dans un nouveau groupe de disponibilité à nœud unique. Les groupes de disponibilité contenus ne sont pas pris en charge.
• Azure SQL Managed Instance avec une politique de mise à jour adaptée à votre scénario. Une politique de correspondance est requise lorsque SQL Managed Instance est la principale initiale ou pour l’inversion des rôles. Commencez si vous n’avez pas d’instance SQL gérée.
• SQL Server Management Studio (SSMS) 22.10.2 ou une version ultérieure.
• Pour la configuration scriptée, Azure PowerShell avec le module Az version 16.3.0 ou ultérieure et Az.SQL version 7.1.0 ou ultérieure, ou Azure CLI version 2.90.0 ou ultérieure. Vous pouvez également utiliser Azure Cloud Shell. Vérifiez que les modules installés ou la ligne de commande (CLI) respectent ces exigences de version.
• Un environnement correctement préparé.
• Pour un groupe de disponibilité à plusieurs nœuds, un écouteur de groupe de disponibilité configuré. Utilisez l'adresse IP de l'auditeur lors de la configuration du lien, et non l'adresse IP d'une réplique individuelle de SQL Server. Utiliser l’écouteur permet au lien de continuer à fonctionner après un basculement local du groupe de disponibilité.
• Aucun lien existant sur une quelconque réplique SQL Server lorsque vous activez le mode de liaison entre plusieurs bases de données. Avant de commencer, supprimez tous les liens qui utilisent l’ancien mode liaison à base de données unique.
• Capacité de base de données et stockage disponibles suffisants sur l’instance gérée cible pour toutes les bases de données de votre groupe de disponibilité. Examinez les limites de ressources.

Permissions

Pour SQL Server, vous avez besoin d’autorisations sysadmin.

Pour Azure SQL Managed Instance, vous devez être membre du rôle Contributeur SQL Managed Instance ou disposer des autorisations de rôle personnalisées suivantes :

Activer le mode liaison multi-bases de données

Le support du mode lien multi-bases de données est désactivé par défaut lors de l’aperçu. Utilisez la procédure stockée intégrée sys.sp_multidb_milink pour l’activer sur chaque réplice SQL Server du groupe de disponibilité, ou sur l’instance SQL Server où vous prévoyez de créer un groupe à nœud unique.

Exécutez la commande suivante sur chaque réplique SQL Server pour activer le mode liaison multi-bases de données :

EXEC sys.sp_multidb_milink 1;

Le paramètre persiste lors des redémarrages de SQL Server, donc il suffit de l’activer une fois sur chaque réplique.

Pour vérifier le paramétrage, exécutez la procédure stockée sans spécifier de paramètre sur chaque réplica. Il revient 1 lorsqu’il est activé et 0 désactivé :

EXEC sys.sp_multidb_milink;

Si la procédure stockée n'est pas disponible, vérifiez que la réplique dispose d'une version SQL Server prise en charge et d'une mise à jour cumulative installée.

Pour désactiver le mode liaison multi-bases de données, supprimez d’abord tous les liens, puis exécutez la commande suivante sur chaque réplique SQL Server :

EXEC sys.sp_multidb_milink 0;

Préparez les bases de données des groupes de disponibilité

Configurez chaque base de données SQL Server que vous souhaitez répliquer sur le modèle de récupération complet, puis créez une sauvegarde complète. Les bases de données existantes des groupes de disponibilité et les bases de données autonomes nécessitent cette préparation. Utilisez la procédure de sauvegarde SSMS dans le guide de configuration du lien.

Pour les bases de données SQL Server, migrez le certificat TDE vers SQL Managed Instance. Pour les bases de données SQL Managed Instance chiffrées liées à SQL Server, utilisez une clé gérée par le client accessible au SQL Server de destination. Consultez la préparation TDE de la liaison pour connaître les exigences dans chaque sens.

Le lien reproduit toutes les bases de données du groupe de disponibilité sélectionné. Vous ne pouvez pas choisir un sous-ensemble, donc vérifiez la capacité disponible de l’instance gérée SQL cible avant de créer le lien. La destination ne doit pas contenir de bases de données portant les mêmes noms que celles que vous souhaitez reproduire. Les bases de données existantes portant des noms différents sont autorisées, sous réserve des limites de capacité de l’instance.

La liaison prend uniquement en charge la réplication des bases de données utilisateur. La réplication des bases de données système n’est pas prise en charge. Pour répliquer des objets au niveau de l’instance, stockés dans master ou msdb, générez les scripts T-SQL correspondants et exécutez-les sur l’instance de destination.

Configurez l’auditeur et les certificats

Pour un groupe de disponibilité à plusieurs nœuds, utilisez l’adresse IP de l’auditeur lors de la configuration du lien, à la fois dans SSMS et dans des scripts. L’auditeur dirige les connexions vers la réplique primaire actuelle. N'utilisez pas l'adresse IP d'une réplique individuelle de SQL Server comme point d'extrémité partenaire du lien. Sans l’écouteur, le lien ne continue pas de fonctionner après un basculement du groupe de disponibilité local. Pour un groupe de disponibilité à nœud unique, y compris un créé par l'assistant SSMS pour des bases de données autonomes, utilisez le point de terminaison IP de cette instance de SQL Server.

L’assistant SSMS échange les certificats entre Azure SQL Managed Instance et uniquement la réplique principale actuelle du SQL Server. Il ne configure pas la confiance des certificats sur les autres répliques de SQL Server. Vous devez copier et configurer manuellement les certificats requis sur chaque autre réplique SQL Server afin que le lien puisse continuer à fonctionner après un basculement local du groupe de disponibilité. Cette étape manuelle s’applique à la fois au SSMS et à la configuration scriptée. Consultez Établir une relation de confiance entre les instances pour connaître les étapes de l’échange de certificats.

Préparez-vous à la création de liens scriptés

Utilisez SSMS pour l’expérience de configuration recommandée. L’assistant automatise de nombreuses étapes de configuration. Si vous n’avez pas besoin d’automatisation scriptée, passez cette section et continuez à l’onglet SSMS dans Étendre le groupe de disponibilité.

La configuration scriptée est une option avancée qui nécessite de l’expérience dans la configuration des groupes de disponibilité, des terminaux et de la confiance des certificats. Ne complétez ces étapes que si vous utilisez PowerShell ou Azure CLI avec SQL Server comme principal initial.

La checklist couvre à la fois les groupes de disponibilité existants et les bases de données autonomes. Après avoir préparé les bases de données, la confiance et les points de terminaison, réutilisez votre groupe de disponibilité existant ou créez-en un à l’étape 4. Ensuite, créez le groupe de disponibilité distribuée. Les commandes PowerShell et Azure CLI de création de liens ne créent pas le groupe de disponibilité pour vous.

Pour un script adapté à votre environnement, utilisez l’assistant de lien SSMS et sélectionnez Script sur sa page de résumé . Révisez le script généré et exécutez-le séparément.

1. Activez le mode liaison multi-bases de données sur chaque réplique SQL Server, ou sur l’instance autonome de SQL Server, et préparez les bases de données.
2. Établir la confiance entre les instances. Suivez les étapes de création de certificats, d’échange de clés publiques, d’importation de certificats racines et de validation de la chaîne de certificats. Pour un groupe à plusieurs nœuds, appliquez les exigences du certificat à chaque réplique SQL Server, pas seulement au principal actuel.
3. Sécurisez le point de terminaison de miroir de la base de données. Si votre groupe de disponibilité a déjà un point de terminaison, utilisez Modifier un point de terminaison existant au lieu d’en créer un autre. Conservez le port de terminaison configuré pour la commande de création de lien.
4. Préparez le groupe de disponibilité. Si vous avez déjà un groupe de disponibilité contenant toutes les bases de données que vous souhaitez répliquer, réutilisez-le et évitez la création d’un nouveau groupe. Si vous commencez avec des bases de données autonomes, créez d’abord un groupe de disponibilité sur SQL Server. Dans l’onglet primaire initial de SQL Server, utilisez l’exemple à CREATE AVAILABILITY GROUP nœud unique par CLUSTER_TYPE = NONE, mais remplacez FOR DATABASE [<DatabaseName>] par la liste complète de la base de données, comme FOR DATABASE [DB01], [DB03], [DB05], [DB07]. Définissez <AGNameOnSQLServer> le nom que vous souhaitez donner au nouveau groupe. Exécutez ce script avant de continuer à la création du groupe de disponibilité distribuée. Ne l’exécutez pas contre un groupe existant ni ne modifiez la configuration du cluster d’un groupe existant.
5. Créez le groupe de disponibilité distribuée sur SQL Server. Utilisez l’onglet principal initial de SQL Server et commencez par les instructions de création du groupe de disponibilité distribuée. Définissez <AGNameOnSQLServer> sur le groupe de disponibilité que vous avez réutilisé ou créé à l’étape précédente. Pour un groupe à plusieurs nœuds, utilisez l’adresse IP de l’auditeur pour <SQLServerIP>. Pour un groupe à nœud unique, utilisez le point de terminaison de l'instance de SQL Server. Conservez <DAGName> comme nom de lien et <AGNameOnSQLMI> comme nom de groupe de disponibilité d’instances gérées pour la commande de création ci-dessous.
6. Vérifiez les groupes de disponibilité sur SQL Server. Confirmez que le groupe de disponibilité Always On et le groupe de disponibilité distribué sont présents. Puis retournez à Étendre le groupe de disponibilité, sélectionnez PowerShell ou Azure CLI, et exécutez la commande de création multi-base de données dans cet article au lieu de la commande de base de données unique de l'autre guide.

Étendre le groupe de disponibilité

Pour conserver les enregistrements de journal nécessaires au seeding, l’approche recommandée consiste à activer le trace flag 12381 sur les compilations de SQL Server prises en charge avant de créer des liens, en particulier pour les grandes bases de données ou de nombreuses bases de données en mode liaison multi-bases. Cependant, cet indicateur n’est pas nécessaire et il existe d’autres mesures d’atténuation, listées dans Résoudre l’erreur 1412. Avec le drapeau activé, les sauvegardes de journal peuvent continuer, mais les enregistrements de journal conservés ne sont pas réutilisables. Surveillez la croissance des logs SQL Server et l’espace disque libre, et désactivez le drapeau dès que le seeding est terminé pour tous les liens créés.

Utilisez SSMS pour automatiser la création de liens, ou choisissez PowerShell ou Azure CLI pour une configuration scriptée avancée. Les exemples suivants utilisent SQL Server comme principal initial. Vous pouvez aussi commencer par SQL Managed Instance avec une politique de mise à jour correspondante, mais ce flux de création n'est pas abordé ici.

Pour la configuration scriptée, complétez les étapes de configuration scriptée pour réutiliser ou créer un groupe de disponibilité contenant toutes les bases de données que vous souhaitez reproduire, puis créez le groupe de disponibilité distribué avant d’exécuter la commande PowerShell ou Azure CLI. Alternativement, si vous commencez avec des bases de données autonomes, la procédure SSMS de cette section crée automatiquement le groupe de disponibilité à nœud unique dans le cadre de la mise en place du lien.

Pour le mode liaison multi-bases de données, spécifiez MultiDatabase explicitement dans les scripts et fournissez tous les noms de bases de données dans le groupe de disponibilité. PowerShell utilise SingleDatabase par défaut si -LinkMode est omis. À utiliser -LinkMode MultiDatabase dans PowerShell ou --link-mode MultiDatabase dans Azure CLI.

Update-Module -Name Az
Update-Module -Name Az.Sql

Get-InstalledModule -Name Az | Select-Object Name, Version
Get-InstalledModule -Name Az.Sql | Select-Object Name, Version

# Run in Azure Cloud Shell and select PowerShell.
$ManagedInstanceName = "<ManagedInstanceName>"

# Use the distributed availability group name from SQL Server as the link name.
# Use lowercase letters and hyphens, with no leading or trailing hyphen.
# The name must not already identify another link on this managed instance.
$DAGName = "<DAGName>"

# Enter the availability group names from the setup steps.
$AGNameOnSQLServer = "<AGNameOnSQLServer>"
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# Include every database in the availability group.
$DatabaseNames = @("DB01", "DB03", "DB05", "DB07")

# Use the listener IP for multiple-node AGs or the instance IP for single-node AGs.
$SQLEndpointIP = "<SQLEndpointIP>"
# Use the database mirroring endpoint port, normally 5022 unless customized.
$EndpointPort = "<EndpointPort>"

$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName
$SQLPartnerEndpoint = "TCP://" + $SQLEndpointIP + ":" + $EndpointPort

# Create the multi-database link with SQL Managed Instance as the secondary.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI -Database $DatabaseNames -PartnerEndpoint $SQLPartnerEndpoint -InstanceLinkRole "Secondary" -FailoverMode "Manual" -SeedingMode "Automatic" -LinkMode "MultiDatabase"

# Run in Azure Cloud Shell and select Bash.
ResourceGroupName="<ResourceGroupName>"
ManagedInstanceName="<ManagedInstanceName>"

# Use the distributed availability group name from SQL Server as the link name.
# Use lowercase letters and hyphens, with no leading or trailing hyphen.
# The name must not already identify another link on this managed instance.
DAGName="<DAGName>"

# Enter the availability group names from the setup steps.
AGNameOnSQLServer="<AGNameOnSQLServer>"
AGNameOnSQLMI="<AGNameOnSQLMI>"

# Include every database in the availability group.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB05},{database-name:DB07}]"

# Use the listener IP for multiple-node AGs or the instance IP for single-node AGs.
SQLEndpointIP="<SQLEndpointIP>"
# Use the database mirroring endpoint port, normally 5022 unless customized.
EndpointPort="<EndpointPort>"

SQLPartnerEndpoint="TCP://${SQLEndpointIP}:${EndpointPort}"

# Create the multi-database link with SQL Managed Instance as the secondary.
az sql mi link create --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --partner-availability-group-name "$AGNameOnSQLServer" --instance-availability-group-name "$AGNameOnSQLMI" --databases "$DatabaseNames" --partner-endpoint "$SQLPartnerEndpoint" --instance-link-role Secondary --failover-mode Manual --seeding-mode Automatic --link-mode MultiDatabase

Vérification de la réplication

Après avoir créé le lien ou ajouté des bases de données, les données se répliquent de la réplique primaire actuelle vers la réplique secondaire actuelle. Soit SQL Server, soit Azure SQL Managed Instance peuvent être les premiers principaux. Après l’inversion des rôles, les données se répliquent dans la direction opposée. Selon la taille de la base de données et la vitesse du réseau, chaque base peut initialement être en état de restauration sur la réplique secondaire. Une fois l’initialisation initiale terminée, la base de données est restaurée sur la réplique secondaire et prête pour les charges de travail en lecture seule.

Sur l’une ou l’autre réplique, utilisez Explorateur d'objets dans SSMS pour visualiser l’état synchronisé de chaque base de données répliquée. Développez Always On High Availability et Availability Groups pour afficher le groupe de disponibilité distribué créé pour le lien.

Lorsque SQL Server est principal, vous pouvez continuer les sauvegardes des journaux de transactions pendant le seeding si le flag de trace 12381 est activé sur une version prise en charge. Si vous mettez en pause les sauvegardes de journal pour éviter une troncature prématurée, reprenez-les après la fin du semis. Pour chaque base de données sans calendrier de sauvegarde de journal, ne faites la première sauvegarde du journal de transaction qu’après la fin de l’ensemencement initial, et non pendant le démarrage. Une fois le seeding terminé pour tous les liens créés, désactivez le drapeau si vous l’avez activé et prenez régulièrement des sauvegardes du journal des transactions de SQL Server tant que SQL Server reste le principal. Lorsque Azure SQL Managed Instance est principal, il effectue automatiquement les sauvegardes des journaux de transaction. Vous n'avez pas besoin de faire des sauvegardes manuelles de journaux SQL Server pour ces bases de données, alors que SQL Server est secondaire.

Une troncature prématurée du journal lors de l’amorçage peut provoquer les erreurs 1408 et 1412 dans le journal d’erreurs SQL Managed Instance. Dans les versions qui le prennent en charge, l’indicateur de trace 12381 empêche cette troncature. Désactivez-le une fois le seeding terminé pour tous les liens en cours de création, et surveillez l’utilisation du journal de transactions, le taux de croissance et l’espace disque libre pendant qu’il est activé. Les sauvegardes de journaux peuvent se poursuivre tant que les enregistrements requis restent conservés. Cette rétention ne remplace pas les sauvegardes régulières des journaux de transactions après l’amorçage. Voir Prévenir la troncature prématurée du log.

Ajouter des bases de données

Utilisez l'assistant SSMS pour ajouter des bases de données provenant du principal actuel, que ce soit SQL Server ou SQL Managed Instance. Le magicien automatise les changements nécessaires. Pour une automatisation avancée, utilisez PowerShell ou Azure CLI. L’ajout d’une base de données est une opération unique du côté primaire.

Avant d’ajouter des bases de données, vérifiez que le lien existant utilise le mode liaison multi-bases de données et que la destination dispose d’une capacité et d’un stockage suffisants disponibles, sans qu’aucun nom existant ne soit en conflit avec les nouvelles bases de données. Lorsque SQL Server est principal, configurez chaque nouvelle base de données qui n'est pas déjà dans le groupe de disponibilité vers le modèle de récupération complet, et créez une sauvegarde complète en utilisant la procédure de sauvegarde SSMS.

Ajouter des bases de données avec SSMS

Utilisez l’assistant Ajouter une base de données à Azure SQL Managed Instance Link pour ajouter des bases de données à un lien multidatabase existant :

1. Connectez-vous au principal actuel dans SSMS. Dans Explorateur d'objets, développez Always On Haute disponibilité et Groupes de disponibilité.

2. Faites un clic droit sur le groupe de disponibilité distribuée pour votre lien, survolez le lien Azure SQL Managed Instance, et sélectionnez Ajouter une base de données....

   

3. Procédez à Introduction et Connexion Azure, puis sélectionnez votre lien multi-base de données sur la page Sélectionner le lien.

4. Sur la page Sélectionner les bases de données , sélectionnez les bases de données que vous souhaitez ajouter. Vous ne pouvez ajouter que des bases de données avec un état Prêt . Les bases de données déjà présentes dans le lien sont indiquées comme Déjà partie du lien sélectionné. Résolvez tout problème d’éligibilité avant de continuer.

   

5. Terminez Validation et consultez Résumé. Sélectionnez Terminer pour exécuter le changement, ou sélectionnez Script pour générer un script sans exécuter le changement, afin de pouvoir le revoir, personnaliser et l’exécuter séparément. Si vous effectuez la modification dans l’assistant, consultez les Résultats avant de le fermer.

Ajouter des bases de données avec des scripts

Exécutez l’ajout sur le nœud principal actuel. Suivez les instructions pour ce cas.

Quand SQL Server est principal

Utilisez T-SQL pour ajouter chaque base de données au groupe de disponibilité. Le lien propage l’ajout à SQL Managed Instance. Aucune autre action n’est nécessaire sur SQL Managed Instance. N'utilisez pas de mise à jour PowerShell ou Azure CLI pour cette addition.

Quand SQL Managed Instance est la principale

Utilisez PowerShell ou Azure CLI pour mettre à jour le lien sur SQL Managed Instance. Le lien propage automatiquement les bases de données ajoutées au groupe de disponibilité. Aucune étape séparée sur SQL Server n’est requise. Fournissez l’adhésion complète prévue, y compris toutes les bases de données existantes que vous souhaitez conserver ainsi que les nouvelles bases de données. La liste fournie remplace les membres actuels. Omettre une base de données la retire de l’adhésion au lien.

Par exemple, pour ajouter DB09 lorsque le lien contient déjà DB01, DB03, DB05 et DB07, conservez ces quatre noms dans la liste, puis ajoutez DB09 à la liste. Remplacez les noms des ressources et de la base de données par vos valeurs.

# Include every existing database to retain and each new database to add.
$DatabaseNames = @("DB01", "DB03", "DB05", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include every existing database to retain and each new database to add.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB05},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Répétez les étapes de vérification de la réplication pour chaque nouvelle base de données ajoutée. Suivez les étapes de sauvegarde manuelle du journal des transactions uniquement lorsque SQL Server est le serveur principal.

Supprimer des bases de données

Utilisez l’assistant SSMS sur la primaire actuelle pour automatiser la suppression des deux côtés. Supprimer une base de données nécessite de la retirer du lien sur SQL Managed Instance et du groupe de disponibilité. Le retirer d’un seul côté ne complète pas l’opération.

Supprimer les bases de données avec SSMS

Les étapes suivantes s’appliquent que le SQL Server ou le SQL Managed Instance soit le principal :

1. Connectez-vous au principal actuel dans SSMS. Dans Explorateur d'objets, développez Always On Haute disponibilité et Groupes de disponibilité.

2. Faites un clic droit sur le groupe de disponibilité distribuée pour le lien, survolez le lien Azure SQL Managed Instance, et sélectionnez Supprimer la base de données....

   

3. Dans l’assistant Supprimer la base de données d’Azure SQL Managed Instance Link, parcourez Introduction et Azure Login, puis sélectionnez le lien sur Select Link.

4. Dans Select Databases, sélectionnez les bases de données à supprimer. Par exemple, sélectionnez DB05 pour la retirer du lien, puis sélectionnez Suivant.

   

5. Complétez la validation, consultez le Résumé, puis sélectionnez Terminer pour exécuter la suppression ou Script pour revoir d’abord les commandes générées. Vérifiez Résultats pour vous assurer que l’opération s’est terminée correctement avant de fermer l’assistant.

Supprimer les bases de données avec des scripts

Supprimez les bases de données des deux instances. Le primaire actuel détermine quelle instance mettre à jour en premier.

Les exemples PowerShell et Azure CLI utilisent les variables suivantes :

Quand SQL Server est principal

1. Utilisez T-SQL pour retirer les bases de données du groupe de disponibilité.
2. Utilisez PowerShell ou Azure CLI pour supprimer les bases de données du lien sur SQL Managed Instance, comme montré dans cette section.

Pour l’étape SQL Managed Instance, fournissez la liste complète des bases de données à conserver, en omettant uniquement celles que vous souhaitez supprimer. Par exemple, si le lien contient DB09, DB05, DB07, DB05 et DB03, la commande suivante supprime DB01 et conserve les quatre autres. Remplacez les noms des ressources et de la base de données par vos valeurs.

# Include only the databases to retain, excluding DB05.
$DatabaseNames = @("DB01", "DB03", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include only the databases to retain, excluding DB05.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Quand SQL Managed Instance est la principale

1. Utilisez PowerShell ou Azure CLI pour supprimer les bases de données du lien sur SQL Managed Instance, comme montré dans cette section.
2. Utilisez T-SQL sur SQL Server pour retirer les bases de données de son groupe de disponibilité. Le retrait n’est pas complet tant que vous n’avez pas terminé cette étape.

Pour l’étape SQL Managed Instance, fournissez la liste complète des bases de données à conserver, en omettant uniquement celles que vous souhaitez supprimer. Par exemple, si le lien contient DB09, DB05, DB07, DB05 et DB03, la commande suivante supprime DB01 et conserve les quatre autres. Remplacez les noms des ressources et de la base de données par vos valeurs.

# Include only the databases to retain, excluding DB05.
$DatabaseNames = @("DB01", "DB03", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include only the databases to retain, excluding DB05.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Confirmez que les bases de données supprimées n’appartiennent plus au lien ni au groupe de disponibilité. Retirer une base de données de la réplication n’est pas la même chose que supprimer sa copie conservée. Examinez les bases de données des deux instances avant de décider si vous devez supprimer une copie dont vous n’avez plus besoin.

Basculement ou passage vers Azure

Utilisez les procédures de basculement existantes dans SSMS ou dans des scripts pour permuter les rôles entre SQL Server et Azure SQL Managed Instance. L’inversion des rôles exige que l’instance gérée SQL utilise la politique de mise à jour correspondant à la version de votre SQL Server. Pour la réplication unidirectionnelle et le passage vers Azure SQL Managed Instance, sa politique de mise à jour doit correspondre ou être supérieure à votre version SQL Server. Vous ne pouvez pas répliquer les données ni revenir à SQL Server après coup si les politiques ne correspondent pas. Consultez les combinaisons prises en charge. Pour les conseils sur la migration et le changement, voir Migrer avec le lien.

Surveiller et résoudre les problèmes de réplication

Utilisez les vues de gestion dynamique (DMV) et la vue catalogue suivantes sur SQL Server pour vérifier le groupe principal de disponibilité, la connectivité des répliques et l'état de réplication de chaque base de données :

SELECT * FROM sys.availability_groups;
SELECT * FROM sys.dm_hadr_availability_replica_states;
SELECT * FROM sys.dm_hadr_database_replica_states;
SELECT * FROM sys.dm_hadr_internal_availability_groups;
SELECT * FROM sys.dm_hadr_internal_availability_replicas;

Si les DMV de réplication internes ne sont pas disponibles, ou si l'exécution de la sys.sp_multidb_milink procédure stockée indique qu'elle n'est pas disponible, vérifiez la version SQL Server installée et la mise à jour cumulative sur cette réplique. Pour résoudre les problèmes de connectivité générale et de réplication, consultez Résoudre les problèmes liés au lien Managed Instance.

Limitations

Considérez les limitations suivantes lors de l’extension d’un groupe de disponibilité via un lien multi-base de données :

• Les noms des liens doivent utiliser des lettres minuscules. Les traits d’union sont autorisés, mais un nom ne peut ni commencer ni se terminer par un trait d’union.
• Ne rétrogradez aucune réplique de SQL Server en dessous de SQL Server 2022 CU27 ou SQL Server 2025 CU9, selon le cas, tant qu'un lien en mode base de données multiple est actif. Le fait de revenir à une version inférieure au CU requis peut entraîner des problèmes imprévisibles, même sans basculement.
• Les groupes de disponibilité contenus ne sont pas pris en charge.
• Les liens à base de données unique et à plusieurs bases de données ne peuvent pas coexister sur la même instance de SQL Server.
• On ne peut pas changer le mode d’un lien en place. Pour passer des modes de lien à base de données unique et à plusieurs bases de données, supprimez tous les liens existants, changez le mode sur chaque réplique SQL Server, puis recréez les liens dans le nouveau mode.
• Lorsque vous créez un lien pour un groupe de disponibilité existant, toutes les bases de données de ce groupe doivent être répliquées. Vous ne pouvez pas sélectionner uniquement un sous-ensemble des bases de données de ce groupe.
• La capacité restante de la base de données sur l’instance gérée SQL cible limite le nombre de bases de données que vous pouvez répliquer. Les offres Usage général et Critique pour l’entreprise prennent en charge jusqu’à 100 bases de données par instance, et l’offre Usage général nouvelle génération prend en charge jusqu’à 500 bases de données par instance. Les bases de données existantes sont prises en compte dans ces limites. Par exemple, une instance avec une limite de 100 bases de données et 10 bases de données existantes a une capacité pour 90 bases de données supplémentaires. Pour plus d’informations, voir les limites de ressources.
• Ajouter des bases de données au groupe de disponibilité au-delà de la capacité disponible de la SQL managed instance cible peut réussir sur SQL Server, mais la réplication vers SQL Managed Instance échoue. Cette condition peut laisser le lien dans un état incohérent qui nécessite la suppression manuelle des bases de données non répliquées du groupe de disponibilité.
• L’ajout de bases de données se propage via le lien, mais supprimer une base de données d’un côté ne la supprime pas automatiquement de l’autre. Si vous retirez une base de données du groupe de disponibilité, sa copie reste sur SQL Managed Instance. Si vous retirez une base de données du lien sur SQL Managed Instance, la base de données reste dans le groupe de disponibilité sans réplication via le lien et nécessite un nettoyage manuel.
• Lors de l’ajout de bases de données à un lien existant via SSMS, vous ne pouvez ajouter que des bases de données en état Prêt . Vous ne pouvez pas ajouter de bases de données appartenant à un autre groupe de disponibilité ou ayant un nom déjà existant sur la destination.

Contenu connexe

• Vue d'ensemble du lien Managed Instance
• Préparer votre environnement en vue de la liaison
• Configurer la liaison avec SSMS
• Meilleures pratiques pour préserver la liaison
• résoudre les problèmes liés au lien