Een Always On availability group uitbreiden naar Azure SQL Managed Instance (preview)

Van toepassing op:Azure SQL Managed Instance

Dit artikel leert je hoe je een Always On-beschikbaarheidsgroep kunt uitbreiden met meerdere databases tussen SQL Server en Azure SQL Managed Instance met de Managed Instance-link door gebruik te maken van SQL Server Management Studio (SSMS), PowerShell of Azure CLI.

Dit artikel behandelt de multiple-database linkmodus, waarbij alle databases in een beschikbaarheidsgroep via één link worden gerepliceerd. De single-database linkmodus repliceert één database per link.

Overzicht

Wanneer je een Always On-beschikbaarheidsgroep uitbreidt tussen SQL Server en Azure SQL Managed Instance, maak je een link die meerdere databases in een beschikbaarheidsgroep repliceert naar de doelreplica. De koppeling gebruikt een gedistribueerde beschikbaarheidsgroep om wijzigingen bijna in realtime te repliceren van de huidige primaire replica naar alleen-lezen-databasekopieën op de secundaire replica. Dit zorgt ervoor dat de schrijfbeveiligde kopieën op de secundaire server up-to-date blijven met de primaire server.

Je kunt een bestaande beschikbaarheidsgroep gebruiken of beginnen met zelfstandige databases. Wanneer je standalone databases selecteert in SSMS, maakt de wizard een single-node beschikbaarheidsgroep aan op de initiële primaire database en repliceert de geselecteerde databases via één link.

Zowel SQL Server als Azure SQL Managed Instance kunnen de eerste primaire zijn. Het aanmaken van de link vanuit SQL Managed Instance vereist SQL Server 2022 of SQL Server 2025 met de vereiste cumulatieve update en een bijpassend SQL Managed Instance-updatebeleid. De creatievoorbeelden in dit artikel beginnen bij SQL Server. Ze lopen niet door de creatie vanuit een SQL Managed Instance. Failover met rolomkering tussen SQL Server en Azure SQL Managed Instance wordt ondersteund voor instanties waarvoor overeenkomend updatebeleid is geconfigureerd.

Supportability

De volgende vereisten gelden voor het uitbreiden van een beschikbaarheidsgroep via een multidatabase-link tijdens de preview. SQL Server op zowel Windows als Linux wordt ondersteund. Je moet de vereiste cumulatieve update (CU) installeren. Eerdere builds ondersteunen deze functie niet.

Houd rekening met het volgende:

• Standard edition wordt niet ondersteund omdat basic availability groups slechts één database ondersteunen.
• SQL Server 2019 en eerdere versies worden niet ondersteund voor de multiple-database link-modus omdat ze niet de benodigde technologie uit SQL Server 2022 hebben.
• Om de koppeling vanuit SQL Managed Instance te maken of de rollen terug te draaien naar SQL Server, moet uw SQL Managed Instance het updatebeleid gebruiken dat overeenkomt met uw SQL Server-versie. Voor eenrichtingsreplicatie en overgang vanuit SQL Server moet het bestemmingsupdatebeleid overeenkomen met, of hoger zijn dan, je SQL Server-versie.
  • SQL Server 2022 ondersteunt replicatie naar instanties die zijn geconfigureerd met de SQL Server 2022, SQL Server 2025 en Always-up-to-date-beleid.
  • SQL Server 2025 ondersteunt replicatie naar instanties die zijn geconfigureerd met de SQL Server 2025- en Always-up-to-date-beleidsregels, maar niet SQL Server 2022. Je kunt geen data repliceren of na een cutover niet teruggaan naar SQL Server als de beleidsregels niet overeenkomen.

Voor SQL Server-versies en edities die single-databaselinks ondersteunen, zie Managed Instance link versie-ondersteunbaarheid.

Prerequisites

Om je beschikbaarheidsgroep uit te breiden tussen SQL Server en Azure SQL Managed Instance, heb je de volgende vereisten nodig:

• Een actieve Azure-abonnement. Als je er geen hebt, maak een gratis account aan.
• Een ondersteunde SQL Server-versie en -editie met de vereiste service-update geïnstalleerd. Je kunt een bestaande Always On-beschikbaarheidsgroep of zelfstandige databases gebruiken die door SSMS in een nieuwe single-node beschikbaarheidsgroep worden geplaatst. Ingesloten beschikbaarheidsgroepen worden niet ondersteund.
• Azure SQL Managed Instance met een updatebeleid dat geschikt is voor jouw situatie. Een overeenkomend beleid is vereist wanneer SQL Managed Instance de oorspronkelijke primaire instantie is of bij rolwisseling. Begin als je geen SQL-beheerde instantie hebt.
• SQL Server Management Studio (SSMS) 22.10.2 of hoger.
• Voor gescripte configuratie gebruik ik Azure PowerShell met de Az-module versie 16.3.0 of later en Az.Sql versie 7.1.0 of later, of Azure CLI versie 2.90.0 of later. U kunt ook Azure Cloud Shell gebruiken. Controleer of de geïnstalleerde modules of CLI aan deze versievereisten voldoen.
• Een goed voorbereide omgeving.
• Voor een beschikbaarheidsgroep met meerdere knooppunten, een geconfigureerde beschikbaarheidsgroep-luisteraar. Gebruik het IP-adres van de luisteraar bij het configureren van de link, niet het IP-adres van een individuele SQL Server-replica. Door de luisteraar te gebruiken, blijft de link werken na een failover van de lokale beschikbaarheidsgroep.
• Geen bestaande links op een SQL Server-replica wanneer je de multiple-database linkmodus inschakelt. Verwijder voordat je begint alle links die de oudere single-database linkmodus gebruiken.
• Voldoende beschikbare databasecapaciteit en opslag op de doel-beheerde instantie voor alle databases in je beschikbaarheidsgroep. Bekijk de limieten van middelen.

Permissions

Voor SQL Server hebt u sysadmin-machtigingen nodig.

Voor Azure SQL Managed Instance moet u lid zijn van de rol SQL Managed Instance Inzender of de volgende aangepaste rolmachtigingen hebben:

Schakel de koppelingsmodus voor meerdere databases in

Ondersteuning voor de multiple-database link-modus is standaard uitgeschakeld tijdens de preview. Gebruik de ingebouwde sys.sp_multidb_milink stored procedure om deze in te schakelen op elke SQL Server-replica in de beschikbaarheidsgroep, of op de SQL Server-instantie waar je een single-node-groep wilt maken.

Voer het volgende commando uit op elke SQL Server-replica om de meervoudige databaselinkmodus in te schakelen:

EXEC sys.sp_multidb_milink 1;

De instelling blijft bestaan bij herstarts van SQL Server, dus je hoeft hem maar één keer per replica in te schakelen.

Om de instelling te controleren, voer je de opgeslagen procedure uit zonder een parameter op elke replica. Het keert terug 1 wanneer ingeschakeld en 0 wanneer uitgeschakeld:

EXEC sys.sp_multidb_milink;

Als de opgeslagen procedure niet beschikbaar is, controleer dan of de replica een ondersteunde SQL Server-versie en cumulatieve update heeft geïnstalleerd.

Om de multiple-database linkmodus uit te schakelen, verwijder eerst alle links en voer vervolgens het volgende commando uit op elke SQL Server-replica:

EXEC sys.sp_multidb_milink 0;

Bereid de databases van de beschikbaarheidsgroepen voor

Stel elke SQL Server-database die je wilt repliceren in naar het volledige herstelmodel en maak vervolgens een volledige back-up. Zowel bestaande beschikbaarheidsgroepdatabases als zelfstandige databases vereisen deze voorbereiding. Gebruik de SSMS-back-upprocedure in de linkconfiguratiegids.

Voor SQL Server-databases migreer je het TDE-certificaat naar SQL Managed Instance. Voor versleutelde SQL Managed Instance-databases die gekoppeld zijn aan SQL Server, gebruik een door de klant beheerde sleutel die toegankelijk is voor de bestemmings-SQL Server. Bekijk de TDE-voorbereiding voor de link voor de vereisten in elke richting.

De link repliceert alle databases in de geselecteerde beschikbaarheidsgroep. Je kunt geen subset kiezen, dus controleer de beschikbare capaciteit van de doel-SQL-beheerde instantie voordat je de link aanmaakt. De bestemming mag geen databases bevatten met dezelfde namen als de databases die je wilt repliceren. Bestaande databases met verschillende namen zijn toegestaan, onder voorbehoud van de capaciteitslimieten van de instantie.

De koppeling ondersteunt alleen het repliceren van gebruikersdatabases. Replicatie van systeemdatabases wordt niet ondersteund. Als u objecten op exemplaarniveau wilt repliceren die zijn opgeslagen in master of msdb, scriptt u deze uit en voert u T-SQL-scripts uit op het doelexemplaren.

Configureer de luisteraar en certificaten

Voor een beschikbaarheid van meerdere knooppunten gebruik je het IP-adres van de luisteraar bij het configureren van de link, zowel in SSMS als in scripts. De luisteraar stuurt verbindingen naar de huidige primaire replica. Gebruik het IP-adres van een individuele SQL Server-replica niet als partner-endpoint van de link. Zonder de luisteraar blijft de verbinding niet werken na een failover van een lokale beschikbaarheidsgroep. Voor een single-node beschikbaarheidsgroep, inclusief een die is gemaakt door de SSMS-wizard voor standalone databases, gebruik je het IP-eindpunt van die SQL Server-instantie.

De SSMS-wizard wisselt certificaten uit tussen Azure SQL Managed Instance en alleen de huidige primaire replica van SQL Server. Het configureert geen certificaatvertrouwen op de andere SQL Server-replica's. Je moet handmatig de vereiste certificaten kopiëren en configureren op elke andere SQL Server-replica zodat de verbinding kan blijven werken na een failover van de lokale beschikbaarheidsgroep. Deze handmatige stap geldt zowel voor SSMS als voor gescripte configuratie. Bekijk Breng vertrouwen tot stand tussen instanties voor de stappen voor het uitwisselen van certificaten.

Bereid je voor op het maken van gescripte links

Gebruik SSMS voor de aanbevolen setup-ervaring. De wizard automatiseert veel configuratiestappen. Als je geen gescripte automatisering nodig hebt, sla dan dit gedeelte over en ga door naar het tabblad SSMS in de beschikbaarheidsgroep Uitbreiden.

Scripted setup is een geavanceerde optie die ervaring vereist met het configureren van beschikbaarheidsgroepen, endpoints en certificaatvertrouwen. Voltooi deze stappen alleen als je PowerShell of Azure CLI gebruikt met SQL Server als eerste primaire functie.

De checklist omvat zowel bestaande beschikbaarheidsgroepen als zelfstandige databases. Nadat je de databases, het vertrouwen en het endpoint hebt voorbereid, hergebruik je je bestaande beschikbaarheidsgroep of maak je er een aan in stap 4. Maak vervolgens de gedistribueerde beschikbaarheidsgroep aan. De PowerShell- en Azure CLI-linkcreatiecommando's maken de beschikbaarheidsgroep niet voor je aan.

Voor een script dat is afgestemd op jouw omgeving, gebruik de SSMS-linkwizard en selecteer Script op de Samenvattingspagina . Bekijk het gegenereerde script en voer het apart uit.

1. Schakel de multiple-database linkmodus in op elke SQL Server-replica, of op de standalone SQL Server-instantie, en bereid de databases voor.
2. Vertrouwensrelaties tussen exemplaren tot stand brengen. Volg de stappen voor certificaatcreatie, publieke sleuteluitwisseling, import van root-certificaten en certificaatketenvalidatie. Voor een groep met meerdere knooppunten passen de certificaatvereisten toe op elke SQL Server-replica, niet alleen op de huidige primaire.
3. Beveilig het databasespiegelings-eindpunt. Als je beschikbaarheidsgroep al een endpoint heeft, gebruik dan Alter een bestaand endpoint in plaats van een nieuw endpoint aan te maken. Bebehoud de geconfigureerde eindpoort voor het linkcreatiecommando.
4. Bereid de beschikbaarheidsgroep voor. Als je al een beschikbaarheidsgroep hebt met alle databases die je wilt repliceren, hergebruik die dan en sla het aanmaken van een nieuwe groep over. Als je begint met zelfstandige databases, maak dan eerst een beschikbaarheidsgroep aan op SQL Server. Gebruik in het initiale primaire tabblad van SQL Server het voorbeeld van één knoop CREATE AVAILABILITY GROUP met CLUSTER_TYPE = NONE, maar vervang FOR DATABASE [<DatabaseName>] het door de volledige databaselijst, zoals FOR DATABASE [DB01], [DB03], [DB05], [DB07]. Stel de naam in <AGNameOnSQLServer> die je aan de nieuwe groep wilt geven. Voer dit script uit voordat je doorgaat met het aanmaken van een gedistribueerde beschikbaarheidsgroep. Voer het niet uit tegen een bestaande groep en verander de clusterconfiguratie van een bestaande groep.
5. Maak de gedistribueerde beschikbaarheidsgroep aan op SQL Server. Gebruik het primaire tabblad van de SQL Server en begin bij de instructies voor het aanmaken van de gedistribueerde beschikbaarheidsgroep. Stel <AGNameOnSQLServer> in op de beschikbaarheidsgroep die je in de vorige stap hebt hergebruikt of aangemaakt. Voor een groep met meerdere knooppunten gebruik je het IP-adres van de luisteraar voor <SQLServerIP>. Voor een single-node-groep gebruik je het eindpunt van de SQL Server-instantie. Bebehoud <DAGName> als je linknaam en <AGNameOnSQLMI> als de naam van de managed-instance beschikbaarheidsgroep voor het aanmaakcommando hieronder.
6. Controleer de beschikbaarheidsgroepen op SQL Server. Bevestig dat zowel de Always On-beschikbaarheidsgroep als de gedistribueerde beschikbaarheidsgroep aanwezig zijn. Ga daarna terug naar de beschikbaarheidsgroep uitbreiden, selecteer PowerShell of Azure CLI, en voer het multiple-database creation commando uit in dit artikel in plaats van het single-database-commando van de andere gids.

Breid de beschikbaarheidsgroep uit

Om logrecords die nodig zijn voor seeding te behouden, wordt aanbevolen om trace flag 12381 in te schakelen op ondersteunde SQL Server-builds voordat links worden aangemaakt, vooral voor grote databases of veel databases in multiple-database linkmodus. De vlag is echter niet vereist, en er zijn alternatieve mitigatiemaatregelen, vermeld in Troubleshoot error 1412. Met de vlag ingeschakeld kunnen logback-ups doorgaan, maar bewaarde logrecords worden niet herbruikbaar gemaakt. Monitor de groei van SQL Server-logboeken en vrije schijfruimte, en schakel de vlag uit zodra de seeding voor alle links die worden aangemaakt is voltooid.

Gebruik SSMS om het maken van links te automatiseren, of kies voor PowerShell of Azure CLI voor geavanceerde gescripte configuratie. De volgende voorbeelden gebruiken SQL Server als initiële primaire. Je kunt ook beginnen met een SQL Managed Instance met een bijpassend updatebeleid, maar die creatieworkflow wordt hier niet behandeld.

Voor gescripte configuratie voltooi je de gescripte setup-stappen om een beschikbaarheidsgroep te hergebruiken of aan te maken met alle databases die je wilt repliceren, en maak je vervolgens de gedistribueerde beschikbaarheidsgroep aan voordat je het PowerShell- of Azure CLI-aanmaakcommando uitvoert. Als alternatief, als je begint met zelfstandige databases, maakt de SSMS-procedure in deze sectie automatisch de single-node beschikbaarheidsgroep aan als onderdeel van de linkopstelling.

Voor multiple-database linkmodus specificeer MultiDatabase expliciet in scripts en geef alle databasenamen in de beschikbaarheidsgroep. PowerShell staat standaard op SingleDatabase if -LinkMode is weggelaten. Gebruik -LinkMode MultiDatabase in PowerShell of --link-mode MultiDatabase in 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

Verifieer replicatie

Nadat je de link hebt gemaakt of databases hebt toegevoegd, repliceert de data van de huidige primaire naar de huidige secundaire replica. Zowel SQL Server als Azure SQL Managed Instance kunnen de eerste primaire zijn. Na rolomkering repliceert de data in de tegenovergestelde richting. Afhankelijk van databasegrootte en netwerksnelheid kan elke database aanvankelijk in een hersteltoestand zijn op de secundaire replica. Nadat de eerste seeding is voltooid, wordt de database hersteld naar de secundaire replica en is deze klaar voor alleen-lezen-taken.

Gebruik bij beide replica's Objectverkenner in SSMS om de gesynchroniseerde status van elke gerepliceerde database te bekijken. Breid Always On High Availability- en Availability Groups uit om de gedistribueerde beschikbaarheidsgroep te bekijken die voor de link is aangemaakt.

Wanneer SQL Server primair is, kun je tijdens het seeden doorgaan met de back-ups van transactielogboeken als trace flag 12381 is ingeschakeld op een ondersteunde build. Als je back-ups van logboeken pauzeert om voortijdige truncatie te voorkomen, hervat ze dan nadat de initiële gegevensaanvulling is voltooid. Voor elke database zonder log-back-up schema maakt u de eerste transactielogback-up pas nadat de initiële seeding is voltooid, niet tijdens het seeden. Nadat de seeding is voltooid voor alle links die worden aangemaakt, schakel dan de vlag uit als je die hebt ingeschakeld en maak regelmatig back-ups van SQL Server-transactielogboeken terwijl SQL Server primair blijft. Wanneer Azure SQL Managed Instance primair is, maakt het automatisch back-ups van transactielogboeken. Je hoeft geen handmatige SQL Server-logback-ups te maken voor deze databases terwijl SQL Server secundair is.

Voortijdige afkorting van logs tijdens seeding kan fouten 1408 en 1412 veroorzaken in het SQL Managed Instance foutlogboek. Bij builds die dit ondersteunen, voorkomt trace-flag 12381 deze afkaping. Schakel het uit zodra de seeding voor alle links is voltooid, en monitor het gebruik van transactielogboeken, groeisnelheid en vrije schijfruimte terwijl het actief is. Logback-ups kunnen doorgaan zolang de vereiste records worden bewaard. Deze bewaartermijn vervangt de reguliere logback-ups na de initiële seeding niet. Zie Voorkom voortijdige truncatie van logs.

Databases toevoegen

Gebruik de SSMS-wizard om databases toe te voegen vanaf de huidige primaire instelling, of het nu SQL Server of SQL Managed Instance is. De tovenaar automatiseert de benodigde wijzigingen. Voor geavanceerde automatisering gebruik je PowerShell of de Azure CLI. Het toevoegen van een database is een enkele bewerking aan de primaire kant.

Controleer voordat je databases toevoegt of de bestaande link multiple-database linkmodus gebruikt en dat de bestemming voldoende beschikbare databasecapaciteit en opslag heeft, zonder bestaande databasenamen die conflicteren met de nieuwe databases. Wanneer SQL Server primair is, stel je elke nieuwe database die nog niet in de beschikbaarheidsgroep zit in op het volledige herstelmodel en maak je een volledige back-up met behulp van de SSMS-back-upprocedure.

Voeg databases toe met SSMS

Gebruik de gids 'Add Database to Azure SQL Managed Instance Link om databases toe te voegen aan een bestaande koppeling met meerdere databases:

1. Maak verbinding met de huidige primaire in SSMS. Vouw in ObjectverkennerAlways On High Availability en beschikbaarheidsgroepen uit.

2. Klik met de rechtermuisknop op de distributed availability-groep van je link, beweeg je muis over de link Azure SQL Managed Instance en selecteer 'Add Database...'.

   

3. Ga door via Introductie en Azure Login, en selecteer vervolgens je link met meerdere databases op de pagina Link selecteren.

4. Selecteer op de pagina Databases selecteren de databases die je wilt toevoegen. Je kunt alleen databases toevoegen met een Klaar-status . Databases die al in de link staan, worden weergegeven als Al onderdeel van de geselecteerde link. Los eventuele geschiktheidsproblemen op voordat je verder gaat.

   

5. Volledige validatie en beoordelingssamenvatting. Selecteer Voltooien om de wijziging uit te voeren, of selecteer Script om een script te genereren zonder de wijziging uit te voeren, zodat je het apart kunt bekijken, aanpassen en uitvoeren. Als je de wijziging in de wizard uitvoert, bekijk dan Resultaten voordat je hem sluit.

Voeg databases toe met scripts

Voer de toevoeging uit op de huidige primary. Volg de instructies voor dat geval.

Wanneer SQL Server primair is

Gebruik T-SQL om elke database toe te voegen aan de beschikbaarheidsgroep. De link verspreidt de toevoeging aan de SQL Managed Instance. Er is geen verdere actie nodig op SQL Managed Instance. Voer geen PowerShell- of Azure CLI-update uit voor deze toevoeging.

Wanneer SQL Managed Instance primair is

Gebruik PowerShell of Azure CLI om de link bij te werken op SQL Managed Instance. De link verspreidt automatisch de toegevoegde databases naar de beschikbaarheidsgroep. Er is geen aparte stap nodig op SQL Server. Geef het volledige beoogde lidmaatschap, inclusief alle bestaande databases die je wilt behouden en de nieuwe databases. De verstrekte lijst vervangt het huidige lidmaatschap. Het weglaten van een database verwijdert deze uit het lidmaatschap van de link.

Bijvoorbeeld, om toe te voegen DB09 wanneer de link al DB01, DB03, DB05, en DB07bevat, behoudt die vier namen in de lijst, en voegt ook DB09 toe aan de lijst. Vervang de bron- en databasenamen door je eigen waarden.

# 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"

Herhaal de replicatieverificatiestappen voor elke nieuw toegevoegde database. Volg de handmatige back-up stappen alleen wanneer SQL Server primair is.

Databases verwijderen

Gebruik de SSMS-wizard op de huidige primaire om verwijdering aan beide kanten te automatiseren. Het verwijderen van een database vereist dat deze uit de link op de SQL Managed Instance en uit de beschikbaarheidsgroep wordt verwijderd. Het slechts aan één kant verwijderen voltooit de bewerking niet.

Verwijder databases met SSMS

De volgende stappen gelden ongeacht of SQL Server of SQL Managed Instance primair is:

1. Maak verbinding met de huidige primaire in SSMS. Vouw in ObjectverkennerAlways On High Availability en beschikbaarheidsgroepen uit.

2. Klik met de rechtermuisknop op de gedistribueerde beschikbaarheidsgroep voor de link, muis met de muis over de link Azure SQL Managed Instance en selecteer Database verwijderen....

   

3. In de gids 'Remove Database from Azure SQL Managed Instance Link' gaat u door via Introduction en Azure Login, en selecteert u de link op Select Link.

4. Selecteer bij Select Databases de databases die verwijderd moeten worden. Selecteer bijvoorbeeld DB05 om het uit de link te verwijderen, en selecteer vervolgens Volgende.

   

5. Voltooi Validatie, bekijk Samenvatting en selecteer Voltooien om de verwijdering uit te voeren of Script om eerst de gegenereerde commando's te bekijken. Controleer de resultaten op succesvolle voltooiing voordat je de wizard afsluit.

Verwijder databases met scripts

Verwijder de databases op beide instanties. De huidige primaire instantie bepaalt welke instantie als eerste wordt bijgewerkt.

De voorbeelden van PowerShell en Azure CLI gebruiken de volgende variabelen:

Wanneer SQL Server primair is

1. Gebruik T-SQL om de databases uit de beschikbaarheidsgroep te verwijderen.
2. Gebruik PowerShell of Azure CLI om de databases van de link op SQL Managed Instance te verwijderen, zoals in deze sectie wordt getoond.

Voor de stap SQL Managed Instance levert u de volledige lijst met databases die behouden moeten worden, waarbij alleen die u wilt verwijderen weglaat. Als bijvoorbeeld de link DB01, DB03, DB05, , DB07en DB09bevat, verwijdert DB05 en behoudt het volgende commando de andere vier. Vervang de bron- en databasenamen door je eigen waarden.

# 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"

Wanneer SQL Managed Instance primair is

1. Gebruik PowerShell of Azure CLI om de databases van de link op SQL Managed Instance te verwijderen, zoals in deze sectie wordt getoond.
2. Gebruik T-SQL op SQL Server om de databases uit de beschikbaarheidsgroep te verwijderen. Het verwijderen is pas voltooid als je deze stap hebt afgerond.

Voor de stap SQL Managed Instance levert u de volledige lijst met databases die behouden moeten worden, waarbij alleen die u wilt verwijderen weglaat. Als bijvoorbeeld de link DB01, DB03, DB05, , DB07en DB09bevat, verwijdert DB05 en behoudt het volgende commando de andere vier. Vervang de bron- en databasenamen door je eigen waarden.

# 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"

Bevestig dat de verwijderde databases niet langer bij de link of de beschikbaarheidsgroep horen. Een database uit replicatie verwijderen is niet hetzelfde als het verwijderen van de behouden kopie. Bekijk de databases van beide gevallen voordat je beslist of je een kopie verwijdert die je niet meer nodig hebt.

Fail over of cut over naar Azure

Gebruik de bestaande failoverprocedures in SSMS of via scripts om de rollen om te wisselen tussen SQL Server en Azure SQL Managed Instance. Rolomkering vereist dat de beheerde SQL-instantie het updatebeleid gebruikt dat overeenkomt met jouw SQL Server-versie. Voor eenrichtingsreplicatie en overgang naar Azure SQL Managed Instance moet het updatebeleid overeenkomen met of hoger zijn dan je SQL Server-versie. Je kunt geen data repliceren of daarna teruggaan naar SQL Server als de beleidsregels niet overeenkomen. Bekijk de ondersteunde combinaties. Voor migratie- en cutover-richtlijnen, zie Migreren met de link.

Replicatie bewaken en problemen oplossen

Gebruik de volgende dynamische beheerweergaven (DMV's) en catalogusweergave op SQL Server om de hoofdbeschikbaarheidsgroep, replica-connectiviteit en de replicatiegezondheid van elke database te controleren:

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;

Als de interne replicatie-DMV's niet beschikbaar zijn, of als het uitvoeren van de sys.sp_multidb_milink opgeslagen procedure meldt dat deze niet beschikbaar is, verifieer dan de geïnstalleerde SQL Server-versie en de cumulatieve update op die replica. Voor algemene connectiviteits- en replicatie-probleemoplossing, zie Troubleshoot de Managed Instance-link.

Limitations

Houd rekening met de volgende beperkingen bij het uitbreiden van een beschikbaarheidsgroep via een verbinding met meerdere databases:

• Linknamen moeten kleine letters gebruiken. Koppeltekens zijn toegestaan, maar een naam mag niet beginnen of eindigen met een koppelteken.
• Downgrade geen enkele SQL Server-replica naar een versie lager dan SQL Server 2022 CU27 of SQL Server 2025 CU9, indien van toepassing, zolang een link in de modus voor meerdere databases actief is. Downgraden onder de vereiste CU kan onvoorspelbare problemen veroorzaken, zelfs zonder failover.
• Ingesloten beschikbaarheidsgroepen worden niet ondersteund.
• Single-databaselinks en multiple-databaselinks kunnen niet naast elkaar bestaan op dezelfde SQL Server-instantie.
• Je kunt de modus van een link niet direct wijzigen. Om te schakelen tussen single-database- en multiple-database linkmodi, verwijder je alle bestaande links, verander je de modus op elke SQL Server-replica en maak je vervolgens de links opnieuw aan in de nieuwe modus.
• Wanneer je een link maakt voor een bestaande beschikbaarheidsgroep, moeten alle databases in die groep worden gerepliceerd. Je kunt niet alleen een subset van de databases in die groep selecteren.
• De resterende databasecapaciteit op de doel-SQL-beheerde instantie beperkt het aantal databases dat je kunt repliceren. General Purpose en Business Critical ondersteunen tot 100 databases per instantie, en Next-gen General Purpose ondersteunt tot 500. Bestaande databases tellen mee voor deze limieten. Een instantie met een limiet van 100 databanken en 10 bestaande databases heeft bijvoorbeeld capaciteit voor nog eens 90 databases. Voor meer informatie, zie resourcelimieten.
• Het toevoegen van databases aan de beschikbaarheidsgroep buiten de beschikbare databasecapaciteit van de doel-SQL managed instance kan slagen op SQL Server, maar replicatie naar SQL Managed Instance faalt. Deze voorwaarde kan de link in een inconsistente toestand achterlaten die handmatig verwijdering van de niet-gerepliceerde databases uit de beschikbaarheidsgroep vereist.
• Het toevoegen van databases wordt via de link verspreid, maar het verwijderen van een database aan de ene kant verwijdert deze niet automatisch aan de andere kant. Als je een database uit de beschikbaarheidsgroep verwijdert, blijft de kopie ervan op SQL Managed Instance. Als je een database verwijdert van de link in de SQL Managed Instance, blijft de database in de beschikbaarheidsgroep zonder replicatie via de link en vereist handmatig opschonen.
• Wanneer je databases toevoegt aan een bestaande link via SSMS, kun je alleen databases toevoegen met een Ready-status . Je kunt geen databases toevoegen die tot een andere beschikbaarheidsgroep behoren of een naam hebben die al op de bestemming staat.

Verwante onderwerpen

• Overzicht van Managed Instance-koppelingen
• Uw omgeving voorbereiden op de link
• Koppeling configureren met SSMS-
• aanbevolen procedures voor het onderhouden van de koppeling
• Problemen met de koppeling oplossen