Använd automatiska redundansgrupper för att aktivera transparent och koordinerad geo-redundans för flera databaser

GÄLLER FÖR: Azure SQL Database Azure SQL Managed Instance

Med funktionen för automatiska redundansgrupper kan du hantera replikering och redundansväxling för en grupp databaser på en server eller alla databaser i en hanterad instans till en annan region. Det är en deklarativ abstraktion ovanpå den befintliga aktiva funktionen för geo-replikering som utformats för att förenkla distribution och hantering av geo-replikerade databaser i stor skala. Du kan initiera en geo-redundans manuellt eller delegera den till Azure-tjänsten baserat på en användardefinierad princip. Med det senare alternativet kan du automatiskt återställa flera relaterade databaser i en sekundär region efter ett oåterkalleligt fel eller andra oplanerade händelser som resulterar i fullständig eller partiell förlust av tillgängligheten för SQL Database eller SQL Managed Instance i den primära regionen. En redundansgrupp kan innehålla en eller flera databaser, som vanligtvis används av samma program. Dessutom kan du använda de läsbara sekundära databaserna för att avlasta skrivskyddade frågearbetsbelastningar.

När du använder automatiska redundansgrupper med en princip för automatisk redundans, resulterar ett avbrott som påverkar en eller flera av databaserna i gruppen i en automatisk geo-redundans. Det här är vanligtvis avbrott som inte kan åtgärdas automatiskt av den inbyggda infrastrukturen för hög tillgänglighet. Exempel på utlösare för geo-redundans är en incident som orsakas av att en SQL Database-klientring eller en kontrollring är ur drift på grund av en OS-kernelminnesläcka på beräkningsnoder eller en incident som orsakas av att en eller flera klientringar ligger nere på grund av att en felaktig nätverkskabel av misstag avbröts under rutinmässig inaktivering av maskinvara. Mer information finns i SQL Database hög tillgänglighet.

Dessutom tillhandahåller automatiska redundansgrupper skrivskyddade och skrivskyddade lyssnarslutpunkter som förblir oförändrade under geo-redundans. Oavsett om du använder manuell eller automatisk redundansaktivering växlar en geo-redundans alla sekundära databaser i gruppen till den primära rollen. När geo-redundansen är klar uppdateras DNS-posten automatiskt för att omdirigera slutpunkterna till den nya regionen. Information om RPO och RTO för geo-redundans finns i Översikt över affärskontinuhet.

När du använder automatiska redundansgrupper med en princip för automatisk redundans, resulterar ett avbrott som påverkar databaser på en server eller hanterad instans i en automatisk geo-redundans.

Du kan hantera automatisk redundansgrupp med hjälp av:

• Azure Portal
• Azure CLI: Redundansgrupp
• PowerShell: Redundansgrupp
• REST API: Redundansgrupp

När du konfigurerar en redundansgrupp, se till att autentisering och nätverksåtkomst på den sekundära har konfigurerats 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.

För att uppnå fullständig affärskontinuhet är det bara en del av lösningen att lägga till regional databasredundans. Återställning av ett program (tjänst) från slutet till slut 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), klientdelar för webben, lagring och DNS. Det är viktigt att alla komponenter är motståndskraftiga mot samma fel och blir tillgängliga inom RTO-målet (RTO) för ditt program. 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 redundansen av de tjänster som den är beroende av. Mer information om hur du utformar lösningar för haveriberedskap finns i Utforma molnlösningar för haveriberedskap med aktiv geo-replikering.

Terminologi och funktioner för redundansgrupp

• Redundansgrupp (DIMM)

  En redundansgrupp är en namngiven grupp med databaser som hanteras av en enskild server eller inom en hanterad instans som kan redundans växlas över som en enhet till en annan region om alla eller vissa primära databaser blir otillgängliga på grund av ett avbrott i den primära regionen. När den skapas för SQL Managed Instance innehåller en redundansgrupp alla användardatabaser i instansen och därför kan endast en redundansgrupp konfigureras på en instans.

  Viktigt

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

• Servrar

  Vissa eller alla användardatabaser på en logisk server kan placeras i en redundansgrupp. Dessutom har en server stöd för flera redundansgrupper på en enda server.

• Primär kontakt

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

• Sekundär

  Den server eller hanterade instans som är värd för de sekundära databaserna i redundansgruppen. Den sekundära kan inte finnas i samma region som den primära.

• Lägga till enkla databaser i redundansgruppen

  Du kan placera flera enkla databaser på samma server i samma redundansgrupp. Om du lägger till en enkel databas i redundansgruppen skapas automatiskt en sekundär databas med samma utgåva och beräkningsstorlek på den sekundära servern. Du angav den servern 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 på den sekundära servern.

  Viktigt

  Kontrollera att den sekundära servern inte har en databas med samma namn såvida det inte är en befintlig sekundär databas. I redundansgrupper för SQL Managed Instance replikeras alla användardatabaser. Du kan inte välja en delmängd av användardatabaserna för replikering i redundansgruppen.

• Lägga till databaser i en elastisk pool i en 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 ledigt utrymme för att vara värd för de sekundära databaser som 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 i den sekundära poolen.

• Inledande seeding

  När du lägger till databaser, elastiska pooler eller hanterade instanser i en redundansgrupp finns det en inledande seedingfas innan datareplikeringen startar. Den första seeding-fasen är den längsta och dyraste åtgärden. När den inledande seedningen är klar synkroniseras data och sedan replikeras endast efterföljande dataändringar. Hur lång tid det tar för den första seedningen att slutföras beror på storleken på dina data, antalet replikerade databaser, belastningen på primära databaser och hastigheten på länken mellan den primära och den sekundära. Under normala omständigheter är möjlig seeding-hastighet upp till 500 GB per timme för SQL Database och upp till 360 GB per timme för SQL Managed Instance. Seeding utförs parallellt för alla databaser.

  För SQL Hanterad instans bör du överväga hastigheten för Express Route-länken mellan de två instanserna när du beräknar tiden för den första seeding-fasen. Om hastigheten för länken mellan de två instanserna är långsammare än vad som är nödvändigt, påverkas förmodligen starttiden märkbart. Du kan använda den angivna seeding-hastigheten, antalet databaser, den totala storleken på data och länkhastigheten för att uppskatta hur lång tid den inledande seeding-fasen tar innan datareplikeringen startar. För en enskild databas på 100 GB skulle till exempel den inledande startfasen ta ungefär 1,2 timmar om länken kan push-överför 84 GB per timme och om det inte finns några andra databaser som seedas. Om länken bara kan överföra 10 GB per timme tar seeding av en databas på 100 GB cirka 10 timmar. Om det finns flera databaser som ska replikeras körs seeding parallellt, och i kombination med långsam länkhastighet kan den inledande seeding-fasen ta betydligt längre tid, särskilt om parallell seeding av data från alla databaser överskrider den tillgängliga länkbandbredden. Om nätverksbandbredden mellan två instanser är begränsad och du lägger till flera hanterade instanser i en redundansgrupp bör du överväga att lägga till flera hanterade instanser i redundansgruppen sekventiellt, en i följd. Med en gateway-SKU av lämplig storlek mellan de två hanterade instanserna, och om företagets nätverksbandbredd tillåter det, är det möjligt att uppnå hastigheter så höga som 360 GB i timmen.

• DNS-zon

  Ett unikt ID som genereras automatiskt när en ny SQL hanterad instans skapas. Ett SAN-certifikat (Multi-Domain) för den här instansen etableras för att autentisera klientanslutningarna till alla instanser i samma DNS-zon. De två hanterade instanserna i samma redundansgrupp måste dela DNS-zonen.

  Anteckning

  Ett DNS-zon-ID krävs inte eller används inte för redundansgrupper som skapats för SQL Database.

• Lyssnare för skrivskyddade redundansgrupp

  En DNS CNAME-post som pekar på den aktuella primära. Den skapas automatiskt när redundansgruppen skapas och gör att arbetsbelastningen för läsning och skrivning transparent kan återansluta till den primära när den primära ändras efter redundans. När redundansgruppen skapas på en server skapas DNS CNAME-posten för lyssnar-URL:en som <fog-name>.database.windows.net . När redundansgruppen skapas på en SQL-instans, skapas DNS CNAME-posten för lyssnar-URL:en som <fog-name>.<zone_id>.database.windows.net .

• Skrivskyddade lyssnare för redundansgrupp

  En DNS CNAME-post som pekar på den aktuella sekundära. 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 redundans. När redundansgruppen skapas på en server skapas DNS CNAME-posten för lyssnar-URL:en som <fog-name>.secondary.database.windows.net . När redundansgruppen skapas på en SQL-instans, skapas DNS CNAME-posten för lyssnar-URL:en som <fog-name>.secondary.<zone_id>.database.windows.net .

• Princip för automatisk redundans

  Som standard konfigureras en redundansgrupp med en princip för automatisk redundans. Systemet utlöser en geo-redundans när felet har identifierats och respitperioden har gått ut. Systemet måste kontrollera att avbrottet inte kan åtgärdas av den inbyggda infrastrukturen för högtillgänglighet, till exempel på grund av effektens skala. Om du vill styra arbetsflödet för geo-redundans från programmet eller manuellt kan du inaktivera automatisk redundans.

  Anteckning

  Eftersom verifiering av skalan för avbrottet och hur snabbt det kan åtgärdas inbegriper mänskliga åtgärder kan respitperioden inte anges under en timme. Den här begränsningen gäller för alla databaser i redundansgruppen oavsett deras datasynkroniseringstillstånd.

• Skrivskyddade redundansprinciper

  Som standard är redundans för den skrivskyddade lyssnaren inaktiverad. Det säkerställer att den primäras prestanda inte påverkas när den sekundära är offline. Men det innebär också att de skrivskyddade sessionerna inte kan ansluta förrän den sekundära har återställts. Om du inte tolererar stilleståndstid för de skrivskyddade sessionerna och kan använda den primära för både skrivskyddad och skrivskyddad trafik på bekostnad av den primära serverns potentiella prestandaförsämring kan du aktivera redundans för den skrivskyddade lyssnaren genom att konfigurera AllowReadOnlyFailoverToPrimary egenskapen . I så fall omdirigeras den skrivskyddade trafiken automatiskt till den primära om den sekundära inte är tillgänglig.

  Anteckning

  Egenskapen AllowReadOnlyFailoverToPrimary har endast effekt om automatisk redundansprincip har aktiverats och en automatisk geo-redundans har utlösts. I så fall, om egenskapen har angetts till Sant, kommer den nya primära att betjäna både skrivskyddade och skrivskyddade sessioner.

• Planerad redundans

  Planerad redundans utför fullständig datasynkronisering mellan primära och sekundära databaser innan de sekundära växlarna till den primära rollen. Detta garanterar ingen dataförlust. Planerad redundans används i följande scenarier:

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

• Oplanerad redundans

  Oplanerad eller framtvingad 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 dataförlust. Oplanerad redundans används som en återställningsmetod under avbrott när den primära inte är tillgänglig. När avbrottet minimeras återansluter den gamla primära automatiskt och blir en ny sekundär. En planerad redundans kan köras för att växla tillbaka och returnera replikerna till sina ursprungliga primära och sekundära roller.

• Manuell redundans

  Du kan initiera en geo-redundans manuellt när som helst, oavsett konfigurationen för automatisk redundans. Under ett avbrott som påverkar den primära, krävs en manuell redundans för att befordra den sekundära till den primära rollen om den automatiska redundansprincipen inte har konfigurerats. Du kan initiera en framtvingad (oplanerad) eller användarvänlig (planerad) redundans. En användarvänlig redundans är endast möjlig när den gamla primära är tillgänglig och kan användas för att flytta den primära till den sekundära regionen utan dataförlust. När en redundans har slutförts uppdateras DNS-posterna automatiskt för att säkerställa anslutningen till den nya primära.

• Respitperiod med dataförlust

  Eftersom de sekundära databaserna synkroniseras med asynkron replikering kan en automatisk geo-redundans leda till dataförlust. Du kan anpassa principen för automatisk redundans så att den återspeglar programmets tolerans för dataförlust. Genom att konfigurera kan du styra hur länge systemet väntar innan en framtvingad GracePeriodWithDataLossHours redundans initieras, vilket kan leda till dataförlust.

• Flera redundansgrupper

  Du kan konfigurera flera redundansgrupper för samma par servrar för att styra omfånget för geo-redundans. Varje grupp går över oberoende av varandra. Om ditt klientorganisationsbaserade databasprogram 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 kan du kanske minska effekten av ett avbrott till endast vissa klientdatabaser.

  Anteckning

  SQL Managed Instance stöder inte flera redundansgrupper.

Behörigheter

Behörigheter för en redundansgrupp hanteras via rollbaserad åtkomstkontroll i Azure (Azure RBAC). Rollen SQL Server har alla behörigheter som krävs för att hantera redundansgrupper.

Skapa en redundansgrupp

Om du vill skapa en redundansgrupp behöver du Azure RBAC-skrivåtkomst till både de primära och sekundära servrarna och till alla databaser i redundansgruppen. För en SQL Managed Instance behöver du Azure RBAC-skrivåtkomst till både den primära och sekundära SQL Managed Instance, men behörigheter för enskilda databaser är inte relevanta eftersom enskilda SQL Managed Instance-databaser inte kan läggas till eller tas bort från en redundansgrupp.

Uppdatera en redundansgrupp

Om du vill uppdatera en redundansgrupp behöver du Azure RBAC-skrivåtkomst till redundansgruppen och alla databaser på den aktuella primära servern eller hanterade instansen.

Redundans för en redundansgrupp

Om du vill växla över en redundansgrupp behöver du Azure RBAC-skrivåtkomst till redundansgruppen på den nya primära servern eller den hanterade instansen.

Metodtips för redundansgrupp för SQL Database

Den automatiska redundansgruppen måste konfigureras på den primära servern och ansluter den till den sekundära servern i en annan Azure-region. Grupperna kan innehålla alla eller vissa databaser på dessa servrar. Följande diagram illustrerar en typisk konfiguration av ett geo-redundant molnprogram med flera databaser och en automatisk redundansgrupp.

När du utformar en tjänst med affärskontinu kontinuitet i åtanke bör du följa dessa allmänna riktlinjer:

Använd en eller flera redundansgrupper för att hantera redundans för 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 den 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 lyssnaren för läsning och skrivning för att ansluta till den primära

För skrivskyddade arbetsbelastningar använder du <fog-name>.database.windows.net som servernamn i anslutningssträngen. Anslutningar dirigeras automatiskt till den primära. Det här namnet ändras inte efter redundansväxlingen. Observera att redundansen innebär att uppdatera DNS-posten så att klientanslutningar omdirigeras till den nya primära först efter att klientens DNS-cache har uppdaterats. TTL-värdet (Time to Live) för DNS-posten för den primära och sekundära lyssnaren är 30 sekunder.

Använd den skrivskyddade lyssnaren för att ansluta till geo-sekundär

Om du har logiskt isolerade skrivskyddade arbetsbelastningar som är toleranta mot datasvarstid 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. Anslutningar dirigeras automatiskt till den geo-sekundära. Vi rekommenderar också att du anger läs avsikt i anslutningssträngen med hjälp av ApplicationIntent=ReadOnly .

Potentiell prestandaförsämring efter geo-redundans

Ett typiskt Azure-program använder flera Azure-tjänster och består av flera komponenter. Den automatiska geo-redundansen för redundansgruppen utlöses baserat på azure-SQL komponenter. Andra Azure-tjänster i den primära regionen kanske inte påverkas av avbrottet 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 de beroende komponenterna öka. För att undvika effekten av längre svarstider på programmets prestanda bör du kontrollera redundansen för alla programkomponenter i DR-regionen, följa dessa riktlinjer för nätverkssäkerhet och dirigera geo-redundans för relevanta programkomponenter tillsammans med databasen.

Potentiell dataförlust efter geo-redundans

Om ett avbrott inträffar i den primära regionen kanske de senaste transaktionerna inte kan replikeras till den geo-sekundära regionen. Om den automatiska redundansprincipen har konfigurerats väntar systemet under den period som du angav innan en automatisk GracePeriodWithDataLossHours geo-redundans initieras. Standardvärdet är 1 timme. Detta gör databasen mer tillgänglig än ingen dataförlust. Genom att ange ett större antal, till exempel 24 timmar, eller inaktivera automatisk geo-redundans kan du minska sannolikheten för dataförlust på bekostnad av GracePeriodWithDataLossHours databasens tillgänglighet.

Ändra den sekundära regionen för en redundansgrupp

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

1. Skapa ytterligare secondaries för varje databas på server A till server C med aktiv geo-replikering. Varje databas på server A har två secondaries, 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 misslyckas inloggningsförsök med hjälp av redundansgruppslutpunkter.
3. Skapa redundansgruppen på nytt 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 en redundansgrupp

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

1. Utför en planerad geo-redundans för att växla den primära servern till B. Server A blir den nya sekundära servern. Redundansen kan resultera i flera minuters driftstopp. Den faktiska tiden beror på storleken på redundansgruppen.
2. Skapa ytterligare secondaries för varje databas på server B till server C med aktiv geo-replikering. Varje databas på server B har två secondaries, 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. Vid det här läget misslyckas inloggningsförsök med hjälp av redundansgruppslutpunkter.
4. Skapa om 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-redundans 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är databaserna på C. Som i steg 1 kan redundansen resultera i flera minuters driftstopp.
7. Ta bort server A. Alla databaser på A tas bort automatiskt.

Metodtips för redundansgrupp för SQL Managed Instance

Den automatiska redundansgruppen måste vara konfigurerad på den primära instansen och ansluter den till den sekundära instansen i en annan Azure-region. Alla användardatabaser i instansen replikeras till den sekundära instansen. Systemdatabaser som master och msdb replikeras inte.

Följande diagram illustrerar en typisk konfiguration av ett geo-redundant molnprogram med hjälp av hanterad instans och automatisk redundansgrupp.

Om ditt program använder SQL-instans som datanivå följer du dessa allmänna riktlinjer när du designar för affärskontinuering:

Skapa den geo-sekundära hanterade instansen

För att säkerställa en oavbruten anslutning till den primära SQL Managed Instance efter redundans, måste både den primära och sekundära instansen finnas i samma DNS-zon. Det garanterar att samma SAN-certifikat (multidomän) kan användas för att autentisera klientanslutningar till någon av de två instanserna i redundansgruppen. När programmet är redo för produktionsdistribution skapar du en sekundär SQL Managed Instance i en annan region och ser till att det delar DNS-zonen med den primära SQL Managed Instance. Du kan göra det genom att ange en valfri parameter när du skapar den. Om du använder PowerShell eller REST API är namnet på den valfria parametern DNSZonePartner . Namnet på motsvarande valfria fält i den Azure Portal är Primär hanterad instans.

Mer information om hur du skapar den sekundära SQL Managed Instance i samma DNS-zon som den primära instansen finns i Skapa en sekundär hanterad instans.

Använda parkopplade regioner

Distribuera båda hanterade instanserna till parkopplade regioner av prestandaskäl. SQL Redundansgrupper för hanterad instans i parkopplade regioner har bättre prestanda jämfört med icke-parkopplade regioner.

Aktivera geo-replikeringstrafik mellan två hanterade instanser

Eftersom varje hanterad instans är isolerad i sitt eget VNet måste tvåriktad trafik mellan dessa virtuella nätverk tillåtas. Se Azure VPN Gateway

Skapa en redundansgrupp mellan hanterade 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 Azure Active Directory klientorganisation. När du använder PowerShell API kan du göra det genom att ange PartnerSubscriptionId parametern för den sekundära SQL Managed Instance. När du REST API kan varje instans-ID som ingår i properties.managedInstancePairs parametern ha ett eget prenumerations-ID.

Hantera geo-redundans till en geo-sekundär instans

Redundansgruppen hanterar geo-redundans för alla databaser på den primära hanterade instansen. När en grupp skapas geo-replikeras varje databas i instansen automatiskt till den geo-sekundära instansen. Du kan inte använda redundansgrupper för att initiera en partiell redundans av en delmängd av databaser.

Använd läs-/skriv-lyssnaren för att ansluta till den primära hanterade instansen

För skrivskyddade arbetsbelastningar använder <fog-name>.zone_id.database.windows.net du som servernamn. Anslutningar dirigeras automatiskt till den primära. Det här namnet ändras inte efter redundansväxlingen. Geo-redundans innebär att uppdatera DNS-posten, så klientanslutningar omdirigeras till den nya primära först när klientens DNS-cache har uppdaterats. Eftersom den sekundära instansen delar DNS-zonen med den primära, kommer klientprogrammet att kunna återansluta till den med samma SAN-certifikat på serversidan.

Använd den skrivskyddade lyssnaren för att ansluta till den geo-sekundära hanterade instansen

Om du har logiskt isolerade skrivskyddade arbetsbelastningar som är toleranta för datasvarstid kan du köra dem på den geo-sekundära. Om du vill ansluta direkt till den geo-sekundära, <fog-name>.secondary.<zone_id>.database.windows.net använder du som servernamn.

Potentiell prestandaförsämring efter redundans till den geo-sekundära hanterade instansen

Ett typiskt Azure-program använder flera Azure-tjänster och består av flera komponenter. Den automatiska geo-redundansen för redundansgruppen utlöses baserat på det tillstånd som Azure SQL-komponenterna. Andra Azure-tjänster i den primära regionen kanske inte påverkas av avbrottet och deras komponenter kan fortfarande vara tillgängliga i den regionen. När de primära databaserna växlar till den sekundära regionen kan svarstiden mellan de beroende komponenterna öka. För att undvika effekten av längre svarstider på programmets prestanda bör du kontrollera redundansen för alla programkomponenter i den sekundära regionen och redundansen över programkomponenterna tillsammans med databasen. Vid konfigurationstiden följer du riktlinjerna för nätverkssäkerhet för att säkerställa anslutningen till databasen i den sekundära regionen.

Potentiell dataförlust efter redundans till den geo-sekundära hanterade instansen

Om ett avbrott inträffar i den primära regionen kanske de senaste transaktionerna inte kan replikeras till den geo-sekundära regionen. Om den automatiska redundansprincipen har konfigurerats utlöses en geo-redundans om det inte finns någon dataförlust, enligt vår vetskap. I annat fall uppskjuts redundansen för den period som du anger med hjälp av GracePeriodWithDataLossHours . Om du har konfigurerat principen för automatisk redundans bör du vara förberedd för dataförlust. I allmänhet prioriterar Azure tillgänglighet under avbrott. Om du anger ett större antal, till exempel 24 timmar, eller inaktiverar automatisk geo-redundans kan du minska risken för dataförlust på bekostnad av GracePeriodWithDataLossHours databasens tillgänglighet.

DNS-uppdateringen av läs-/skriv-lyssnaren sker omedelbart efter att redundansen har initierats. Den här åtgärden leder inte till dataförlust. Processen med att växla databasroller kan dock ta upp till 5 minuter under normala förhållanden. Tills den är klar är vissa databaser i den nya primära instansen fortfarande skrivskyddade. Om en redundans initieras med Hjälp av PowerShell är åtgärden för att växla den primära replikrollen synkron. Om den initieras med hjälp Azure Portal visar användargränssnittet slutförandestatus. Om avsökningsmekanismen initieras med hjälp REST API standard Azure Resource Manager avsökningsmekanismen för att övervaka att den har slutförts.

Ändra den sekundära regionen för den hanterade instansens redundansgrupp

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. Följ dessa steg för att göra övergången:

1. Skapa instans C med samma storlek som A och i samma DNS-zon.
2. Ta bort redundansgruppen mellan instanserna A och B. Nu misslyckas inloggningarna eftersom SQL-aliasen för redundansgruppens lyssnare har tagits bort och gatewayen inte känner igen namnet på redundansgruppen. De sekundära databaserna kopplas bort från primärdatabaserna och blir skrivskyddade databaser.
3. Skapa en redundansgrupp med samma namn mellan instans A och C. Följ instruktionerna i självstudien för redundansgrupp SQL hanterad instans. Det här är en datastorleksåtgärd som slutförs när alla databaser från instans A seedas och synkroniseras.
4. Ta bort instans B om det inte behövs för att undvika onödiga kostnader.

Ändra den primära regionen för redundansgruppen för hanterad instans

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

1. Skapa instans C med samma storlek som B och i samma DNS-zon.
2. Anslut till instans B och växla manuellt över den primära instansen till B. Instans A blir automatiskt den nya sekundära instansen.
3. Ta bort redundansgruppen mellan instanserna A och B. Vid det här läget misslyckas inloggningsförsök med hjälp av redundansgruppslutpunkter. De sekundära databaserna på A kopplas bort från primärdatabaserna och blir skrivskyddade databaser.
4. Skapa en redundansgrupp med samma namn mellan instans A och C. Följ anvisningarna i självstudien om redundansgrupp med hanterad instans. Det här är en datastorleksåtgärd som slutförs när alla databaser från instans A seedas och synkroniseras. Vid det här läget slutar inloggningsförsöken att misslyckas.
5. Ta bort instans A om det inte behövs för att undvika onödiga kostnader.

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

Systemdatabaser replikeras inte till den sekundära instansen i en redundansgrupp. Om du vill aktivera scenarier som är beroende av objekt från systemdatabaserna måste du skapa samma objekt på den sekundära instansen och synkronisera dem med den primära instansen.

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

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

Synkronisera instansegenskaper och kvarhållningsprinciper mellan primär och sekundär instans

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 en princip för långsiktig kvarhållning av säkerhetskopior på den primära instansen måste du även ändra den på den sekundära instansen.

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, till exempel en virtuell dator, webbtjänst osv. Det här kravet medför vissa utmaningar för utformningen av affärskontinuering och användningen av redundansgrupper. Överväg följande alternativ när du implementerar sådan begränsad åtkomst.

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

Om du använder Virtual Network-tjänstslutpunkter och regler för att begränsa åtkomsten till databasen i SQL Database eller SQL Managed Instance 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 dirigeras om till en server i en annan (sekundär) region, misslyckas dessa sessioner om de kommer från en klient utanför den regionen. Därför kan inte principen för automatisk redundans aktiveras om deltagande servrar eller instanser ingår i Virtual Network reglerna. Följ dessa steg om du vill ha stöd för manuell redundans:

1. Etablera redundanta kopior av programmets frontend-komponenter (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 frontend-redundans med hjälp av en Traffic Manager-konfiguration.
4. Initiera manuell geo-redundans när avbrottet identifieras. Det här alternativet är optimerat för program som kräver konsekvent svarstid mellan frontend och datanivån och stöder återställning när antingen frontend, datanivån eller båda påverkas av avbrottet.

Använda redundansgrupper och brandväggsregler

Om din plan för affärskontinu kontinuitet kräver redundans med hjälp av grupper med automatisk redundans kan du begränsa åtkomsten till databasen i SQL Database med hjälp av offentliga IP-brandväggsregler. Följ dessa steg för att stödja automatisk redundans:

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 frontend-komponenter.
4. Skapa en nätverkssäkerhetsgrupp och konfigurera inkommande anslutningar.
5. Se till 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 som tillåter inkommande trafik från den offentliga IP-adress som du skapade 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.

Konfigurationen ovan säkerställer att en automatisk geo-redundans inte blockerar anslutningar från frontend-komponenterna och förutsätter att programmet kan tolerera den längre svarstiden mellan frontend och datanivån.

Aktivera geo-replikering mellan virtuella nätverk med hanterade instanser

När du ställer in en redundansgrupp mellan primära och sekundära SQL Managed Instances i två olika regioner isoleras varje instans med hjälp av ett oberoende virtuellt nätverk. Om du vill tillåta replikeringstrafik mellan dessa virtuella nätverk ser du till att dessa krav är uppfyllda:

• De två instanserna av SQL Managed Instance måste finnas i olika Azure-regioner.

• De två instanserna av SQL Managed Instance måste ha samma tjänstnivå och samma lagringsstorlek.

• Den sekundära instansen av SQL Managed Instance måste vara tom (inga användardatabaser).

• De virtuella nätverk som används av instanserna av SQL Managed Instance måste anslutas via en VPN Gateway eller Express Route. Se till att inga brandväggsregler blockerar portarna 5022 eller 11000–11999 när två virtuella nätverk ansluter via ett lokalt nätverk. Global VNet-peering stöds med den begränsning som beskrivs i meddelandet nedan.

  Viktigt

  2020-09-22-stödför global peering för virtuella nätverk för nyligen skapade virtuella kluster presenterades. Det innebär att global peering för virtuella nätverk stöds för SQL-hanterade instanser som skapats i tomma undernät efter tillkännagivandet, samt för alla efterföljande hanterade instanser som skapats i dessa undernät. För alla andra SQL är peering-stöd för hanterade instanser begränsat till nätverken i samma region på grund av begränsningarna för global peering för virtuella nätverk. Se även relevant avsnitt i artikeln med vanliga frågor och svar om Virtuella Azure-nätverk för mer information. Om du vill kunna använda global peering för virtuella nätverk för SQL-hanterade instanser från virtuella kluster som skapats före tillkännagivandet bör du överväga att konfigurera underhållsfönstret som inte är standard på instanserna eftersom instanserna flyttas till nya virtuella kluster som stöder global peering för virtuella nätverk.

• De två virtuella SQL instanserna kan inte ha överlappande IP-adresser.

• Du måste konfigurera dina nätverkssäkerhetsgrupper (NSG) så att portarna 5022 och intervallet 11000–12000 är öppna för inkommande och utgående anslutningar från den andra hanterade instansens undernät. Det här görs för att tillåta replikeringstrafik mellan instanserna.

  Viktigt

  Felkonfigurerade NSG-säkerhetsregler leder till seeding-åtgärder för databaser som har fastnat.

• Den sekundära SQL managed instance konfigureras med rätt DNS-zon-ID. DNS-zonen är en egenskap för en SQL-instans och underliggande virtuellt kluster, och dess ID ingår i värdnamnets adress. Zon-ID genereras som en slumpmässig sträng när den första SQL Managed Instance skapas i varje VNet och samma ID tilldelas till alla andra instanser i samma undernät. När dns-zonen har tilldelats kan den inte ändras. SQL Hanterade instanser som ingår i samma redundansgrupp måste dela DNS-zonen. Du åstadkommer detta genom att skicka zon-ID:t för den primära instansen som värdet för parametern DnsZonePartner när du skapar den sekundära instansen.

  Anteckning

  En detaljerad självstudiekurs om hur du konfigurerar redundansgrupper med SQL Managed Instance finns i lägga till en SQL hanterad instans till en redundansgrupp.

Skala primär databas

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 skalar du om i omvänd ordning: skala ned den primära först och skala sedan ned 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 problem där den geo-sekundära vid en lägre SKU överbelastas och måste omvärdeeras under en uppgradering 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.

Förhindra förlust av kritiska data

På grund av den höga svarstiden i breda nätverk använder geo-replikering en asynkron replikeringsmekanism. Asynkron replikering gör att det inte går att undvika dataförlust om den primära misslyckas. För att skydda kritiska transaktioner mot dataförlust kan en programutvecklare anropa den sp_wait_for_database_copy_sync lagrade proceduren direkt efter att transaktionen har genomförs. Anrop blockerar anropstråden tills den senast införda transaktionen har överförts och sp_wait_for_database_copy_sync härdats i transaktionsloggen för den sekundära databasen. Den väntar dock inte på att de överförda transaktionerna ska spelas upp igen (göra om) på den sekundära. sp_wait_for_database_copy_sync är begränsad till en specifik geo-replikeringslänk. Alla användare med anslutningsbehörighet till den primära databasen kan anropa den här proceduren.

Redundansgrupper och återställning till tidpunkt

Information om hur du använder återställning till tidpunkt med redundansgrupper finns i Tidpunktsåterställning (PITR).

Begränsningar för redundansgrupper

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

• Redundansgrupper kan inte skapas mellan två servrar eller instanser i samma Azure-region.
• Redundansgrupper kan inte byta namn. Du måste ta bort gruppen och skapa den på nytt med ett annat namn.
• Namnbyte på databas stöds inte för databaser i redundansgruppen. Du måste tillfälligt ta bort redundansgruppen för att kunna byta namn på en databas eller ta bort databasen från redundansgruppen.
• Systemdatabaser replikeras inte till den sekundära instansen i en redundansgrupp. Scenarier som är beroende av objekt från systemdatabaserna kräver därför att objekt skapas manuellt på de sekundära instanserna och även hålls synkroniserade manuellt efter ändringar som görs på den primära instansen. Det enda undantaget är Service Master Key (SMK) för SQL Managed Instance, som replikeras automatiskt till en sekundär instans när en redundansgrupp skapas. Eventuella efterföljande ändringar av SMK på den primära instansen replikeras dock inte till den sekundära instansen.
• Redundansgrupper kan inte skapas mellan instanser om någon av dem finns i en instanspool.

Hantera redundansgrupper programmatiskt

Som vi nämnt tidigare kan automatiska redundansgrupper också hanteras programmatiskt med hjälp av Azure PowerShell, Azure CLI och REST API. Följande tabeller beskriver uppsättningen kommandon som är tillgängliga. Aktiv geo-replikering innehåller en uppsättning Azure Resource Manager API:er för hantering, inklusive cmdletarna Azure SQL Database REST API och Azure PowerShell. Dessa API:er kräver användning av resursgrupper och har stöd för rollbaserad åtkomstkontroll i Azure (Azure RBAC). Mer information om hur du implementerar åtkomstroller finns i Rollbaserad åtkomstkontroll i Azure (Azure RBAC).

Hantera SQL Database geo-redundans

Hantera SQL managed instance geo-failover

Nästa steg

• Detaljerade självstudier finns i
  • Lägga SQL Database till en redundansgrupp
  • Lägga till en elastisk pool till en redundansgrupp
  • Lägga till SQL hanterad instans i en redundansgrupp
• Exempelskript finns i:
  • Använd 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 Azure SQL Database i en redundansgrupp
• En översikt över affärskontinuhet och scenarier finns i Översikt över affärskontinuhet
• Mer information om hur Azure SQL Database säkerhetskopieringar finns i SQL Database automatiska säkerhetskopieringar.
• Mer information om hur du använder automatiska säkerhetskopieringar för återställning finns i Återställa en databas från tjänstinitierade säkerhetskopior.
• Mer information om autentiseringskrav för en ny primär server och databas finns i SQL Database säkerhet efter haveriberedskap.