Översikt över & metodtips för automatiska redundansgrupper (Azure SQL Database)

  • Artikel
  • 20 minuter för att läsa

Gäller för: Azure SQL-databas

Med funktionen för automatiska redundansgrupper kan du hantera replikering och redundans för vissa eller alla databaser på en logisk server till en annan region. Den här artikeln fokuserar på att använda funktionen För automatiska redundansgrupper med Azure SQL Database och några metodtips.

Kom igång genom att läsa Konfigurera automatisk redundans. En upplevelse från slutpunkt till slutpunkt finns i självstudien om gruppen Automatisk redundans.

Anteckning

  • Den här artikeln beskriver automatiska redundansgrupper för Azure SQL Database. Mer Azure SQL Managed Instance finns i Automatiska redundansgrupper i Azure SQL Managed Instance.
  • Automatiska redundansgrupper stöder geo-replikering av alla databaser i gruppen till endast en sekundär server i en annan region. Om du behöver skapa flera geo-sekundära repliker för Azure SQL Database (i samma eller olika regioner) för samma primära replik använder du aktiv geo-replikering.

Översikt

Med funktionen för automatiska redundansgrupper kan du hantera replikering och redundans för en grupp databaser på en server eller alla användardatabaser i en hanterad instans till en annan Azure-region. Det är en deklarativ abstraktion ovanpå den aktiva geo-replikeringsfunktionen som är utformad för att förenkla distribution och hantering av geo-replikerade databaser i stor skala.

Automatisk redundans

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 en annan oplanerad händelse som resulterar i fullständig eller partiell förlust av SQL Database eller SQL Managed Instance tillgänglighet i den primära regionen. Det här är vanligtvis avbrott som inte kan åtgärdas automatiskt av den inbyggda infrastrukturen för hög tillgänglighet. Exempel på geo-redundansutlösare är naturkatastrofer eller incidenter som orsakas av att en klientorganisation eller kontrollring ligger nere på grund av en os-kernelminnesläcka på beräkningsnoder. Mer information finns i Azure SQL hög tillgänglighet.

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.

Omdirigering av slutpunkt

Automatiska redundansgrupper har skrivbara och skrivskyddade lyssnarslutpunkter som förblir oförändrade under georedundans. Det innebär att du inte behöver ändra anslutningssträngen för ditt program efter en geo-redundans eftersom anslutningar automatiskt dirigeras till den aktuella primära. Oavsett om du använder manuell eller automatisk redundansaktivering växlar en geo-redundansväxling alla sekundära databaser i gruppen till den primära rollen. När geo-redundansväxlingen har slutförts 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ärskontinuitet.

Å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 eventuella 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.

Terminologi och funktioner

  • Redundansgrupp (FOG)

    En redundansgrupp är en namngiven grupp databaser som hanteras av en enskild server och 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 enda server.

  • Primär kontakt

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

  • Sekundär

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

  • Lägga till enskilda databaser i redundansgruppen

    Du kan placera flera enskilda 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 databas på den sekundära servern.

    Viktigt

    Kontrollera att den sekundära servern inte har en databas med samma namn såvida den inte är en befintlig sekundär databas.

  • Lägga till databaser i elastisk pool till redundanskluster

    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 kapacitet för att vara värd för de sekundära databaser som kommer att 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.

  • Lyssningsfunktion för redundansklustergrupp

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

  • Skrivskyddad lyssnare för redundansgrupper

    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.

  • Flera redundansgrupper

    Du kan konfigurera flera redundansgrupper för samma serverpar 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 kan du kanske minska effekten av ett avbrott för endast vissa klientdatabaser.

  • 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 med hög tillgänglighet, till exempel på grund av påverkans omfattning. Om du vill styra arbetsflödet för geo-redundans från programmet eller manuellt kan du inaktivera principen för automatisk redundans.

    Anteckning

    Eftersom verifiering av avbrottets skala och hur snabbt det kan åtgärdas inbegriper mänskliga åtgärder kan respitperioden inte anges under en timme och den exakta tiden för redundansväxlingen kan variera något från respitperioden som angavs. Den här begränsningen gäller för alla databaser i redundansgruppen oavsett deras datasynkroniseringstillstånd.

  • Skrivskyddad redundansprincip

    Som standard är redundansväxlingen för den skrivskyddade lyssnaren inaktiverad. 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 de skrivskyddade sessionerna inte kan ansluta förrän den sekundära har återställts. Om du inte tolererar 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 för 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 trafiken inte är tillgänglig.

    Anteckning

    Egenskapen AllowReadOnlyFailoverToPrimary har endast effekt om principen för automatisk redundans är aktiverad och en automatisk geo-redundans har utlösts. I så fall, om egenskapen är inställd på True, kommer den nya primära att hantera både skrivskyddade och skrivskyddade sessioner.

  • Planerad redundans

    Planerad 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. Planerad redundans används i följande scenarier:

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

    Anteckning

    Om en databas innehåller minnesinterna OLTP-objekt bör de primära databaserna och de sekundära geo-replikdatabaserna ha matchande tjänstnivåer, eftersom minnesinterna OLTP-objekt alltid är hydratiserade i minnet. En lägre tjänstnivå på måldatabasen för geo-replikering kan leda till minnesbrist. Om detta inträffar kan den berörda geo-sekundära databasrepliken försättas i ett begränsat skrivskyddat läge som kallas minnesinternt OLTP-kontrollpunktsläge . Skrivskyddade tabellfrågor tillåts, men skrivskyddade minnesinterna OLTP-tabellfrågor tillåts inte på den berörda geo-sekundära databasrepliken. Planerad redundans blockeras om alla repliker i den geo-sekundära databasen är i endast kontrollpunktsläge. Oplanerad redundansväxling kan misslyckas på grund av minnesbrist. Undvik detta genom att uppgradera tjänstnivån för den sekundära databasen så att den matchar den primära databasen under den planerade redundansväxlingen, eller genom att granska den. Uppgraderingar på tjänstnivå kan vara datastorleksåtgärder och kan ta en stund att slutföra.

  • Oplanerad redundans

    Oplanerad eller tvingad redundansväxling 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 resultera i dataförlust. Oplanerad redundans används som en återställningsmetod vid avbrott när den primära inte är tillgänglig. När avbrottet har åtgärdats återansluter den gamla primära databasen automatiskt och blir en ny sekundär. En planerad redundansväxling kan köras för att återställas, vilket returnerar replikerna till deras ursprungliga primära och sekundära roller.

  • Manuell redundans

    Du kan initiera en geo-redundans manuellt när som helst oavsett konfiguration av automatisk redundans. Du kan initiera en tvingad (oplanerad) eller vänlig (planerad) redundansväxling. En användarvänlig redundansväxling ä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. Om principen för automatisk redundans inte har konfigurerats under ett avbrott som påverkar den primära, krävs en manuell redundansväxling för att höja upp den sekundära till den primära rollen. När en redundansväxling har slutförts uppdateras DNS-posterna automatiskt för att säkerställa anslutningen till den nya primära.

  • Respitperiod med dataförlust

    Eftersom data replikeras till den sekundära databasen med asynkron replikering kan en automatisk geo-redundans leda till dataförlust. Du kan anpassa principen för automatisk redundans för att återspegla programmets tolerans för dataförlust. Genom att GracePeriodWithDataLossHourskonfigurera kan du styra hur länge systemet väntar innan en tvingad redundansväxling initieras, vilket kan leda till dataförlust.

Arkitektur för redundanskluster

En redundansgrupp i Azure SQL Database kan innehålla en eller flera databaser, som vanligtvis används av samma program. 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-redundansväxling.

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 visar en typisk konfiguration av en georedundant molnapp med flera databaser och en automatisk redundansgrupp.

Diagram som visar en typisk konfiguration av ett geo-redundant molnprogram som använder flera databaser och en grupp för automatisk redundans.

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 ska du se till att autentisering och nätverksåtkomst på den sekundära är konfigurerad 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 om hur du utformar lösningar för haveriberedskap finns i Designa molnlösningar för haveriberedskap med aktiv geo-replikering.

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

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å primära databaser och hastigheten på länken mellan den primära och den sekundära. Under normala omständigheter är den möjliga seedningshastigheten upp till 500 GB i timmen för SQL Database. Seeding utförs parallellt för alla databaser.

Använd flera redundansgrupper för att redundansväxlar 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 läs- och skrivlyssnaren (primär)

För skrivbara 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 redundansväxlingen innebär att uppdatera DNS-posten så att klientanslutningarna omdirigeras till den nya primära först när 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 (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. Anslutningar dirigeras automatiskt till den geo-sekundära. Vi rekommenderar också att du anger läs avsikt i anslutningssträngen 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ängen. 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-replikerade 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. Den automatiska geo-redundansväxlingen för redundansgruppen utlöses baserat på det tillstånd som enbart 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 (DR) kan svarstiden mellan beroende komponenter öka. För att undvika effekten av högre svarstider på programmets prestanda säkerställer du redundansen för alla programmets komponenter i DR-regionen, följer dessa riktlinjer för nätverkssäkerhet och samordnar geo-redundans för relevanta programkomponenter tillsammans med databasen.

Potentiell dataförlust efter redundansväxling

Om det sker ett avbrott i den primära regionen kanske de senaste transaktionerna inte kan replikeras till den geosekundära regionen. Om principen för automatisk redundans har konfigurerats väntar systemet under den period som du angav GracePeriodWithDataLossHours innan en automatisk geo-redundans initieras. Standardvärdet är 1 timme. Då prioriteras databasens tillgänglighet framför eventuella dataförluster. Om du anger GracePeriodWithDataLossHours ett större antal, till exempel 24 timmar, eller inaktiverar automatisk geo-redundans kan du minska sannolikheten för dataförlust på bekostnad av databasens tillgänglighet.

Viktigt

Elastiska pooler med 800 eller färre DTU:er eller med åtta eller färre virtuella kärnor och fler än 250 databaser kan stöta på problem, till exempel längre planerade geo-redundansväxlingar och försämrade prestanda. Det är troligare att dessa problem uppstår för skrivintensiva arbetsbelastningar, när geo-repliker är mycket avgränsade med geografi eller när flera sekundära geo-repliker används för varje databas. Ett symptom på dessa problem är en ökning av fördröjningen för geo-replikering över tid, vilket kan leda till mer omfattande dataförlust vid ett avbrott. Den här fördröjningen kan övervakas med hjälp av sys.dm_geo_replication_link_status. Om dessa problem uppstår kan du skala upp poolen för att få fler DTU:er eller virtuella kärnor, eller minska antalet geo-replikerade databaser i poolen.

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, en 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 virtuellt nätverk

Om du använder Virtual Network tjänstslutpunkter och regler för att begränsa åtkomsten till databasen i SQL Database 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 SQL Database klientsessioner omdirigeras 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 de deltagande servrarna eller instanserna ingår i Virtual Network regler. Följ dessa steg för att stödja manuell redundans:

  1. Etablera redundanta kopior av programmets klientdelskomponenter (webbtjänst, virtuella datorer osv.) i den sekundära regionen.
  2. Konfigurera reglerna för virtuellt nätverk individuellt för den primära och sekundära servern.
  3. Aktivera klientdelsredundans 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 de 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 avbrottet.

Anteckning

Om du använder den skrivskyddade lyssnaren för att belastningsutjämning av en skrivskyddad arbetsbelastning kontrollerar du att 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 affärskontinuitetsplanen 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.
  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.

Ovanstående konfiguration säkerställer att en automatisk geo-redundans inte blockerar anslutningar från klientdelskomponenterna och förutsätter att programmet kan tolerera den längre svarstiden mellan klientdelen och datanivån.

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.

Skala primär databas

Du kan skala upp eller skala 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 skickas på nytt 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.

Anteckning

Om du har skapat en geo-sekundär som en del av konfigurationen av redundansklustergruppen 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 tvingad redundansväxling när den tidigare geo-primära är otillgänglig på grund av avbrott. Vi är medvetna om denna begränsning och kommer att åtgärda den snart.

Förhindra förlust av kritiska data

På grund av långa svarstider 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 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 ha genomfört transaktionen. 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. Den 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.

Anteckning

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.

Återställning efter fel

När grupper för automatisk redundans konfigureras med en princip för automatisk redundans initieras redundans till geo-sekundär server under ett katastrofscenario enligt den definierade respitperioden. Återställning efter fel till den gamla primära måste initieras manuellt.

Behörigheter

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

Skrivbehörighet för Azure RBAC krävs för att skapa och hantera redundansgrupper. Rollen SQL Server deltagare har alla nödvändiga behörigheter för att hantera redundansgrupper.

För specifika behörighetsomfång kan du läsa om hur du konfigurerar grupper för automatisk redundans i Azure SQL Database.

Begränsningar

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

  • Redundansgrupper kan inte skapas mellan två servrar i samma Azure-region.
  • Det går inte att byta namn på redundansgrupper. Du måste ta bort gruppen och återskapa den med ett annat namn.
  • Namnbyte på databaser 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.

Hantera redundansgrupper programmatiskt

Som tidigare nämnts kan grupper för automatisk redundans också hanteras programmatiskt med hjälp av Azure PowerShell, Azure CLI och REST API. Följande tabeller beskriver den uppsättning kommandon som är tillgängliga. Aktiv geo-replikering innehåller en uppsättning Azure Resource Manager API:er för hantering, inklusive rest-API:et Azure SQL Database 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 redundans för en redundansgrupp till den sekundära servern
Add-AzSqlDatabaseToFailoverGroup Lägger till en eller flera databaser i en redundansgrupp

Nästa steg