Dela via


Konfigurera en redundansgrupp för Azure SQL Database

Gäller för:Azure SQL Database

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

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.

    Open server for single db

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

    Add new failover group

  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.

    Add SQL Database to failover group

Testa planerad redundans

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

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.

    Open server for single db

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

    Screenshot shows Failover groups where you can select a failover group for your SQL Server.

  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.

    Fail over your failover group containing your database

  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.

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.

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.

    Open server for elastic pool

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

    Add new failover group

  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.

    Add elastic pool to failover group

  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.

Testa planerad redundans

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

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.

    Screenshot of select server for elastic pool in the Azure portal.

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

    Screenshot shows Failover groups where you can select a failover group for your SQL Server.

  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.

    Fail over your failover group containing your database

  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.

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.

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:

Failover group connection string

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).

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.

Nästa steg

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