Konfigurera en redundansgrupp för Azure SQL Database

Gäller för:Azure SQL Database

• Azure SQL Database
• Hanterad Azure SQL-instans

I den här artikeln får du lära dig hur du konfigurerar en redundansgrupp för enkla databaser och pooldatabaser i Azure SQL Database med hjälp av Azure-portalen, Azure PowerShell och Azure CLI.

För skript från slutpunkt till slutpunkt läser du hur du lägger till en enskild databas i en redundansgrupp med Azure PowerShell eller Azure CLI.

Förutsättningar

Tänk på följande förutsättningar för att skapa redundansgruppen för en enskild databas:

• Serverinloggnings- och brandväggsinställningarna för den sekundära servern måste matcha den primära serverns inställningar.

Skapa en redundansgrupp

Portal

Skapa redundansgruppen och lägg till din enkla databas i den 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 favoritmarka den och lägg till den som ett objekt i det vänstra navigeringsfältet.

2. Välj den databas som du vill lägga till i redundansgruppen.

3. Välj namnet på servern under Servernamn för att öppna inställningarna för servern.

   

4. Välj Redundansgrupper under fönstret Inställningar och välj sedan Lägg till grupp för att skapa en ny redundansgrupp.

   

5. På sidan Redundansgrupp anger eller väljer du de värden som krävs och väljer sedan Skapa. Skapa antingen en ny sekundär server eller välj en befintlig sekundär server. Den sekundära servern i redundansgruppen måste finnas i en annan region än den primära servern.

   • Databaser i gruppen: Välj den databas som du vill lägga till i redundansgruppen. Om du lägger till databasen i redundansgruppen startas automatiskt geo-replikeringsprocessen.

   

PowerShell

Skapa redundansgruppen och lägg till databasen i den med hjälp av PowerShell.

Använd New-AzSqlDatabaseFailoverGroup för att skapa redundansgruppen:

# Create a failover group between the servers
$failovergroup = Write-host "Creating a failover group between the primary and secondary server..."
New-AzSqlDatabaseFailoverGroup `
   –ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -PartnerServerName $drServerName  `
   –FailoverGroupName $failoverGroupName `
   –FailoverPolicy Manual
$failovergroup

Använd kommandona Get-AzSqlDatabase och Add-AzSqlDatabaseToFailoverGroup för att lägga till databasen i redundansgruppen:

# Add the database to the failover group
Write-host "Adding the database to the failover group..." 
Get-AzSqlDatabase `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -DatabaseName $databaseName | `
Add-AzSqlDatabaseToFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Successfully added the database to the failover group..."

Kommentar

Det går att distribuera redundansgruppen mellan prenumerationer med hjälp av parametern -PartnerSubscriptionId i Azure Powershell som börjar med Az.SQL 3.11.0. Mer information finns i följande exempel.

Azure CLI

I det här steget skapar du redundansgruppen och lägger till databasen i den med hjälp av Azure CLI.

Använd az sql failover-group create och för att skapa en redundansgrupp och lägga till databasen i redundansgruppen:

echo "Creating $failoverGroup between $server and $secondaryServer..."
az sql failover-group create --name $failoverGroup --partner-server $secondaryServer --resource-group $resourceGroup --server $server --failover-policy Automatic --grace-period 2 --add-db $database

Testa planerad redundans

Testa redundans för redundansgruppen utan dataförlust med hjälp av Azure-portalen eller PowerShell.

Portal

Testa redundans för redundansgruppen 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 favoritmarka den och lägg till den som ett objekt i det vänstra navigeringsfältet.

2. Välj den databas som du vill lägga till i redundansgruppen.

   

3. Välj Redundansgrupper under fönstret Inställningar och välj sedan den redundansgrupp som du nyss skapade.

   

4. Granska vilken server som är primär och vilken server som är sekundär.

5. Välj Redundans i åtgärdsfönstret för att redundansväxla redundansgruppen som innehåller databasen.

6. Välj Ja på varningen som meddelar dig att TDS-sessioner kommer att kopplas från.

   

7. Granska vilken server som nu är primär och vilken server som är sekundär. Om redundansväxlingen lyckades bör de två servrarna ha växlade roller.

8. Välj Redundans igen för att återställa servrarna till sina ursprungliga roller.

PowerShell

Testa redundans för redundansgruppen med hjälp av PowerShell.

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

Azure CLI

Testa redundans med hjälp av Azure CLI.

Verifiera rollerna för varje server

Använd kommandot az sql failover-group show för att bekräfta rollerna för varje server.

echo "Confirming the role of each server in the failover group..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Redundansvämna till den sekundära servern

Använd az sql failover-group set-primary för att redundansväxla till den sekundära servern. Använd kommandot az sql failover-group show för att verifiera en lyckad redundansväxling.

echo "Failing over to $secondaryServer..."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $secondaryServer 

echo "Confirming role of $secondaryServer is now primary..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Återställ redundansgruppen till den primära servern

Använd kommandot az sql failover-group set-primary för att återställa till den primära servern.

echo "Failing back to $server...."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $server

Viktigt!

Om du behöver ta bort den sekundära databasen tar du bort den från redundansgruppen innan du tar bort den. Om du tar bort en sekundär databas innan den tas bort från redundansgruppen kan det orsaka oförutsägbart beteende.

För skript från slutpunkt till slutpunkt läser du hur du lägger till en elastisk pool i en redundansgrupp med Azure PowerShell eller Azure CLI.

Förutsättningar

Överväg följande förutsättningar för att skapa redundansgruppen för en pooldatabas:

• Serverinloggnings- och brandväggsinställningarna för den sekundära servern måste matcha den primära serverns inställningar.

Skapa en redundansgrupp

Skapa redundansgruppen för din elastiska pool med hjälp av Azure-portalen eller PowerShell.

Portal

Skapa redundansgruppen och lägg till den elastiska poolen i den 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 favoritmarka den och lägg till den som ett objekt i det vänstra navigeringsfältet.

2. Välj den elastiska pool som du vill lägga till i redundansgruppen.

3. I fönstret Översikt väljer du namnet på servern under Servernamn för att öppna inställningarna för servern.

   

4. Välj Redundansgrupper under fönstret Inställningar och välj sedan Lägg till grupp för att skapa en ny redundansgrupp.

   

5. På sidan Redundansgrupp anger eller väljer du de värden som krävs och väljer sedan Skapa. Skapa antingen en ny sekundär server eller välj en befintlig sekundär server.

6. Välj Databaser i gruppen och välj den elastiska pool som du vill lägga till i redundansgruppen. Om det inte redan finns en elastisk pool på den sekundära servern visas en varning som uppmanar dig att skapa en elastisk pool på den sekundära servern. Välj varningen och välj sedan OK för att skapa den elastiska poolen på den sekundära servern.

   

7. Använd Välj för att tillämpa inställningarna för den elastiska poolen på redundansgruppen och välj sedan Skapa för att skapa redundansgruppen. Om du lägger till den elastiska poolen i redundansgruppen startas geo-replikeringsprocessen automatiskt.

PowerShell

Skapa redundansgruppen och lägg till den elastiska poolen i den med hjälp av PowerShell.

Använd New-AzSqlDatabaseFailoverGroup för att skapa redundansgruppen:

# Create a failover group between the servers
Write-host "Creating failover group..." 
New-AzSqlDatabaseFailoverGroup `
  –ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -PartnerServerName $drServerName  `
   –FailoverGroupName $failoverGroupName `
   –FailoverPolicy Manual
Write-host "Failover group created successfully."

Använd kommandona Get-AzSqlDatabaseFailoverGroup och Get-AzSqlElasticPoolDatabase för att lägga till databasen i redundansgruppen:

# Add elastic pool to the failover group
Write-host "Enumerating databases in elastic pool...." 
$FailoverGroup = Get-AzSqlDatabaseFailoverGroup `
                 -ResourceGroupName $resourceGroupName `
                 -ServerName $serverName `
                 -FailoverGroupName $failoverGroupName
$databases = Get-AzSqlElasticPoolDatabase `
               -ResourceGroupName $resourceGroupName `
               -ServerName $serverName `
               -ElasticPoolName $poolName
Write-host "Adding databases to failover group..." 
$failoverGroup = $failoverGroup | Add-AzSqlDatabaseToFailoverGroup `
                                  -Database $databases 
$failoverGroup

Azure CLI

I det här steget skapar du redundansgruppen och lägger till databasen i den med hjälp av Azure CLI.

Använd kommandot az sql failover-group create för att skapa en redundansgrupp.

echo "Creating $failoverGroup between $server and $secondaryServer..."
az sql failover-group create --name $failoverGroup --partner-server $secondaryServer --resource-group $resourceGroup --server $server --failover-policy Automatic --grace-period 2
databaseId=$(az sql elastic-pool list-dbs --name $pool --resource-group $resourceGroup --server $server --query [0].name -o json | tr -d '"')

Använd kommandot az sql failover-group update för att lägga till en databas i redundansgruppen.

echo "Adding $database to $failoverGroup..."
az sql failover-group update --name $failoverGroup --add-db $databaseId --resource-group $resourceGroup --server $server

Testa planerad redundans

Testa redundans utan dataförlust av din elastiska pool med hjälp av Azure-portalen eller PowerShell.

Portal

Redundansväxla redundansgruppen till den sekundära servern och redundansväxla sedan 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 favoritmarka den och lägg till den som ett objekt i det vänstra navigeringsfältet.

2. Välj den elastiska pool som du vill redundansväxla.

3. I fönstret Översikt väljer du namnet på servern under Servernamn för att öppna inställningarna för servern.

   

4. Välj Redundansgrupper under Inställningar och välj sedan den redundansgrupp som du skapade tidigare.

   

5. Granska vilken server som är primär och vilken server som är sekundär.

6. Välj Redundans i åtgärdsfönstret för att redundansväxla redundansgruppen som innehåller den elastiska poolen.

7. Välj Ja på varningen som meddelar dig att TDS-sessioner kommer att kopplas från.

   

8. Granska vilken server som är primär, vilken server som är sekundär. Om redundansväxlingen lyckades bör de två servrarna ha växlade roller.

9. Välj Redundans igen för att återställa redundansgruppen till de ursprungliga inställningarna.

PowerShell

Testa redundans för redundansgruppen med hjälp av PowerShell med hjälp av följande PowerShell-kommandon:

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 server 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 "Failover group failed over to" $drServerName 

# Check role of secondary replica
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 "Failover group failed over to" $serverName

Azure CLI

Testa redundans med hjälp av Azure CLI.

Verifiera rollerna för varje server

Använd kommandot az sql failover-group show för att bekräfta rollerna för varje server i redundansgruppen.

echo "Confirming the role of each server in the failover group..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Redundansvämna till den sekundära servern

Använd kommandot az sql failover-group set-primary för att redundansväxla till den sekundära servern. Använd kommandot az sql failover-group show för att verifiera en lyckad redundansväxling.

echo "Failing over to $secondaryServer..."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $secondaryServer 

echo "Confirming role of $secondaryServer is now primary..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Återställ redundansgruppen till den primära servern

Använd kommandot az sql failover-group set-primary för att återställa till den primära servern.

echo "Failing back to $server...."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $server

Viktigt!

Om du behöver ta bort den sekundära databasen tar du bort den från redundansgruppen innan du tar bort den. Om du tar bort en sekundär databas innan den tas bort från redundansgruppen kan det orsaka oförutsägbart beteende.

Använda Private Link

Med en privat länk kan du associera en logisk server med en specifik privat IP-adress i det virtuella nätverket och undernätet.

Om du vill använda en privat länk med redundansgruppen gör du följande:

1. Kontrollera att dina primära och sekundära servrar finns i en parkopplad region.
2. Skapa det virtuella nätverket och undernätet i varje region som värd för privata slutpunkter för primära och sekundära servrar så att de inte har ip-adressutrymmen som inte överlappar varandra. Till exempel överlappar adressintervallet 10.0.0.0/16 för det primära virtuella nätverket och adressintervallet 10.0.0.1/16 för det sekundära virtuella nätverket . Mer information om adressintervall för virtuella nätverk finns i bloggen om att designa virtuella Azure-nätverk.
3. Skapa en privat slutpunkt och en Azure Privat DNS-zon för den primära servern.
4. Skapa även en privat slutpunkt för den sekundära servern, men den här gången väljer du att återanvända samma privata DNS-zon som för den primära servern.
5. När den privata länken har upprättats kan du skapa redundansgruppen genom att följa stegen som beskrevs tidigare i den här artikeln.

Hitta lyssnarslutpunkten

När redundansgruppen har konfigurerats uppdaterar du anslutningssträng för programmet till lyssnarens slutpunkt. Detta håller ditt program anslutet till lyssnaren för redundansgruppen i stället för den primära databasen eller den elastiska poolen. 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:

Skala databaser i en redundansgrupp

Du kan skala upp eller ned den primära databasen till en annan beräkningsstorlek (inom samma tjänstnivå) utan att koppla från några geo-sekundärfiler. När du skalar upp rekommenderar vi att du skalar upp den geo-sekundära först och sedan skalar upp den primära. När du skalar ned gör du det i omvänd ordning: skala ned den primära först och sedan den sekundära. När du skalar en databas till en annan tjänstnivå tillämpas den här rekommendationen.

Den här sekvensen rekommenderas specifikt för att undvika problemet där den geo-sekundära vid en lägre SKU överbelastas och måste återställas under en uppgraderings- eller nedgraderingsprocess. Du kan också undvika problemet genom att göra den primära instansen skrivskyddad, vilket dock påverkar alla arbetsbelastningar med skrivningar mot den primära instansen.

Kommentar

Om du har skapat en geo-sekundär som en del av konfigurationen av en redundansgrupp, rekommenderar vi inte att du skalar ned den geo-sekundära. Detta säkerställer att datanivån har tillräckligt med kapacitet för att bearbeta din normala arbetsbelastning efter en geo-redundansväxling. Du kanske inte kan skala en geo-sekundär efter en oplanerad redundansväxling när den tidigare geo-primära inte är tillgänglig på grund av avbrott. Det här är en känd begränsning.

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

För att illustrera ändringssekvensen förutsätter vi att server A är den primära servern, att server B är den befintliga sekundära servern och att server C är den nya sekundära i den tredje regionen. Gör övergången genom att följa dessa steg:

1. Skapa ytterligare sekundärfiler för varje databas på server A till server C med aktiv geo-replikering. Varje databas på server A har två sekundärfiler, en på server B och en på server C. Detta garanterar att de primära databaserna förblir skyddade under övergången.
2. Ta bort redundansgruppen. Nu börjar inloggningsförsök med slutpunkter för redundansgrupper att misslyckas.
3. Återskapa redundansgruppen med samma namn mellan servrarna A och C.
4. Lägg till alla primära databaser på server A i den nya redundansgruppen. Nu slutar inloggningsförsöken att misslyckas.
5. Ta bort server B. Alla databaser på B tas bort automatiskt.

Ändra den primära regionen

För att illustrera ändringssekvensen antar vi att server A är den primära servern, server B är den befintliga sekundära servern och att server C är den nya primära i den tredje regionen. Gör övergången genom att följa dessa steg:

1. Utför en planerad geo-redundansväxling för att växla den primära servern till B. Server A blir den nya sekundära servern. Redundansväxlingen kan resultera i flera minuters stilleståndstid. Den faktiska tiden beror på storleken på redundansgruppen.
2. Skapa ytterligare sekundärfiler för varje databas på server B till server C med aktiv geo-replikering. Varje databas på server B har två sekundärfiler, en på server A och en på server C. Detta garanterar att de primära databaserna förblir skyddade under övergången.
3. Ta bort redundansgruppen. Nu börjar inloggningsförsök med slutpunkter för redundansgrupper att misslyckas.
4. Återskapa redundansgruppen med samma namn mellan servrarna B och C.
5. Lägg till alla primära databaser på B i den nya redundansgruppen. Nu slutar inloggningsförsöken att misslyckas.
6. Utför en planerad geo-redundansväxling för redundansgruppen för att växla B och C. Nu blir server C den primära och B den sekundära. Alla sekundära databaser på server A länkas automatiskt till primärvalen på C. Precis som i steg 1 kan redundansväxlingen resultera i flera minuters stilleståndstid.
7. Ta bort server A. Alla databaser på A tas bort automatiskt.

Viktigt!

När redundansgruppen tas bort tas även DNS-posterna för lyssnarens slutpunkter bort. Då är sannolikheten inte noll att någon annan skapar en redundansgrupp eller ett DNS-alias för servern med samma namn. Eftersom namn på redundanskluster och DNS-alias 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.

Redundansgrupper och nätverkssäkerhet

För vissa program kräver säkerhetsreglerna att nätverksåtkomsten till datanivån är begränsad till en specifik komponent eller komponenter som en virtuell dator, webbtjänst osv. Det här kravet innebär vissa utmaningar för affärskontinuitetsdesign och användning av redundansgrupper. Överväg följande alternativ när du implementerar sådan begränsad åtkomst.

Använda redundansgrupper och tjänstslutpunkter för virtuella nätverk

Om du använder tjänstslutpunkter och regler för virtuellt nätverk för att begränsa åtkomsten till databasen bör du vara medveten om att varje tjänstslutpunkt för virtuellt nätverk endast gäller för en Azure-region. Slutpunkten gör det inte möjligt för andra regioner att acceptera kommunikation från undernätet. Därför kan endast klientprogram som distribueras i samma region ansluta till den primära databasen. Eftersom en geo-redundans resulterar i att SQL Database-klientsessionerna omdirigeras till en server i en annan (sekundär) region, kan dessa sessioner misslyckas om de kommer från en klient utanför den regionen. Därför kan inte Microsofts hanterade redundansprincip aktiveras om de deltagande servrarna ingår i reglerna för virtuellt nätverk. Följ dessa steg för att stödja manuell redundansprincip:

1. Etablera redundanta kopior av klientdelskomponenterna i ditt program (webbtjänst, virtuella datorer osv.) i den sekundära regionen.
2. Konfigurera regler för virtuella nätverk individuellt för den primära och sekundära servern.
3. Aktivera redundansväxling i klientdelen med hjälp av en Traffic Manager-konfiguration.
4. Initiera en manuell geo-redundans när avbrottet identifieras. Det här alternativet är optimerat för program som kräver konsekvent svarstid mellan klientdelen och datanivån och stöder återställning när antingen klientdelen, datanivån eller båda påverkas av avbrotten.

Kommentar

Om du använder den skrivskyddade lyssnaren för att belastningsutjämning en skrivskyddad arbetsbelastning ska du kontrollera att den här arbetsbelastningen körs på en virtuell dator eller någon annan resurs i den sekundära regionen så att den kan ansluta till den sekundära databasen.

Använda redundansgrupper och brandväggsregler

Om din affärskontinuitetsplan kräver redundans med hjälp av redundansgrupper kan du begränsa åtkomsten till din SQL Database med hjälp av offentliga IP-brandväggsregler. Den här konfigurationen säkerställer att en geo-redundans inte blockerar anslutningar från klientdelskomponenter och förutsätter att programmet kan tolerera längre svarstider mellan klientdelen och datanivån.

Följ dessa steg för att stödja redundansväxling av redundansgrupper:

1. Skapa en offentlig IP-adress.
2. Skapa en offentlig lastbalanserare och tilldela den offentliga IP-adressen till den.
3. Skapa ett virtuellt nätverk och de virtuella datorerna för dina klientdelskomponenter .
4. Skapa en nätverkssäkerhetsgrupp och konfigurera inkommande anslutningar.
5. Kontrollera att de utgående anslutningarna är öppna för Azure SQL Database i en region med hjälp av en Sql.<Region>tjänsttagg.
6. Skapa en SQL Database-brandväggsregel för att tillåta inkommande trafik från den offentliga IP-adress som du skapar i steg 1.

Mer information om hur du konfigurerar utgående åtkomst och vilken IP-adress som ska användas i brandväggsreglerna finns i Utgående anslutningar för lastbalanserare.

Viktigt!

För att garantera affärskontinuitet vid regionala avbrott måste du säkerställa geografisk redundans för både klientdelskomponenter och databaser.

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 Server-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 Database:

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

Begränsningar

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

• Redundansgrupper kan inte skapas mellan två servrar i samma Azure-region.
• Redundansgrupper stöder geo-replikering av alla databaser i gruppen till endast en sekundär logisk server i en annan region.
• Det går inte att byta namn på redundansgrupper. Du måste ta bort gruppen och återskapa den med ett annat namn.
• Databasbyte stöds inte för databaser i en redundansgrupp. Du måste tillfälligt ta bort redundansgruppen för att kunna byta namn på en databas eller ta bort databasen från redundansgruppen.
• Replikeringen stoppas inte om du tar bort en redundansgrupp för en enskild eller en grupperad databas, och inte heller tas den replikerade databasen bort. Du måste stoppa geo-replikering manuellt och ta bort databasen från den sekundära servern om du vill lägga till en enkel databas eller en pooldatabas tillbaka till en redundansgrupp när den har tagits bort. Om du inte gör något av detta kan det leda till The operation cannot be performed due to multiple errors ett fel som liknar när du försöker lägga till databasen i redundansgruppen.
• Namn på redundansgrupper omfattas av namngivningsbegränsningar.

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-AzSqlDatabaseFailoverGroup	Det här kommandot skapar en redundansgrupp och registrerar den på både primära och sekundära servrar
Remove-AzSqlDatabaseFailoverGroup	Tar bort en redundansgrupp från servern
Get-AzSqlDatabaseFailoverGroup	Hämtar konfigurationen för en redundansgrupp
Set-AzSqlDatabaseFailoverGroup	Ändrar konfigurationen av en redundansgrupp
Switch-AzSqlDatabaseFailoverGroup	Utlöser redundansväxling av en redundansgrupp till den sekundära servern
Add-AzSqlDatabaseToFailoverGroup	Lägger till en eller flera databaser i en redundansgrupp

Kommentar

Det går att distribuera redundansgruppen mellan prenumerationer med hjälp av parametern -PartnerSubscriptionId i Azure Powershell som börjar med Az.SQL 3.11.0. Mer information finns i följande exempel.

Azure CLI

Kommando	beskrivning
az sql failover-group create	Det här kommandot skapar en redundansgrupp och registrerar den på både primära och sekundära servrar
az sql failover-group delete	Tar bort en redundansgrupp från servern
az sql failover-group show	Hämtar en konfiguration av redundanskluster
az sql failover-group update	Ändrar en redundansgrupps konfiguration och/eller lägger till en eller flera databaser i en redundansgrupp
az sql 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 en redundansgrupp
Ta bort redundansgrupp	Tar bort en redundansgrupp från servern
Redundansväxling (planerad)	Utlöser redundans från den aktuella primära servern till den sekundära servern med fullständig datasynkronisering.
Framtvinga redundans tillåt dataförlust	Utlöser redundans från den aktuella primära servern till den sekundära servern 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 efter server	Visar en lista över redundansgrupper på en server.
Uppdatera redundansgrupp	Uppdateringar konfigurationen för en redundansgrupp.

Nästa steg

En översikt över alternativ för hög tillgänglighet i Azure SQL Database finns i geo-replikering och redundansgrupper.