Konfigurera en redundansgrupp för Azure SQL Managed Instance

Gäller för:Azure SQL Managed Instance

• Azure SQL Database
• Hanterad Azure SQL-instans

I den här artikeln lär du dig hur du konfigurerar en redundansgrupp för Azure SQL Managed Instance med hjälp av Azure-portalen och Azure PowerShell.

Ett PowerShell-skript från slutpunkt till slutpunkt för att skapa båda instanserna i en redundansgrupp finns i Lägg till instans i en redundansgrupp.

Förutsättningar

Tänk på följande förutsättningar:

• Den sekundära hanterade instansen måste vara tom, d.v.s. inte innehålla några användardatabaser.
• De två instanserna av SQL Managed Instance måste ha samma tjänstnivå och samma lagringsstorlek. Även om det inte behövs rekommenderar vi starkt att två instanser har samma beräkningsstorlek för att se till att den sekundära instansen kan bearbeta ändringarna som replikeras från den primära instansen på ett hållbart sätt, inklusive perioder med hög aktivitet.
• IP-adressintervallet för det virtuella nätverket för den primära instansen får inte överlappa adressintervallet för det virtuella nätverket för den sekundära hanterade instansen eller något annat virtuellt nätverk som är peerkopplat med det primära eller sekundära virtuella nätverket.
• När du skapar den sekundära hanterade instansen måste du ange den primära instansens DNS-zon-ID som värdet för parametern DnsZonePartner . Om du inte anger något värde för DnsZonePartnergenereras zon-ID:t som en slumpmässig sträng när den första instansen skapas i varje virtuellt nätverk och samma ID tilldelas till alla andra instanser i samma undernät. När DNS-zonen har tilldelats kan du inte ändra den.
• Regler för nätverkssäkerhetsgrupper (NSG) på värdinstansen för undernät måste ha port 5022 (TCP) och portintervallet 11000–11999 (TCP) öppen för inkommande och utgående anslutningar från och till undernätet som är värd för den andra hanterade instansen. Detta gäller både undernät som är värdar för den primära och sekundära instansen.
• Sorteringen och tidszonen för den sekundära hanterade instansen måste matcha den primära hanterade instansens.
• Hanterade instanser bör distribueras i parkopplade regioner av prestandaskäl. Hanterade instanser som finns i geo-kopplade regioner drar nytta av en betydligt högre geo-replikeringshastighet jämfört med obetalda regioner.

Adressutrymmesintervall

Om du vill kontrollera adressutrymmet för den primära instansen går du till den virtuella nätverksresursen för den primära instansen och väljer Adressutrymme under Inställningar. Kontrollera intervallet under Adressintervall:

Ange den primära instansens zon-ID

När du skapar den sekundära instansen måste du ange zon-ID för den primära instansen DnsZonePartnersom .

Portal

Om du skapar den sekundära instansen i Azure-portalen går du till fliken Ytterligare inställningar och under Geo-replikering väljer du Ja för att använda som sekundär redundans och väljer sedan den primära instansen i listrutan:

PowerShell

Om du skapar din sekundära instans med Azure PowerShell måste du ange parametern DnsZonePartner med zon-ID:t för den primära instansen.

Du kan använda kommandot Get-AzSqlInstance för att parametrisera DNS-zon-ID för den primära instansen och sedan skicka det till parametern DnsZonePartner för kommandot New-AzSqlInstance :

# Get the DNS zone ID of the primary instance
$primaryManagedInstanceId = Get-AzSqlInstance -Name $primaryInstance -ResourceGroupName $resourceGroupName | Select-Object Id

# Create the secondary managed instance
New-AzSqlInstance -Name $secondaryInstance `
                  -ResourceGroupName $resourceGroupName `
                  -Location $drLocation `
                  -SubnetId $secondaryMiSubnetConfigId `
                  -AdministratorCredential $mycreds `
                  -StorageSizeInGB $maxStorage `
                  -VCore $vCores `
                  -Edition $edition `
                  -ComputeGeneration $computeGeneration `
                  -LicenseType $license `
                  -DnsZonePartner $primaryManagedInstanceId.Id
Write-host "Secondary SQL Managed Instance created successfully."

Aktivera anslutning mellan instanserna

Anslut mellan det virtuella nätverkets undernät som är värd för den primära och sekundära instansen måste upprättas för avbrott i trafikflödet för geo-replikering. Det finns flera sätt att upprätta anslutningar mellan hanterade instanser i olika Azure-regioner, inklusive:

• Global peering för virtuella nätverk
• Azure ExpressRoute
• VPN-gateways

Global peering för virtuella nätverk rekommenderassom det mest högpresterande och robusta sättet att upprätta anslutning mellan instanser i en redundansgrupp. Global peering för virtuella nätverk ger en privat anslutning med låg svarstid och hög bandbredd mellan peer-kopplade virtuella nätverk med hjälp av Microsofts staminfrastruktur. Inget offentligt Internet, gatewayer eller ytterligare kryptering krävs i kommunikationen mellan de peerkopplade virtuella nätverken.

Viktigt!

Alternativa sätt att ansluta instanser som omfattar ytterligare nätverksenheter kan komplicera felsökningen av problem med anslutning eller replikeringshastighet, eventuellt kräva aktiv inblandning av nätverksadministratörer och eventuellt avsevärt förlänga lösningstiden.

Oavsett anslutningsmekanism finns det krav som måste uppfyllas för att geo-replikeringstrafiken ska flöda:

• Routningstabeller och nätverkssäkerhetsgrupper som tilldelats hanterade instansundernät delas inte mellan de två peer-kopplade virtuella nätverken.
• NSG-reglerna (Network Security Group) på undernätet som är värd för den primära instansen tillåter:
  • Inkommande trafik på port 5022 och portintervall 11000-11999 från undernätet som är värd för den sekundära instansen.
  • Utgående trafik på port 5022 och portintervall 11000-11999 till undernätet som är värd för den sekundära instansen.
• NSG-reglerna (Network Security Group) på undernätet som är värd för den sekundära instansen tillåter:
  • Inkommande trafik på port 5022 och portintervall 11000-11999 från undernätet som är värd för den primära instansen.
  • Utgående trafik på port 5022 och portintervall 11000-11999 till undernätet som är värd för den primära instansen.
• IP-adressintervall för virtuella nätverk som är värdar för den primära och sekundära instansen får inte överlappa varandra.
• Det finns ingen indirekt överlappning av IP-adressintervall mellan de virtuella nätverk som är värdar för den primära och sekundära instansen, eller andra virtuella nätverk som de peerkopplas med via peering för lokala virtuella nätverk eller på annat sätt.

Om du använder andra mekanismer för att tillhandahålla anslutning mellan instanserna än den rekommenderade globala peeringen för virtuella nätverk måste du dessutom se till att följande:

• Alla nätverksenheter som används, till exempel brandväggar eller virtuella nätverksinstallationer (NVA), blockerar inte trafik på de portar som nämnts tidigare.
• Att routningen är korrekt konfigurerad och att inte asymmetrisk routning används.
• Om du distribuerar redundansgrupper i en nav-och-eker-nätverkstopologi mellan regioner bör replikeringstrafiken gå direkt mellan de två hanterade instansundernäten i stället för att dirigeras via hubbnätverken. Det hjälper dig att undvika problem med anslutning och replikeringshastighet.

Portal

1. I Azure-portalen går du till resursen Virtuellt nätverk för din primära hanterade instans.
2. Välj Peerings under Inställningar och välj sedan + Lägg till.

1. Ange eller välj värden för följande inställningar:

   Inställningar	beskrivning
   Det här virtuella nätverket
   Namn på peeringlänk	Namnet på peering måste vara unikt i det virtuella nätverket.
   Trafik till fjärranslutet virtuellt nätverk	Välj Tillåt (standard) för att aktivera kommunikation mellan de två virtuella nätverken via standardflödet VirtualNetwork . Genom att aktivera kommunikation mellan virtuella nätverk kan resurser som är anslutna till något av de virtuella nätverken kommunicera med varandra med samma bandbredd och svarstid som om de var anslutna till samma virtuella nätverk. All kommunikation mellan resurser i de två virtuella nätverken sker via det privata Azure-nätverket.
   Trafik som vidarebefordras från ett fjärranslutet virtuellt nätverk	Både Tillåten (standard) och Alternativet Blockera fungerar för den här självstudien. Mer information finns i Skapa en peering
   Virtuell nätverksgateway eller routningsserver	Välj Ingen. Mer information om de andra tillgängliga alternativen finns i Skapa en peering.
   Fjärranslutet virtuellt nätverk
   Namn på peeringlänk	Namnet på samma peering som ska användas i det virtuella nätverket som är värd för den sekundära instansen.
   Distributionsmodell för virtuellt nätverk	Välj Resurshanterare.
   Jag känner till mitt resurs-ID	Låt kryssrutan vara avmarkerad.
   Prenumeration	Välj Azure-prenumerationen för det virtuella nätverket som är värd för den sekundära instans som du vill peer-koppla med.
   Virtuellt nätverk	Välj det virtuella nätverk som är värd för den sekundära instans som du vill peer-koppla med. Om det virtuella nätverket visas men är nedtonat kan det bero på att adressutrymmet för det virtuella nätverket överlappar adressutrymmet för det virtuella nätverket. Om adressutrymmen för virtuella nätverk överlappar varandra kan de inte peer-kopplas.
   Trafik till fjärranslutet virtuellt nätverk	Välj Tillåt (standard)
   Trafik som vidarebefordras från ett fjärranslutet virtuellt nätverk	Både Tillåten (standard) och Alternativet Blockera fungerar för den här självstudien. Mer information finns i Skapa en peering.
   Virtuell nätverksgateway eller routningsserver	Välj Ingen. Mer information om de andra tillgängliga alternativen finns i Skapa en peering.

2. Välj Lägg till för att konfigurera peering med det virtuella nätverk som du har valt. Efter några sekunder väljer du knappen Uppdatera så ändras peeringstatusen från Uppdatera till Anslut ed.

   

PowerShell

Konfigurera global peering för virtuella nätverk mellan de virtuella nätverken för de primära och sekundära hanterade instanserna:

# Create global virtual network peering
$primaryVirtualNetwork  = Get-AzVirtualNetwork `
                  -Name $primaryVNet `
                  -ResourceGroupName $resourceGroupName

$secondaryVirtualNetwork = Get-AzVirtualNetwork `
                  -Name $secondaryVNet `
                  -ResourceGroupName $resourceGroupName
                  
Write-host "Peering primary VNet to secondary VNet..."
Add-AzVirtualNetworkPeering `
 -Name primaryVnet-secondaryVNet1 `
 -VirtualNetwork $primaryVirtualNetwork `
 -RemoteVirtualNetworkId $secondaryVirtualNetwork.Id
 Write-host "Primary VNet peered to secondary VNet successfully."

Write-host "Peering secondary VNet to primary VNet..."
Add-AzVirtualNetworkPeering `
 -Name secondaryVNet-primaryVNet `
 -VirtualNetwork $secondaryVirtualNetwork `
 -RemoteVirtualNetworkId $primaryVirtualNetwork.Id
Write-host "Secondary VNet peered to primary VNet successfully."

Write-host "Checking peering state on the primary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $primaryVNet `
| Select PeeringState

Write-host "Checking peering state on the secondary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $secondaryVNet `
| Select PeeringState

Det här kodfragmentet använder följande kommandon:

Command	Kommentar
1. Get-AzVirtualNetwork	Hämtar ett virtuellt nätverk i en resursgrupp.
2. Add-AzVirtualNetworkPeering	Lägger till en peering i ett virtuellt nätverk.
3. Get-AzVirtualNetworkPeering	Hämtar en peering för ett virtuellt nätverk.

Skapa redundansgruppen

Skapa redundansgruppen för dina hanterade instanser med hjälp av Azure-portalen eller PowerShell.

Portal

Skapa redundansgruppen för dina SQL Managed Instances med hjälp av Azure-portalen.

1. Välj Azure SQL på den vänstra menyn i Azure-portalen. Om Azure SQL inte finns med i listan väljer du Alla tjänster och skriver sedan Azure SQL i sökrutan. (Valfritt) Välj stjärnan bredvid Azure SQL för att lägga till den som ett favoritobjekt i det vänstra navigeringsfältet.

2. Välj den primära hanterade instans som du vill lägga till i redundansgruppen.

3. Under Inställningar navigerar du till Instans redundansgrupper och väljer sedan Lägg till grupp för att öppna sidan för att skapa instansens redundansklustergrupp.

   

4. På sidan Redundansgrupp för instans skriver du namnet på redundansgruppen och väljer sedan den sekundära hanterade instansen i listrutan. Välj Skapa när du vill skapa redundansgruppen.

   

5. När distributionen av redundansklustergruppen är klar tas du tillbaka till sidan Redundansgrupp .

PowerShell

Använd New-AzSqlDatabaseInstanceFailoverGroup för att skapa redundansgruppen för dina hanterade instanser med hjälp av PowerShell.

# Create failover group
Write-host "Creating the failover group..."
$failoverGroup = New-AzSqlDatabaseInstanceFailoverGroup -Name $failoverGroupName `
     -Location $location -ResourceGroupName $resourceGroupName -PrimaryManagedInstanceName $primaryInstance `
     -PartnerRegion $drLocation -PartnerManagedInstanceName $secondaryInstance `
     -FailoverPolicy Manual -GracePeriodWithDataLossHours 1
$failoverGroup

Redundanstest

Testa redundans för din redundansgrupp med hjälp av Azure-portalen eller PowerShell.

Portal

Testa redundans för redundansgruppen med hjälp av Azure-portalen.

1. Gå till den sekundära hanterade instansen i Azure-portalen och välj Instansredundansgrupper under inställningar.

2. Anteckna hanterade instanser i den primära och sekundära rollen.

3. Välj Redundans och välj sedan Ja på varningen om att TDS-sessioner kopplas från.

   

4. Anteckna hanterade instanser i den primära och sekundära rollen. Om redundansväxlingen lyckades bör de två instanserna ha växlade roller.

   

Viktigt!

Om rollerna inte växlade kontrollerar du anslutningen mellan instanserna och relaterade NSG- och brandväggsregler. Fortsätt med nästa steg först efter att rollerna har växlats.

1. Gå till den nya sekundära hanterade instansen och välj Redundans igen för att återställa den primära instansen till den primära rollen.

PowerShell

Testa planerad redundans genom att redundansväxla till den sekundära repliken och sedan återställa.

Verifiera rollerna för varje server

Använd kommandot Get-AzSqlDatabaseInstanceFailoverGroup för att bekräfta rollerna för varje server:

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Redundansvämna till den sekundära servern

Använd Switch-AzSqlDatabaseFailoverGroup för att redundansväxla till den sekundära servern.

# Failover the primary managed instance to the secondary role
Write-host "Failing primary over to the secondary location"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to secondary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName

Återställ redundansgruppen till den primära servern

Använd kommandot Switch-AzSqlDatabaseFailoverGroup för att återställa till den primära servern.

# Fail primary managed instance back to primary role
Write-host "Failing primary back to primary role"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to primary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Verifiera rollerna för varje server

Använd kommandot Get-AzSqlDatabaseFailoverGroup för att bekräfta rollerna för varje server.

# Check role of secondary replica
Write-host "Confirming the secondary replica is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Redundansvämna till den sekundära servern

Använd Switch-AzSqlDatabaseFailoverGroup för att redundansväxla till den sekundära servern.

# Failover to secondary server
Write-host "Failing over failover group to the secondary..." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully to" $drServerName 

Write-host "Confirming the secondary server is now primary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Återställ redundansgruppen till den primära servern

Använd kommandot Switch-AzSqlDatabaseFailoverGroup för att återställa till den primära servern.

# Revert failover to primary server
Write-host "Failing over failover group to the primary...." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully back to" $serverName

Hitta lyssnarslutpunkten

När redundansgruppen har konfigurerats uppdaterar du anslutningssträng för programmet till lyssnarens slutpunkt. Programmet är anslutet till lyssnaren för redundansgruppen i stället för den primära databasen, den elastiska poolen eller instansdatabasen. På så sätt behöver du inte uppdatera anslutningssträng manuellt varje gång databasentiteten redundansväxlar och trafiken dirigeras till den entitet som för närvarande är primär.

Lyssnarens slutpunkt är i form av fog-name.database.windows.netoch visas i Azure-portalen när du visar redundansgruppen:

Skapa grupp mellan instanser i olika prenumerationer

Du kan skapa en redundansgrupp mellan SQL Managed Instances i två olika prenumerationer, så länge prenumerationer är associerade med samma Microsoft Entra-klientorganisation.

• När du använder PowerShell API kan du göra det genom att ange parametern PartnerSubscriptionId för den sekundära SQL Managed Instance.
• När du använder REST API kan varje instans-ID som ingår i parametern properties.managedInstancePairs ha ett eget prenumerations-ID.
• Azure-portalen stöder inte skapande av redundansgrupper i olika prenumerationer.

Viktigt!

Azure-portalen stöder inte skapande av redundansgrupper i olika prenumerationer. För redundansgrupper i olika prenumerationer och/eller resursgrupper kan redundans inte initieras manuellt via Azure-portalen från den primära SQL-hanterade instansen. Starta från den geo-sekundära instansen i stället.

Förhindra förlust av kritiska data

På grund av den långa svarstiden för nätverk i stora områden använder geo-replikering en asynkron replikeringsmekanism. Asynkron replikering gör risken för dataförlust oundviklig om den primära replikeringen misslyckas. För att skydda kritiska transaktioner mot dataförlust kan en programutvecklare anropa den sp_wait_for_database_copy_sync lagrade proceduren omedelbart efter att transaktionen har genomförts. Anrop sp_wait_for_database_copy_sync blockerar den anropande tråden tills den senast checkade transaktionen har överförts och härdats i transaktionsloggen för den sekundära databasen. Det väntar dock inte på att de överförda transaktionerna ska spelas upp igen (görs om) på den sekundära. sp_wait_for_database_copy_sync är begränsad till en specifik geo-replikeringslänk. Alla användare med anslutningsrättigheter till den primära databasen kan anropa den här proceduren.

Kommentar

sp_wait_for_database_copy_sync förhindrar dataförlust efter geo-redundans för specifika transaktioner, men garanterar inte fullständig synkronisering för läsåtkomst. Fördröjningen som orsakas av ett sp_wait_for_database_copy_sync proceduranrop kan vara betydande och beror på storleken på den ännu inte överförda transaktionsloggen på den primära vid tidpunkten för anropet.

Ändra den sekundära regionen

Anta att instans A är den primära instansen, instans B är den befintliga sekundära instansen och instans C är den nya sekundära instansen i den tredje regionen. Gör övergången genom att följa dessa steg:

1. Skapa instans C med samma storlek som A och i samma DNS-zon.
2. Ta bort redundansgruppen mellan instanserna A och B. Försök att logga in börjar misslyckas eftersom SQL-aliasen för lyssnarna för redundansgruppen har tagits bort och gatewayen inte känner igen namnet på redundansklustergruppen. De sekundära databaserna kopplas från primärvalen och blir skrivskyddade databaser.
3. Skapa en redundansgrupp med samma namn mellan instans A och C. Följ anvisningarna i guiden Konfigurera redundansgrupp. Det här är en datastorleksåtgärd som slutförs när alla databaser från instans A är seedade och synkroniserade.
4. Ta bort instans B om det inte behövs för att undvika onödiga avgifter.

Kommentar

Efter steg 2 och tills steg 3 har slutförts förblir databaserna i instans A oskyddade från ett oåterkalleligt fel i instans A.

Ändra den primära regionen

Anta att instans A är den primära instansen, instans B är den befintliga sekundära instansen och instans C är den nya primära instansen i den tredje regionen. Gör övergången genom att följa dessa steg:

1. Skapa instans C med samma storlek som B och i samma DNS-zon.
2. Anslut till instans B och manuellt redundansväxla den primära instansen till B. Instans A blir automatiskt den nya sekundära instansen.
3. Ta bort redundansgruppen mellan instanserna A och B. Nu börjar inloggningsförsök med slutpunkter för redundansgrupper att misslyckas. De sekundära databaserna på A är frånkopplade från primärvalen och blir skrivskyddade databaser.
4. Skapa en redundansgrupp med samma namn mellan instans B och C. Följ anvisningarna i guiden för redundansgrupper. Det här är en datastorleksåtgärd som slutförs när alla databaser från instans A är seedade och synkroniserade. Nu slutar inloggningsförsöken att misslyckas.
5. Redundansväxla manuellt för att växla C-instansen till primär roll. Instans B blir automatiskt den nya sekundära instansen.
6. Ta bort instans A om det inte behövs för att undvika onödiga avgifter.

Varning

Efter steg 3 och tills steg 4 har slutförts förblir databaserna i instans A oskyddade från ett oåterkalleligt fel i instans A.

Viktigt!

När redundansgruppen tas bort tas även DNS-posterna för lyssnarens slutpunkter bort. Då finns det en sannolikhet som inte är noll för att någon annan ska skapa en redundansgrupp med samma namn. Eftersom namn på redundanskluster måste vara globalt unika hindrar detta dig från att använda samma namn igen. Använd inte generiska redundansklusternamn för att minimera den här risken.

Aktivera scenarier som är beroende av objekt från systemdatabaserna

Systemdatabaser replikeras inte till den sekundära instansen i en redundansgrupp. Om du vill möjliggöra scenarier som är beroende av objekt från systemdatabaserna ska du skapa samma objekt i den sekundära instansen och hålla dem synkroniserade med den primära instansen.

Om du till exempel planerar att använda samma inloggningar på den sekundära instansen måste du skapa dem med samma SID.

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

Mer information finns i Replikering av inloggningar och agentjobb.

Synkronisera instansegenskaper och instanser av kvarhållningsprinciper

Instanser i en redundansgrupp förblir separata Azure-resurser och inga ändringar som görs i konfigurationen av den primära instansen replikeras automatiskt till den sekundära instansen. Se till att utföra alla relevanta ändringar både på den primära och sekundära instansen. Om du till exempel ändrar redundans för lagring av säkerhetskopior eller långsiktig kvarhållningsprincip för säkerhetskopiering på den primära instansen måste du även ändra den på den sekundära instansen.

Skalningsinstanser

Du kan skala upp eller skala ned den primära och sekundära instansen till en annan beräkningsstorlek inom samma tjänstnivå eller till en annan tjänstnivå. När du skalar upp inom samma tjänstnivå rekommenderar vi att du skalar upp den geo-sekundära först och sedan skalar upp den primära. När du skalar ned inom samma tjänstnivå ändrar du ordningen: skala ned den primära först och skala sedan ned den sekundära. När du skalar instansen till en annan tjänstnivå framtvingas den här rekommendationen.

Den här sekvensen rekommenderas särskilt för att undvika problemet där den geo-sekundära instansen med en lägre SKU blir överbelastad och måste dirigeras om under en uppgradering eller nedgradering.

Behörigheter

Behörigheter för en redundansgrupp hanteras via rollbaserad åtkomstkontroll i Azure (Azure RBAC).

Skrivåtkomst för Azure RBAC krävs för att skapa och hantera redundansgrupper. Rollen SQL Managed Instance-deltagare har alla behörigheter som krävs för att hantera redundansgrupper.

I följande tabell visas specifika behörighetsomfång för Azure SQL Managed Instance:

Åtgärd	Behörighet	Definitionsområde
Skapa en redundansgrupp	Skrivåtkomst för Azure RBAC	Primär hanterad instans Sekundär hanterad instans
Uppdatera redundansgrupp	Skrivåtkomst för Azure RBAC	Redundansgrupp Alla databaser i den hanterade instansen
Redundansväxlingsgrupp	Skrivåtkomst för Azure RBAC	Redundansgrupp på ny primär hanterad instans

Begränsningar

Tänk på följande begränsningar:

• Redundansgrupper kan inte skapas mellan två instanser i samma Azure-region.
• Det går inte att byta namn på redundansgrupper. Du måste ta bort gruppen och återskapa den med ett annat namn.
• En redundansgrupp innehåller exakt två hanterade instanser. Det går inte att lägga till ytterligare instanser i redundansgruppen.
• En instans kan bara delta i en redundansgrupp när som helst.
• Det går inte att skapa en redundansgrupp mellan två instanser som tillhör olika Azure-klientorganisationer.
• Det går inte att skapa en redundansgrupp mellan två instanser som tillhör olika Azure-prenumerationer med Hjälp av Azure-portalen eller Azure CLI. Använd Azure PowerShell eller REST API i stället för att skapa en sådan redundansgrupp. När den har skapats visas redundansgrupper mellan prenumerationer regelbundet i Azure-portalen och alla efterföljande åtgärder, inklusive redundansväxlingar, kan initieras från Azure-portalen eller Azure CLI.
• Databasbyte stöds inte för databaser i redundansgrupper. Du måste tillfälligt ta bort redundans för att kunna byta namn på en databas.
• Systemdatabaser replikeras inte till den sekundära instansen i en redundansgrupp. Därför kräver scenarier som är beroende av objekt från systemdatabaser som serverinloggningar och agentjobb att objekt skapas manuellt på de sekundära instanserna och även synkroniseras manuellt efter ändringar som gjorts på den primära instansen. Det enda undantaget är Tjänstens huvudnyckel (SMK) för SQL Managed Instance som replikeras automatiskt till sekundär instans när redundansgruppen skapas. Eventuella efterföljande ändringar av SMK på den primära instansen replikeras dock inte till den sekundära instansen. Mer information finns i Aktivera scenarier som är beroende av objekt från systemdatabaserna.
• Redundansgrupper kan inte skapas mellan instanser om någon av dem finns i en instanspool.

Hantera redundansgrupper programmatiskt

Redundansgrupper kan också hanteras programmatiskt med hjälp av Azure PowerShell, Azure CLI och REST API. I följande tabeller beskrivs vilken uppsättning kommandon som är tillgängliga. Redundansgrupper innehåller en uppsättning Azure Resource Manager-API:er för hantering, inklusive Azure SQL Database REST API och Azure PowerShell-cmdletar. Dessa API:er kräver användning av resursgrupper och stöder rollbaserad åtkomstkontroll i Azure (Azure RBAC). Mer information om hur du implementerar åtkomstroller finns i Rollbaserad åtkomstkontroll i Azure (Azure RBAC).

PowerShell

Cmdlet	beskrivning
New-AzSqlDatabaseInstanceFailoverGroup	Det här kommandot skapar en redundansgrupp och registrerar den på både primära och sekundära instanser
Set-AzSqlDatabaseInstanceFailoverGroup	Ändrar konfigurationen av en redundansgrupp
Get-AzSqlDatabaseInstanceFailoverGroup	Hämtar konfigurationen för en redundansgrupp
Switch-AzSqlDatabaseInstanceFailoverGroup	Utlöser redundans för en redundansgrupp till den sekundära instansen
Remove-AzSqlDatabaseInstanceFailoverGroup	Tar bort en redundansgrupp

Azure CLI

Kommando	beskrivning
az sql instance-failover-group create	Det här kommandot skapar en redundansgrupp och registrerar den på både primära och sekundära servrar
az sql instance-failover-group delete	Tar bort en redundansgrupp från servern
az sql instance-failover-group show	Hämtar en konfiguration av redundanskluster
az sql instance-failover-group update	Ändrar en redundansgrupps konfiguration och/eller lägger till en eller flera databaser i en redundansgrupp
az sql instance-failover-group set-primary	Utlöser redundansväxling av en redundansgrupp till den sekundära servern

REST-API

API	beskrivning
Skapa eller uppdatera redundansgrupp	Skapar eller uppdaterar konfigurationen för en redundansgrupp
Ta bort redundansgrupp	Tar bort en redundansgrupp från instansen
Redundansväxling (planerad)	Utlöser redundans från den aktuella primära instansen till den här instansen med fullständig datasynkronisering.
Framtvinga redundans tillåt dataförlust	Utlöser redundans från den aktuella primära instansen till den sekundära instansen utan att synkronisera data. Den här åtgärden kan leda till dataförlust.
Hämta redundansgrupp	hämtar konfigurationen för en redundansgrupp.
Lista redundansgrupper – lista efter plats	Visar en lista över redundansgrupper på en plats.

Nästa steg

Anvisningar för hur du konfigurerar en redundansgrupp finns i guiden Lägg till en hanterad instans i en redundansgrupp .

En översikt över funktionen finns i Redundansgrupper. Information om hur du sparar på licenskostnader finns i Konfigurera standby-replik.