Utöka en Always On-tillgänglighetsgrupp till Azure SQL Managed Instance (förhandsvisning)

gäller för:Azure SQL Managed Instance

Den här artikeln lär dig hur du kan utöka en Always On-tillgänglighetsgrupp med flera databaser mellan SQL Server och Azure SQL Managed Instance med Managed Instance-länken genom att använda SQL Server Management Studio (SSMS), PowerShell eller Azure CLI.

Denna artikel behandlar multiple-database-länkläge, som replikerar alla databaser i en tillgänglighetsgrupp via en länk. Länkläge med en enda databas replikerar en databas per länk.

Overview

När du förlänger en Always On-tillgänglighetsgrupp mellan SQL Server och Azure SQL Managed Instance, skapar du en länk som replikerar flera databaser i en tillgänglighetsgrupp till målrepliken. Länken använder en distribuerad tillgänglighetsgrupp för att replikera förändringar i nästan realtid från den aktuella primära repliken till skrivskyddade databaskopior på den sekundära repliken. Detta säkerställer att de skrivskyddade kopiorna på sekundären hålls uppdaterade i synk med primären.

Du kan använda en befintlig tillgänglighetsgrupp eller börja med fristående databaser. När du väljer fristående databaser i SSMS skapar guiden en tillgänglighetsgrupp med en enda nod på den initiala primärfilen och replikerar de valda databaserna via en länk.

Antingen SQL Server eller Azure SQL Managed Instance kan vara den initiala primära. Att skapa länken från SQL Managed Instance kräver SQL Server 2022 eller SQL Server 2025 med den nödvändiga kumulativa uppdateringen och en matchande SQL Managed Instance-uppdateringspolicy. Skapandeexemplen i denna artikel börjar från SQL Server. De går inte igenom skapandet från SQL Managed Instance. Failover med rollombytning mellan SQL Server och Azure SQL Managed Instance stöds för instanser konfigurerade med matchande uppdateringspolicys.

Supportbarhet

Följande krav gäller för att utöka en tillgänglighetsgrupp via en länk med flera databaser under förhandsgranskning. SQL Server på både Windows och Linux stöds. Du måste installera den nödvändiga kumulativa uppdateringen (CU). Tidigare versioner stödjer inte denna funktion.

Tänk på följande:

• Standardutgåvan stöds inte eftersom grundläggande tillgänglighetsgrupper bara stöder en databas.
• SQL Server 2019 och tidigare versioner stöds inte för multidatabaslänksläge eftersom de saknar den nödvändiga teknologin som introducerades i SQL Server 2022.
• För att skapa länken från SQL Managed Instance eller omvända roller tillbaka till SQL Server måste din SQL managed instance använda den uppdateringspolicy som matchar din SQL Server-version. För enkelriktad replikering och övergångsöverföring från SQL Server måste destinationsuppdateringspolicyn matcha eller vara högre än din SQL Server-version.
  • SQL Server 2022 stöder replikering till instanser konfigurerade med policyerna SQL Server 2022, SQL Server 2025 och Always-up-to-date.
  • SQL Server 2025 stöder replikering till instanser konfigurerade med SQL Server 2025 och Always-up-to-date-policys, men inte SQL Server 2022. Du kan inte replikera data eller gå tillbaka till SQL Server efter cutover om policyerna inte stämmer.

För SQL Server-versioner och utgåvor som har stöd för länkar för enskilda databaser, se Versionsstöd för Managed Instance-link.

Förutsättningar

För att utöka din tillgänglighetsgrupp mellan SQL Server och Azure SQL Managed Instance behöver du följande förutsättningar:

• En aktiv prenumeration för Azure. Om du inte har något konto, skapa ett kostnadsfritt konto.
• En stödd SQL Server-version och version med nödvändig serviceuppdatering installerad. Du kan använda en befintlig Always On-tillgänglighetsgrupp eller fristående databaser som SSMS placerar i en ny tillgänglighetsgrupp med en enda nod. Contained-tillgänglighetsgrupper stöds inte.
• Azure SQL Managed Instance med en uppdateringspolicy som passar din situation. En matchningspolicy krävs när SQL Managed Instance är den initiala primära eller för rollomkastning. Börja om du inte har en SQL-hanterad instans.
• SQL Server Management Studio (SSMS) 22.10.2 eller senare.
• För skriptad konfiguration, Azure PowerShell med Az-modulen version 16.3.0 eller senare och Az.Sql version 7.1.0 eller senare, eller Azure CLI version 2.90.0 eller senare. Du kan också använda Azure Cloud Shell. Verifiera att de installerade modulerna eller CLI uppfyller dessa versionskrav.
• En korrekt förberedd miljö.
• För en tillgänglighetsgrupp med flera noder, en konfigurerad tillgänglighetsgrupplyssnare. Använd lyssnarens IP-adress när du konfigurerar länken, inte en enskild SQL Server-replikas IP-adress. Med hjälp av lyssnaren fortsätter länken att fungera efter en lokal tillgänglighetsgrupp-failover.
• Inga befintliga länkar på någon SQL Server-replik när du aktiverar multiple-database-länkläge. Innan du börjar, ta bort alla länkar som använder det äldre enkeldatabaslänksläget.
• Tillräcklig tillgänglig databaskapacitet och lagring på den målhanterade instansen för alla databaser i din tillgänglighetsgrupp. Gå igenom resursgränser.

Permissions

För SQL Server behöver du sysadmin-behörigheter .

För Azure SQL Managed Instance måste du vara medlem i rollen SQL Managed Instance Contributor eller ha följande behörigheter för en anpassad roll:

Aktivera länkläge med flera databaser

Stöd för multiple-database-länkläge är inaktiverat som standard under förhandsgranskning. Använd den inbyggda sys.sp_multidb_milink lagrade proceduren för att aktivera den på varje SQL Server-replik i tillgänglighetsgruppen, eller på SQL Server-instansen där du planerar att skapa en grupp med en enda nod.

Kör följande kommando på varje SQL Server-replika för att aktivera multiple-database-länkläge:

EXEC sys.sp_multidb_milink 1;

Inställningen kvarstår under alla omstarter av SQL Server, så du behöver bara aktivera den en gång på varje replik.

För att kontrollera inställningen, kör den lagrade proceduren utan en parameter på varje replik. Den återvänder 1 när den är aktiverad och 0 när den är avstängd:

EXEC sys.sp_multidb_milink;

Om den lagrade proceduren inte är tillgänglig, kontrollera att replikan har en stödd SQL Server-version och kumulativ uppdatering installerad.

För att inaktivera multiple-database-länkläge, ta först bort alla länkar och kör sedan följande kommando på varje SQL Server-replik:

EXEC sys.sp_multidb_milink 0;

Förbered tillgänglighetsgruppsdatabaserna

Sätt in varje SQL Server-databas du vill replikera till hela återställningsmodellen och skapa sedan en fullständig backup. Både befintliga tillgänglighetsgruppsdatabaser och fristående databaser kräver denna förberedelse. Använd SSMS-backupproceduren i länkkonfigurationsguiden.

För SQL Server-databaser, migrera TDE-certifikatet till SQL Managed Instance. För krypterade SQL Managed Instance-databaser kopplade till SQL Server, använd en kundhanterad nyckel som är tillgänglig för destinations-SQL Server. Gå igenom TDE-förberedelserna för länken för kraven i varje riktning.

Länken replikerar alla databaser i den valda tillgänglighetsgruppen. Du kan inte välja en delmängd, så kontrollera den tillgängliga kapaciteten för den mål-SQL-hanterade instansen innan du skapar länken. Destinationen får inte innehålla databaser med samma namn som de databaser du vill replikera. Befintliga databaser med olika namn är tillåtna, med förbehåll för instansens kapacitetsbegränsningar.

Länken stöder endast replikering av användardatabaser. Replikering av systemdatabaser stöds inte. Om du vill replikera objekt på instansnivå som lagras i master eller msdbskriptar du ut dem och kör T-SQL-skript på målinstansen.

Konfigurera lyssnaren och certifikaten

För en tillgänglighetsgrupp med flera noder, använd lyssnarens IP-adress vid konfiguration av länken, både i SSMS och i skript. Lyssnaren dirigerar anslutningar till den aktuella primära replikan. Använd inte IP-adressen till en enskild SQL Server-replika som länkens partner-endpoint. Utan lyssnaren fortsätter inte länken att fungera efter en lokal tillgänglighetsgrupp-failover. För en tillgänglighetsgrupp med en enda nod, inklusive en som skapats av SSMS-guiden för fristående databaser, använd den SQL Server-instansens IP-endpoint.

SSMS-guiden utbyter certifikat mellan Azure SQL Managed Instance och endast den aktuella primära SQL Server-repliken. Den konfigurerar inte certifikatförtroende på de andra SQL Server-replikerna. Du måste manuellt kopiera och konfigurera de nödvändiga certifikaten på varje annan SQL Server-replik så att länken kan fortsätta fungera efter en lokal tillgänglighetsgruppsfailover. Detta manuella steg gäller både SSMS och skriptad konfiguration. Granska Etablera förtroende mellan instanser för certifikatutbytesstegen.

Förbered dig för att skapa skriptade länkar

Använd SSMS för den rekommenderade setup-upplevelsen. Guiden automatiserar många konfigurationssteg. Om du inte behöver skriptad automation, hoppa över detta avsnitt och fortsätt till fliken SSMS i Utöka tillgänglighetsgruppen.

Skriptad installation är ett avancerat alternativ som kräver erfarenhet av att konfigurera tillgänglighetsgrupper, endpoints och certifikatförtroende. Genomför dessa steg endast om du använder PowerShell eller Azure CLI med SQL Server som första primära.

Checklistan täcker både befintliga tillgänglighetsgrupper och fristående databaser. Efter att du har förberett databaserna, förtroendet och endpointen, återanvänd din befintliga tillgänglighetsgrupp eller skapa en i steg 4. Skapa sedan gruppen för distribuerad tillgänglighet. PowerShell- och Azure CLI-länkskapandekommandona skapar inte tillgänglighetsgruppen åt dig.

För ett skript anpassat till din miljö, använd SSMS länkguide och välj Skript på dess sammanfattningssida . Gå igenom det genererade skriptet och kör det separat.

1. Aktivera multiple-database-länkläge på varje SQL Server-replik, eller på den fristående SQL Server-instansen, och förbered databaserna.
2. Upprätta förtroende mellan instanser. Följ stegen för skapande av certifikat, utbyte av offentliga nycklar, import av rotcertifikat och validering av certifikatkedjan. För en grupp med flera noder, tillämpa certifikatkraven på varje SQL Server-replika, inte bara den aktuella primära.
3. Säkra databasspeglingsändpunkten. Om din tillgänglighetsgrupp redan har en endpoint, använd Alter en befintlig endpoint istället för att skapa en ny. Behåll den konfigurerade endpoint-porten för länkskapandekommandot.
4. Förbered tillgänglighetsgruppen. Om du redan har en tillgänglighetsgrupp som innehåller alla databaser du vill replikera, återanvänd den och hoppa över att skapa en ny grupp. Om du börjar med fristående databaser, skapa först en tillgänglighetsgrupp på SQL Server. I SQL Server:s initiala primära flik, använd exemplet med en enda nod CREATE AVAILABILITY GROUP med CLUSTER_TYPE = NONE, men ersätt FOR DATABASE [<DatabaseName>] med hela databaslistan, såsom FOR DATABASE [DB01], [DB03], [DB05], [DB07]. Ställ <AGNameOnSQLServer> in på det namn du vill ge den nya gruppen. Kör detta skript innan du fortsätter med att skapa distribuerad tillgänglighetsgrupp. Kör det inte mot en befintlig grupp eller ändra en befintlig grupps klusterkonfiguration.
5. Skapa gruppen för distribuerad tillgänglighet på SQL Server. Använd SQL Server:s initiala primärflik och börja vid instruktionerna för att skapa en distribuerad tillgänglighetsgrupp. Ställ in <AGNameOnSQLServer> den tillgänglighetsgrupp du återanvände eller skapade i föregående steg. För en grupp med flera noder, använd lyssnarens IP-adress för <SQLServerIP>. För en grupp med en enda nod, använd SQL Server-instansens endpoint. Behåll <DAGName> som ditt länknamn och <AGNameOnSQLMI> som namnet på den hanterade instansens tillgänglighetsgrupp för skapandekommandot nedan.
6. Verifiera tillgänglighetsgrupperna på SQL Server. Bekräfta att både Always On-tillgänglighetsgruppen och den distribuerade tillgänglighetsgruppen är närvarande. Gå sedan tillbaka till Utöka tillgänglighetsgruppen, välj PowerShell eller Azure CLI, och kör kommandot för att skapa flera databaser i denna artikel istället för den andra guidens kommando för en enda databas.

Utöka tillgänglighetsgruppen

För att behålla loggposter som behövs för seeding rekommenderas att aktivera trace flag 12381 på stödda SQL Server-byggen innan länkar skapas, särskilt för stora databaser eller många databaser i länkläge med flera databaser. Flaggan är dock inte nödvändig, och det finns alternativa åtgärder, listade i felsökningsfel 1412. Med flaggan aktiverad kan loggkopior fortsätta, men behållna loggposter blir inte återanvändbara. Övervaka SQL Server-loggtillväxt och ledigt diskutrymme, och inaktivera flaggan så snart seedningen är klar för alla länkar som skapas.

Använd SSMS för att automatisera länkskapande, eller välj PowerShell eller Azure CLI för avancerad skriptad konfiguration. Följande exempel använder SQL Server som den initiala primären. Du kan också börja från SQL Managed Instance med en matchande uppdateringspolicy, men det arbetsflödet för skapande täcks inte här.

För skriptad konfiguration, slutför de skriptade installationsstegen för att återanvända eller skapa en tillgänglighetsgrupp som innehåller alla databaser du vill replikera, och skapa sedan den distribuerade tillgänglighetsgruppen innan du kör PowerShell- eller Azure CLI-skapaandekommandot. Alternativt, om du börjar med fristående databaser, skapar SSMS-proceduren i detta avsnitt automatiskt en tillgänglighetsgrupp med en enda nod som en del av länkkonfigurationen.

För länkläge med flera databaser, specificera MultiDatabase explicit i skript och ange alla databasnamn i tillgänglighetsgruppen. PowerShell använder SingleDatabase som standard om -LinkMode utelämnas. Använda -LinkMode MultiDatabase i PowerShell eller --link-mode MultiDatabase i 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

Verifiera replikeringen

Efter att du skapat länken eller lagt till databaser replikeras data från den nuvarande primära till den aktuella sekundära repliken. Antingen SQL Server eller Azure SQL Managed Instance kan vara den initiala primära. Efter rollomkastning replikeras data i motsatt riktning. Beroende på databasens storlek och nätverkshastighet kan varje databas initialt vara i återställningsläge på den sekundära repliken. När den första seedingen är klar återställs databasen till den sekundära repliken och är redo för skrivskyddade arbetsbelastningar.

På någon av replikerna använder du Object Explorer i SSMS för att visa statusen Synkroniserad för varje replikerad databas. Expandera Always On High Availability- och Availability-grupper för att se den distribuerade tillgänglighetsgruppen som skapats för länken.

När SQL Server är primär kan du fortsätta med säkerhetskopiering av transaktionsloggen under seedning om spårningsflaggan 12381 är aktiverad i en version som stöds. Om du pausar loggbackuper för att förhindra för tidig avkortning återupptar du dem när den inledande seedningen har slutförts. För varje databas utan loggbackupschema, ta den första transaktionsloggbackupen först efter att den initiala seedningen är klar, inte under seedningen. När initieringen har slutförts för alla kopplingar som skapas, inaktiverar du flaggan om du aktiverade den och tar regelbundet säkerhetskopior av SQL Server-transaktionsloggen medan SQL Server är den primära. När Azure SQL Managed Instance är primär tar den automatiskt kopior av transaktionsloggar. Du behöver inte ta manuella SQL Server-loggkopior för dessa databaser medan SQL Server är sekundärt.

För tidig loggtrunkering under seedning kan orsaka fel 1408 och 1412 i SQL Managed Instance-felloggen. I versioner som stöder det förhindrar spårningsflaggan 12381 denna avkortning. Inaktivera det när seedningen är klar för alla länkar som skapas, och övervaka transaktionslogganvändning, tillväxthastighet och ledigt diskutrymme medan det är aktiverat. Säkerhetskopiering av transaktionsloggar kan fortsätta att tas så länge som de poster som krävs behålls. Denna kvarhållning ersätter inte regelbundna loggsäkerhetskopior efter initiering. Se Förhindra för tidig trunkering av loggar.

Lägga till databaser

Använd SSMS-guiden för att lägga till databaser från den nuvarande primära, oavsett om det är SQL Server eller SQL Managed Instance. Trollkarlen automatiserar de nödvändiga ändringarna. För avancerad automatisering, använd PowerShell eller Azure CLI. Att lägga till en databas är en enda operation på primärsidan.

Innan du lägger till databaser, kontrollera att den befintliga länken använder multidatabaslänksläge och att destinationen har tillräcklig tillgänglig databaskapacitet och lagring, utan befintliga databasnamn som krockar med de nya databaserna. När SQL Server är primär, sätt varje ny databas som inte redan finns i tillgänglighetsgruppen till den fullständiga återställningsmodellen och skapa en fullständig backup genom att använda SSMS-backupproceduren.

Lägg till databaser med SSMS

Använd guiden Add Database to Azure SQL Managed Instance Link för att lägga till databaser i en befintlig länk med flera databaser:

1. Koppla upp dig mot den aktuella primära i SSMS. I Object Explorer expanderar du Always On-hög tillgänglighet och tillgänglighetsgrupper.

2. Högerklicka på den distribuerade tillgänglighetsgruppen för din länk, håll muspekaren över länken Azure SQL Managed Instance och välj Add Database....

   

3. Gå vidare genom Introduktion och Azure Login, och välj sedan din länk för flera databaser på sidan Välj länk.

4. På sidan Välj databaser , välj de databaser du vill lägga til. Du kan bara lägga till databaser med ett färdigt tillstånd. Databaser som redan finns i länken visas som Redan en del av den valda länken. Lös eventuella behörighetsproblem innan du fortsätter.

   

5. Fullständig validering och granskningssammanfattning. Välj Avsluta för att köra ändringen, eller välj Script för att generera ett skript utan att köra ändringen så att du kan granska, anpassa och köra det separat. Om du utför ändringen i wizarden, granska Results innan du stänger den.

Lägg till databaser med skript

Kör tilläggsåtgärden på den aktuella primära noden. Följ instruktionerna för det tillfället.

När SQL Server är primär

Använd T-SQL för att lägga till varje databas i tillgänglighetsgruppen. Länken sprider tillägget till SQL Managed Instance. Ingen ytterligare åtgärd behövs på SQL Managed Instance. Kör inte en PowerShell- eller Azure CLI-uppdatering för denna tillägg.

När SQL Managed Instance är primär

Använd PowerShell eller Azure CLI för att uppdatera länken på SQL Managed Instance. Länken sprider automatiskt de tillagda databaserna till tillgänglighetsgruppen. Inget separat steg på SQL Server krävs. Tillhandahåll hela det avsedda medlemskapet, inklusive alla befintliga databaser du vill behålla och de nya databaserna. Den medföljande listan ersätter det nuvarande medlemskapet. Att utelämna en databas tar bort den från länkens medlemskap.

Till exempel att lägga till DB09 när länken redan innehåller DB01, DB03, DB05, och DB07, behålla dessa fyra namn i listan, och även lägga till DB09 i listan. Byt ut resurs- och databasnamnen mot dina värden.

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

Upprepa replikationsverifieringsstegen för varje nyligen tillagd databas. Följ de manuella stegen för loggsäkerhetskopiering endast när SQL Server är primärt.

Ta bort databaser

Använd SSMS-guiden på den aktuella primära enheten för att automatisera borttagning på båda sidor. Att ta bort en databas kräver att den tas bort från länken på SQL Managed Instance och från tillgänglighetsgruppen. Att ta bort den på bara ena sidan slutför inte operationen.

Ta bort databaser med SSMS

Följande steg gäller oavsett om SQL Server eller SQL Managed Instance är primärt:

1. Koppla upp dig mot den aktuella primära i SSMS. I Object Explorer expanderar du Always On-hög tillgänglighet och tillgänglighetsgrupper.

2. Högerklicka på den distribuerade tillgänglighetsgruppen för länken, hovra över länken Azure SQL Managed Instance och välj Remove Database....

   

3. I guiden Remove Database from Azure SQL Managed Instance Link, gå igenom Introduction och Azure Login, och välj länken i Select Link.

4. Vid Select Databases, välj de databaser som ska tas bort. Till exempel, välj DB05 för att ta bort den från länken, och välj sedan Nästa.

   

5. Fullfölj valideringen, granska Sammanfattning och välj Avsluta för att utföra borttagningen eller Skript för att granska de genererade kommandona först. Kontrollera resultaten för lyckad slutföring innan du stänger trollkarlen.

Ta bort databaser med skript

Ta bort databaserna på båda instanserna. Den nuvarande primären avgör vilken instans som ska uppdateras först.

Exemplen med PowerShell och Azure CLI använder följande variabler:

När SQL Server är primär

1. Använd T-SQL för att ta bort databaserna från tillgänglighetsgruppen.
2. Använd PowerShell eller Azure CLI för att ta bort databaserna från länken på SQL Managed Instance, som visas i detta avsnitt.

För steget SQL Managed Instance, tillhandahåll den kompletta listan över databaser att behålla, och utelämna endast de du vill ta bort. Till exempel, om länken innehåller DB01, DB03, DB05, , DB07och DB09, tar följande kommando bort DB05 och behåller de andra fyra. Byt ut resurs- och databasnamnen mot dina värden.

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

När SQL Managed Instance är primär

1. Använd PowerShell eller Azure CLI för att ta bort databaserna från länken på SQL Managed Instance, som visas i detta avsnitt.
2. Använd T-SQL på SQL Server för att ta bort databaserna från dess tillgänglighetsgrupp. Borttagningen är inte klar förrän du har slutfört detta steg.

För steget SQL Managed Instance, tillhandahåll den kompletta listan över databaser att behålla, och utelämna endast de du vill ta bort. Till exempel, om länken innehåller DB01, DB03, DB05, , DB07och DB09, tar följande kommando bort DB05 och behåller de andra fyra. Byt ut resurs- och databasnamnen mot dina värden.

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

Bekräfta att de borttagna databaserna inte längre tillhör länken eller tillgänglighetsgruppen. Att ta bort en databas från replikering är inte samma sak som att radera dess kvarhållna kopia. Gå igenom databaserna i båda instanserna innan du bestämmer om du ska ta bort en kopia du inte längre behöver.

Fail over eller växla över till Azure

Använd befintliga failover-procedurer i SSMS eller skript för att byta roller mellan SQL Server och Azure SQL Managed Instance. Rollombytning kräver att den SQL-hanterade instansen använder den uppdateringspolicy som matchar din SQL Server-version. För enkelriktad replikering och övergång till Azure SQL Managed Instance måste dess uppdateringspolicy matcha eller vara högre än din SQL Server-version. Du kan inte replikera data eller gå tillbaka till SQL Server efteråt om policyerna inte stämmer. Gå igenom de stödda kombinationerna. För vägledning om migration och cutover, se Migrera med länken.

Övervaka och felsöka replikering

Använd följande dynamiska hanteringsvyer (DMV) och katalogvy på SQL Server för att kontrollera huvudtillgänglighetsgruppen, replikkopplingen och varje databass replikeringshälsa:

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;

Om de interna DMV:erna för replikering inte är tillgängliga, eller om det vid körning av den lagrade proceduren sys.sp_multidb_milink rapporteras att den inte är tillgänglig, kontrollerar du vilken SQL Server-version och vilken kumulativ uppdatering som är installerad på den repliken. För allmän felsökning av anslutning och replikering, se Felsök länken Managed Instance.

Limitations

Tänk på följande begränsningar när du utökar en tillgänglighetsgrupp via en länk med flera databaser:

• Länknamn måste skrivas med gemener. Bindestreck är tillåtna, men ett namn kan inte börja eller sluta med ett bindestreck.
• Nedgradera inte någon SQL Server-replika under SQL Server 2022 CU27 eller SQL Server 2025 CU9, beroende på vad som är tillämpligt, medan en länk i flerdatabasläge är aktiv. Att nedgradera till under den CU som krävs kan orsaka oförutsägbara problem även utan redundansväxling.
• Contained-tillgänglighetsgrupper stöds inte.
• Länkar med en enda databas och länkar med flera databaser kan inte samexistera på samma SQL Server-instans.
• Du kan inte ändra läget för en länk direkt. För att växla mellan länklägen med en och flera databaser, ta bort alla befintliga länkar, ändra läget på varje SQL Server-replik och återskapa länkarna i det nya läget.
• När du skapar en länk för en befintlig tillgänglighetsgrupp måste alla databaser i den gruppen replikeras. Du kan inte bara välja en delmängd av databaserna i den gruppen.
• Den återstående databaskapaciteten på den mål-SQL-hanterade instansen begränsar antalet databaser du kan replikera. General Purpose och Business Critical stöder upp till 100 databaser per instans, och Next-gen General Purpose stödjer upp till 500. Befintliga databaser räknas mot dessa gränser. Till exempel har en instans med en gräns på 100 databaser och 10 befintliga databaser kapacitet för 90 ytterligare databaser. För mer information, se resursgränser.
• Att lägga till databaser i tillgänglighetsgruppen utöver målinstansens tillgängliga databaskapacitet i SQL Managed Instance kan lyckas i SQL Server, men replikeringen till SQL Managed Instance misslyckas. Detta tillstånd kan lämna länken i ett inkonsekvent tillstånd som kräver manuell borttagning av de icke-replikerade databaserna från tillgänglighetsgruppen.
• Att lägga till databaser sprids via länken, men att ta bort en databas på ena sidan tar inte automatiskt bort den på andra sidan. Om du tar bort en databas från tillgänglighetsgruppen förblir dess kopia på SQL Managed Instance. Om du tar bort en databas från länken i SQL Managed Instance förblir databasen i tillgänglighetsgruppen utan replikering via länken och kräver manuell rensning.
• När du lägger till databaser till en befintlig länk via SSMS kan du bara lägga till databaser med ett färdigt tillstånd. Du kan inte lägga till databaser som tillhör en annan tillgänglighetsgrupp eller har ett namn som redan finns på destinationen.

Relaterat innehåll

• Översikt över länkar till hanterade instanser
• Förbereda din miljö för länken
• Konfigurera länk med SSMS
• Metodtips för att underhålla länken
• Felsöka problem med länken