Översikt över redundansgrupper och metodtips (Azure SQL Database)

Gäller för:Azure SQL Database

Med funktionen redundansgrupper kan du hantera replikering och redundans för vissa eller alla databaser på en logisk server till en logisk server i en annan region. Den här artikeln innehåller en översikt över funktionen för redundansgrupper med metodtips och rekommendationer för att använda den med Azure SQL Database.

Om du vill komma igång med funktionen läser du Konfigurera redundansgrupp.

Om du vill veta mer om haveriberedskap för Azure SQL Database kan du titta på den här videon:

Översikt

Med funktionen redundansgrupper kan du hantera replikering och redundans för databaser till en annan Azure-region. Du kan välja alla eller en delmängd av användardatabaser på en logisk server som ska replikeras till en annan logisk server. Det är en deklarativ abstraktion ovanpå den aktiva geo-replikeringsfunktionen , utformad för att förenkla distributionen och hanteringen av geo-replikerade databaser i stor skala.

Information om RPO och RTO för geo-redundans finns i Översikt över affärskontinuitet.

Omdirigering av slutpunkt

Redundansgrupper tillhandahåller skrivskyddade och skrivskyddade lyssnarens slutpunkter som förblir oförändrade under geo-redundansväxlingar. Du behöver inte ändra anslutningssträng för ditt program efter en geo-redundans eftersom anslutningar automatiskt dirigeras till den aktuella primära. En geo-redundansväxlar alla sekundära databaser i gruppen till den primära rollen. När geo-redundans har slutförts uppdateras DNS-posten automatiskt för att omdirigera slutpunkterna till den nya regionen.

Avlasta skrivskyddade arbetsbelastningar

Om du vill minska trafiken till dina primära databaser kan du också använda de sekundära databaserna i en redundansgrupp för att avlasta skrivskyddade arbetsbelastningar. Använd den skrivskyddade lyssnaren för att dirigera skrivskyddad trafik till en läsbar sekundär databas.

Återställa ett program

För att uppnå fullständig affärskontinuitet är det bara en del av lösningen att lägga till regional databasredundans. Återställning av ett program (tjänst) från slutpunkt till slutpunkt efter ett oåterkalleligt fel kräver återställning av alla komponenter som utgör tjänsten och alla beroende tjänster. Exempel på dessa komponenter är klientprogramvaran (till exempel en webbläsare med ett anpassat JavaScript), webbklientdelar, lagring och DNS. Det är viktigt att alla komponenter är motståndskraftiga mot samma fel och blir tillgängliga inom programmets mål för återställningstid (RTO). Därför måste du identifiera alla beroende tjänster och förstå de garantier och funktioner som de tillhandahåller. Sedan måste du vidta lämpliga åtgärder för att säkerställa att tjänsten fungerar under redundansväxlingen av de tjänster som den är beroende av.

Redundansprincip

Redundansgrupper stöder två redundansprinciper:

• Kundhanterad (rekommenderas) – Kunder kan utföra en redundansväxling av en grupp när de märker ett oväntat avbrott som påverkar en eller flera databaser i redundansgruppen. När du använder kommandoradsverktyg som PowerShell, Azure CLI eller Rest API är manualvärdet för redundansprincipen för kundhanterade .
• Microsoft hanterad – I händelse av ett omfattande avbrott som påverkar en primär region initierar Microsoft redundans av alla berörda redundansgrupper som har sin redundansprincip konfigurerad att vara Microsoft-hanterad. Microsofts hanterade redundansväxling initieras inte för enskilda redundansgrupper eller en delmängd av redundansgrupper i en region. När du använder kommandoradsverktyg som PowerShell, Azure CLI eller Rest API är automaticvärdet för redundansprincipen för Microsoft-hanterad .

Varje redundansprincip har en unik uppsättning användningsfall och motsvarande förväntningar på redundansomfånget och dataförlusten, som följande tabell sammanfattar:

Kundhanterad

I sällsynta fall räcker inte den inbyggda tillgängligheten eller hög tillgänglighet för att minska ett avbrott, och dina databaser i en redundansgrupp kan vara otillgängliga under en tid som inte är acceptabel för serviceavtalet (SLA) för program som använder databaserna. Databaser kan inte vara tillgängliga på grund av ett lokaliserat problem som påverkar bara några få databaser, eller på datacenter-, tillgänglighetszon- eller regionnivå. I något av dessa fall kan du initiera en tvingad redundansväxling för att återställa affärskontinuiteten.

Att ställa in redundanspolicyn på kundhanterad rekommenderas starkt, eftersom du får kontroll över när du ska initiera en redundansväxling och återställa affärskontinuitet. Du kan initiera en redundansväxling när du märker ett oväntat avbrott som påverkar en eller flera databaser i redundansgruppen.

Hanterad av Microsoft

Med en Microsoft-hanterad redundansprincip delegeras ansvaret för haveriberedskap till Azure SQL-tjänsten. För att Azure SQL-tjänsten ska kunna initiera en tvingad redundansväxling måste följande villkor uppfyllas:

• Avbrott på datacenter-, tillgänglighetszon- eller regionnivå som orsakas av en naturkatastrof, konfigurationsändringar, programvarubuggar eller maskinvarukomponentfel och många databaser i regionen påverkas.
• Respitperioden har upphört att gälla. Eftersom verifieringen av omfattningen av och mildrandet beror på mänskliga åtgärder, kan respitperioden inte anges under en timme.

När dessa villkor uppfylls initierar Azure SQL-tjänsten framtvingade redundansväxlingar för alla redundansgrupper i regionen som har redundansprincipen inställd på Microsoft hanterad.

Ange redundansprincipen till Microsoft hanterad endast när:

• Du vill delegera ansvaret för haveriberedskap till Azure SQL-tjänsten.
• Programmet är tolerant mot att databasen inte är tillgänglig i minst en timme eller mer.
• Det är acceptabelt att utlösa framtvingade redundansväxlingar en tid efter att respitperioden upphör att gälla eftersom den faktiska tiden för den framtvingade redundansväxlingen kan variera avsevärt.
• Det är acceptabelt att alla databaser i redundansgruppen redundansväxlar, oavsett zonredundanskonfiguration eller tillgänglighetsstatus. Även om databaser som konfigurerats för zonredundans är motståndskraftiga mot zonfel och kanske inte påverkas av ett avbrott, kommer de fortfarande att redundansväxlas om de ingår i en redundansgrupp med en Microsoft-hanterad redundansprincip.
• Det är acceptabelt att ha framtvingade redundansväxlingar av databaser i redundansgruppen utan att ta hänsyn till programmets beroende av andra Azure-tjänster eller komponenter som används av programmet, vilket kan orsaka prestandaförsämring eller otillgänglighet för programmet.
• Det är acceptabelt att ådra sig en okänd mängd dataförlust eftersom den exakta tiden för tvingad redundans inte kan kontrolleras och ignorerar synkroniseringsstatusen för de sekundära databaserna.
• Alla primära och sekundära databaser i redundansgruppen har samma tjänstnivå, beräkningsnivå (etablerad eller serverlös) och beräkningsstorlek (DTU:er eller virtuella kärnor). Om servicenivåmålet (SLO) för alla databaser i en redundansgrupp inte matchar uppdateras redundanspolicyn så småningom från Microsoft Managed to Customer Managed by Azure SQL Service.

När en redundansväxling utlöses av Microsoft läggs en post för åtgärdsnamnet Redundans för Azure SQL-redundans till i Azure Monitor-aktivitetsloggen. Posten innehåller namnet på redundansgruppen under Resurs, och Händelsen som initierades av visar ett enda bindestreck (-) som anger att redundansväxlingen initierades av Microsoft. Den här informationen finns också på sidan Aktivitetslogg för den nya primära servern eller instansen i Azure-portalen.

Terminologi och funktioner

• Redundansgrupp (FOG)

  En redundansgrupp är en namngiven grupp med databaser som hanteras av en enda logisk server i Azure som kan redundansväxla som en enhet till en annan Azure-region om alla eller vissa primära databaser blir otillgängliga på grund av ett avbrott i den primära regionen.

  Viktigt!

  Namnet på redundansgruppen måste vara globalt unikt inom domänen .database.windows.net.

• Servrar

  Vissa eller alla användardatabaser på en logisk server kan placeras i en redundansgrupp. Dessutom stöder en server flera redundansgrupper på en enskild server.

• Primär kontakt

  Den logiska server som är värd för de primära databaserna i redundansgruppen.

• Sekundära

  Den logiska server som är värd för de sekundära databaserna i redundansgruppen. Den sekundära kan inte finnas i samma Azure-region som den primära.

• Redundansväxling (ingen dataförlust)

  Redundans utför fullständig datasynkronisering mellan primära och sekundära databaser innan den sekundära växlar till den primära rollen. Detta garanterar ingen dataförlust. Redundans är bara möjligt när den primära är tillgänglig. Redundans används i följande scenarier:

  • Utföra haveriberedskapstest (DR) i produktion när dataförlust inte är acceptabelt
  • Flytta arbetsbelastningen till en annan region
  • Returnera arbetsbelastningen till den primära regionen efter att avbrottet har åtgärdats (återställning efter fel)

• Tvingad redundansväxling (potentiell dataförlust)

  Tvingad redundans växlar omedelbart den sekundära till den primära rollen utan att vänta på att de senaste ändringarna ska spridas från den primära. Den här åtgärden kan leda till potentiell dataförlust. Tvingad redundans används som en återställningsmetod vid avbrott när den primära inte är tillgänglig. När avbrotten har åtgärdats återansluter den gamla primära automatiskt och blir en ny sekundär. En redundansväxling kan köras för återställning efter fel, vilket returnerar replikerna till deras ursprungliga primära och sekundära roller.

• Respitperiod med dataförlust

  Eftersom data replikeras till den sekundära med asynkron replikering kan tvingad redundansväxling av grupper med Microsofts hanterade redundansprinciper leda till dataförlust. Du kan anpassa redundanspolicyn så att den återspeglar programmets tolerans mot dataförlust. Genom att GracePeriodWithDataLossHourskonfigurera kan du styra hur länge Azure SQL-tjänsten väntar innan du påbörjar en tvingad redundansväxling, vilket kan leda till dataförlust.

• Lägga till enskilda databaser i redundansgruppen

  Du kan placera flera enskilda databaser på samma logiska server i samma redundansgrupp. Om du lägger till en enskild databas i redundansgruppen skapas automatiskt en sekundär databas med samma utgåva och beräkningsstorlek på den sekundära server som du angav när redundansgruppen skapades. Om du lägger till en databas som redan har en sekundär databas på den sekundära servern ärvs den geo-replikeringslänken av gruppen. När du lägger till en databas som redan har en sekundär databas på en server som inte ingår i redundansgruppen skapas en ny sekundär databas på den sekundära servern.

  Viktigt!

  • Kontrollera att den sekundära logiska servern inte har en databas med samma namn om den inte är en befintlig sekundär databas.
  • Om en databas innehåller minnesinterna OLTP-objekt måste den primära databasen och den sekundära geo-replikdatabasen ha matchande tjänstnivåer, eftersom minnesinterna OLTP-objekt finns i minnet. En lägre tjänstnivå på geo-replikdatabasen kan leda till problem med minnesbrist. Om detta inträffar kan geo-repliken misslyckas med att återställa databasen, vilket orsakar otillgänglighet för den sekundära databasen tillsammans med minnesinterna OLTP-objekt på den geo-sekundära. Detta kan i sin tur också leda till att redundansväxlingar misslyckas. Undvik detta genom att se till att tjänstnivån för den geo-sekundära databasen matchar den primära databasens. Uppgraderingar på tjänstnivå kan vara datastorleksåtgärder och kan ta ett tag att slutföra.

• Lägga till databaser i elastisk pool till redundansgrupp

  Du kan placera alla eller flera databaser i en elastisk pool i samma redundansgrupp. Om den primära databasen finns i en elastisk pool skapas den sekundära automatiskt i den elastiska poolen med samma namn (sekundär pool). Du måste se till att den sekundära servern innehåller en elastisk pool med samma exakta namn och tillräckligt med ledig kapacitet som värd för de sekundära databaser som ska skapas av redundansgruppen. Om du lägger till en databas i poolen som redan har en sekundär databas i den sekundära poolen ärvs den geo-replikeringslänken av gruppen. När du lägger till en databas som redan har en sekundär databas på en server som inte ingår i redundansgruppen skapas en ny sekundär databas i den sekundära poolen.

• Läs/skriv-lyssnare för redundansgrupp

  En DNS CNAME-post som pekar på den aktuella primära posten. Den skapas automatiskt när redundansgruppen skapas och gör att läs-och skriv-arbetsbelastningen transparent kan återansluta till den primära när den primära ändras efter redundansväxlingen. När redundansgruppen skapas på en server, skapas DNS CNAME-posten för lyssnarens URL som <fog-name>.database.windows.net. Efter redundans uppdateras DNS-posten automatiskt för att omdirigera lyssnaren till den nya primära posten.

• Skrivskyddad lyssnare för redundansgrupp

  En DNS CNAME-post som pekar på den aktuella sekundära posten. Den skapas automatiskt när redundansgruppen skapas och tillåter att den skrivskyddade SQL-arbetsbelastningen transparent ansluter till den sekundära när den sekundära ändras efter redundansväxlingen. När redundansgruppen skapas på en server, skapas DNS CNAME-posten för lyssnarens URL som <fog-name>.secondary.database.windows.net. Som standard inaktiveras redundansväxling av den skrivskyddade lyssnaren eftersom det säkerställer att prestanda för den primära inte påverkas när den sekundära är offline. Men det innebär också att skrivskyddade sessioner inte kan ansluta förrän den sekundära har återställts. Om du inte kan tolerera stilleståndstid för skrivskyddade sessioner och kan använda den primära för både skrivskyddad och skrivskyddad trafik på bekostnad av den potentiella prestandaförsämringen av den primära, kan du aktivera redundans för den skrivskyddade lyssnaren AllowReadOnlyFailoverToPrimary genom att konfigurera egenskapen. I så fall omdirigeras den skrivskyddade trafiken automatiskt till den primära om den sekundära inte är tillgänglig.

  Kommentar

  Egenskapen AllowReadOnlyFailoverToPrimary har endast effekt om Microsofts hanterade redundansprincip är aktiverad och en tvingad redundans har utlösts. I så fall, om egenskapen är inställd på True, kommer den nya primären att hantera både skrivskyddade och skrivskyddade sessioner.

• Flera redundansgrupper

  Du kan konfigurera flera redundansgrupper för samma par servrar för att styra omfånget för geo-redundans. Varje grupp redundansväxlar oberoende av varandra. Om ditt klient-per-databas-program distribueras i flera regioner och använder elastiska pooler kan du använda den här funktionen för att blanda primära och sekundära databaser i varje pool. På så sätt kanske du kan minska effekten av ett avbrott till endast vissa klientdatabaser.

Arkitektur för redundanskluster

En redundansgrupp i Azure SQL Database kan innehålla en eller flera databaser, som vanligtvis används av samma program. En redundansgrupp måste konfigureras på den primära servern, som ansluter den till den sekundära servern i en annan Azure-region. Redundansgruppen kan innehålla alla eller vissa databaser på den primära servern. Följande diagram illustrerar en typisk konfiguration av ett geo-redundant molnprogram med flera databaser i en redundansgrupp:

När du utformar en tjänst med affärskontinuitet i åtanke följer du de allmänna riktlinjer och metodtips som beskrivs i den här artikeln. När du konfigurerar en redundansgrupp kontrollerar du att autentisering och nätverksåtkomst på den sekundära är konfigurerade för att fungera korrekt efter geo-redundans, när den geo-sekundära blir den nya primära. Mer information finns i SQL Database-säkerhet efter haveriberedskap. Mer information finns i Designa molnlösningar för haveriberedskap.

Använda länkade regioner

När du skapar redundansgruppen mellan den primära och sekundära servern använder du parkopplade regioner eftersom redundansgrupper i parkopplade regioner har bättre prestanda jämfört med obetalda regioner.

Med hjälp av säkra distributionsmetoder uppdaterar Azure SQL Database vanligtvis inte kopplade regioner samtidigt. Det går dock inte att förutsäga vilken region som ska uppgraderas först, så distributionsordningen är inte garanterad. Ibland uppgraderas den primära servern först, och ibland uppgraderas den till en andra.

Om du har geo-replikering eller redundansgrupper konfigurerade för databaser som inte överensstämmer med azure-regionparkopplingen använder du olika underhållsfönsterscheman för dina primära och sekundära databaser. Du kan till exempel välja veckodagunderhållsfönster för den sekundära databasen och helgunderhållsfönstret för din primära databas.

Inledande seeding

När du lägger till databaser eller elastiska pooler i en redundansgrupp finns det en inledande seeding-fas innan datareplikeringen startar. Den inledande seeding-fasen är den längsta och dyraste åtgärden. När den första seedingen är klar synkroniseras data och sedan replikeras endast efterföljande dataändringar. Den tid det tar för den första seedingen att slutföras beror på storleken på dina data, antalet replikerade databaser, belastningen på de primära databaserna och hastigheten på nätverkslänken mellan den primära och sekundära databasen. Under normala omständigheter är den möjliga seedinghastigheten upp till 500 GB i timmen för SQL Database. Seeding utförs för alla databaser parallellt.

Använda flera redundansgrupper för att redundansväsna flera databaser

En eller flera redundansgrupper kan skapas mellan två servrar i olika regioner (primära och sekundära servrar). Varje grupp kan innehålla en eller flera databaser som återställs som en enhet om alla eller vissa primära databaser blir otillgängliga på grund av ett avbrott i den primära regionen. När du skapar en redundansgrupp skapas geo-sekundära databaser med samma tjänstmål som det primära. Om du lägger till en befintlig geo-replikeringsrelation till en redundansgrupp kontrollerar du att den geo-sekundära är konfigurerad med samma tjänstnivå och beräkningsstorlek som den primära.

Använd läs-och-skriv-lyssnaren (primär)

För skrivbara arbetsbelastningar använder du <fog-name>.database.windows.net som servernamn i anslutningssträngen. Anslut ions dirigeras automatiskt till den primära. Det här namnet ändras inte efter redundansväxlingen. Observera att redundansväxlingen innebär att DNS-posten uppdateras så att klientanslutningarna omdirigeras till den nya primära posten först efter att klientens DNS-cache har uppdaterats. Time to live (TTL) för den primära och sekundära lyssnarens DNS-post är 30 sekunder.

Använd den skrivskyddade lyssnaren (sekundär)

Om du har logiskt isolerade skrivskyddade arbetsbelastningar som är toleranta mot datafördröjning kan du köra dem på den geo-sekundära. För skrivskyddade sessioner använder du <fog-name>.secondary.database.windows.net som servernamn i anslutningssträngen. Anslut ions dirigeras automatiskt till den geo-sekundära. Vi rekommenderar också att du anger läs avsikt i anslutningssträng med hjälp ApplicationIntent=ReadOnlyav .

I tjänstnivåerna Premium, Affärskritisk och Hyperskala stöder SQL Database användning av skrivskyddade repliker för att avlasta skrivskyddade frågearbetsbelastningar med hjälp av parametern ApplicationIntent=ReadOnly i anslutningssträng. När du har konfigurerat en geo-sekundär kan du använda den här funktionen för att ansluta till antingen en skrivskyddad replik på den primära platsen eller på den geo-sekundära platsen:

Om du vill ansluta till en skrivskyddad replik på den sekundära platsen använder du ApplicationIntent=ReadOnly och <fog-name>.secondary.database.windows.net.

Potentiell prestandaförsämring efter redundansväxling

Ett typiskt Azure-program använder flera Azure-tjänster och består av flera komponenter. Redundansväxling av en grupp utlöses baserat på tillståndet för enbart Azure SQL Database. Andra Azure-tjänster i den primära regionen kanske inte påverkas av avbrotten och deras komponenter kan fortfarande vara tillgängliga i den regionen. När de primära databaserna växlar till den sekundära regionen (DR) kan svarstiden mellan beroende komponenter öka. För att undvika effekten av högre svarstid på programmets prestanda kontrollerar du att redundansen för alla programmets komponenter i DR-regionen följer dessa riktlinjer för nätverkssäkerhet och samordnar georedundans för relevanta programkomponenter tillsammans med databasen.

Potentiell dataförlust efter tvingad redundans

Om ett avbrott inträffar i den primära regionen kanske de senaste transaktionerna inte har replikerats till den geo-sekundära och det kan uppstå dataförlust om en tvingad redundans utförs.

Återställning efter fel

När redundansgrupper konfigureras med en Microsoft-hanterad redundansprincip initieras tvingad redundans till den geo-sekundära servern under ett katastrofscenario enligt den definierade respitperioden. Återställning efter fel till den gamla primära måste initieras manuellt.

Behörigheter och begränsningar

I guiden konfigurera redundansgrupp finns en lista över behörigheter och begränsningar.

Hantera redundansgrupper programmatiskt

Redundansgrupper kan även hanteras programmatiskt med hjälp av Azure PowerShell, Azure CLI och REST API. Mer information finns i Konfigurera redundansgrupp.

Relaterat innehåll

• Exempelskript finns i:
  • Använda PowerShell för att konfigurera aktiv geo-replikering för Azure SQL Database
  • Använda PowerShell för att konfigurera aktiv geo-replikering för en pooldatabas i Azure SQL Database
  • Använda PowerShell för att lägga till en Azure SQL Database i en redundansgrupp
• En översikt och scenarier för affärskontinuitet finns i Översikt över affärskontinuitet
• Mer information om automatiserade säkerhetskopieringar i Azure SQL Database finns i Automatiserade säkerhetskopieringar av SQL Database.
• Mer information om hur du använder automatiserade säkerhetskopior för återställning finns i Återställa en databas från de tjänstinitierade säkerhetskopiorna.
• Mer information om autentiseringskrav för en ny primär server och databas finns i SQL Database-säkerhet efter haveriberedskap.