Översikt över failovergrupper & bästa praxis – Azure SQL Managed Instance

gäller för:Azure SQL Managed Instance

Den här artikeln innehåller en översikt över funktionen för redundansgrupper med metodtips och rekommendationer för användning med Azure SQL Managed Instance. Med funktionen failovergrupper kan du hantera replikering och failover av alla användardatabaser i en SQL-hanterad instans till en annan Azure-region.

Kom igång genom att läsa Konfigurera en redundansgrupp för Azure SQL Managed Instance.

Överblick

Med funktionen redundansgrupper kan du hantera replikering och redundans för användardatabaser från en SQL-hanterad instans till en annan SQL-hanterad instans i en annan Azure-region. Redundansgrupper är utformade för att förenkla distribution och hantering av geo-replikerade databaser i stor skala.

Mer information finns i Hög tillgänglighet för Azure SQL Managed Instance. Information om geo-failover RPO och RTO kan hittas i översikten över affärskontinuitet.

Omdirigering av slutpunkt

Redundansgrupper tillhandahåller skriv- och lässkyddade lyssnarslutpunkter som förblir oförändrade under geo-failovers. Du behöver inte ändra anslutningssträngen för ditt program efter en geografisk failover eftersom anslutningar automatiskt dirigeras till den nuvarande primära servern. En geo-failover gör att samtliga sekundära databaser i gruppen övertar den primära rollen. När geo-failover är klar uppdateras DNS-uppgiften automatiskt för att omdirigera slutpunkterna till den nya regionen.

Avlasta läsintensiva arbetsuppgifter

Om du vill minska trafiken till dina primära databaser kan du också använda de sekundära databaserna i en failover-grupp för att avlasta läsintensiva arbetsbelastningar. Använd lyssnaren för endast läsning för att dirigera bara läsbar trafik till en läsbar sekundär databasnod.

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

Omkopplingspolicy

Failovergrupper stöder två failover-policyer:

• Kundhanterad (rekommenderas) – Kunder kan utföra en failover av en grupp när de märker ett oväntat avbrott som påverkar en eller flera databaser i failovergruppen. När du använder kommandoradsverktyg som PowerShell, Azure CLI eller REST API är värdet för failover-policy för kundhanterade inställningar manual.
• Microsoft hanterad – I händelse av ett omfattande avbrott som påverkar en primär region initierar Microsoft redundansväxling av alla berörda redundansgrupper som har sin redundansprincip konfigurerad att vara Microsoft-hanterad. Microsofts hanterade redundans 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 värdet för överflyttningspolicyn för Microsoft-hanterad automatic.

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:

Hanterad av kunden

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 de 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 failover för att återställa affärskontinuiteten.

Att ställa in din policy för failover på kundhanterad är starkt rekommenderat, eftersom du får kontroll över när du ska påbörja en failover 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å 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 verifiering av omfattningen och hanteringen av avbrottet beror på mänskliga åtgärder, kan respitperioden inte sättas till under en timme.

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

Ange failover-policy endast som Microsoft-hanterad 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 failovergruppen växlar över oavsett deras 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.
• De primära och sekundära replikerna i redundansgruppen har samma tjänstnivå, beräkningsnivå och beräkningsstorlek.

När Microsoft utlöser en failover läggs en post för åtgärden med namnet Failover i Azure SQL-failover-gruppen till i Azure Monitor-aktivitetsloggen. Posten innehåller namnet på redundansgruppen under Resurs, och Händelse initierad av visar ett bindestreck (-) som anger att övergången till redundans initierades av Microsoft. Den här informationen finns också på sidan aktivitetslogg på den nya primära servern eller instansen i Azure-portalen.

Terminologi och funktioner

• failover-grupp (FOG)

  Med en redundansgrupp kan alla användardatabaser i en SQL-hanterad instans redundansväxla som en enhet till en annan Azure-region om den primära SQL-hanterade instansen blir otillgänglig på grund av ett avbrott i den primära regionen. Eftersom redundansgrupper för SQL Managed Instance innehåller alla användardatabaser i instansen kan endast en redundansgrupp konfigureras på en instans.

  Viktig

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

• primär

  Den SQL-hanterade instansen som är värd för de primära databaserna i redundansgruppen.

• sekundär

  Den SQL-hanterade instansen 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.

  Viktig

  Om en databas innehåller minnesinterna OLTP-objekt måste den primära och sekundära geo-replikinstansen ha matchande tjänstnivåer, eftersom minnesinterna OLTP-objekt finns i minnet. En lägre tjänstnivå på geo-replikatinstansen kan leda till minnesbrist. Om detta inträffar kan den sekundära 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 redundans misslyckas. Undvik detta genom att se till att tjänstnivån för den geo-sekundära instansen matchar den primära databasens. Uppgraderingar på tjänstnivå kan vara datastorleksåtgärder och kan ta ett tag att slutföra.

• Failover (ingen dataförlust)

  Failover-processen utför fullständig datasynkronisering mellan primära och sekundära databaser innan den sekundära övertar den primära rollen. Detta garanterar ingen dataförlust. Failover är bara möjlig när det primära systemet är tillgängligt. Failover används i följande scenarier:

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

• Tvingad failover (potentiell dataförlust)

  Tvingad failover byter omedelbart ut 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. Tvungen övergång används som en återställningsmetod vid avbrott när det primära systemet inte är tillgängligt. När avbrotten har åtgärdats återansluter den gamla primära automatiskt och blir en ny sekundär. En failover kan köras för att återgå, vilket återställer 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 en tvungen failover av grupper med Microsofts hanterade failoverprinciper leda till dataförlust. Du kan anpassa redundanspolicyn så att den återspeglar programmets tolerans mot dataförlust. Genom att konfigurera GracePeriodWithDataLossHourskan 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.

• DNS-zon

  Ett unikt ID som genereras automatiskt när en ny SQL Managed Instance 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å SQL-hanterade instanserna i samma redundansgrupp måste dela DNS-zonen.

• Läs-och-skriv-listener för failover-grupp

  En DNS CNAME-post som pekar på den aktuella primära servern. Den skapas automatiskt när failover-gruppen skapas och gör att läs- och skrivarbetsbelastningen kan transparent återanslutas till den primära noden när den primära noden ändras efter en failover. När redundansgruppen skapas på en SQL-hanterad instans, skapas DNS CNAME-posten för lyssnarens URL som <fog-name>.<zone_id>.database.windows.net.

• skrivskyddad lyssnare för failovergrupper

  En DNS CNAME-post som pekar på den aktuella sekundären. Den skapas automatiskt när redundansgruppen skapas och möjliggör att den skrivskyddade SQL-arbetsbelastningen kan ansluta utan avbrott till den sekundära när den sekundära ändras efter failover. När redundansgruppen skapas på en SQL-hanterad instans, skapas DNS CNAME-posten för lyssnarens URL som <fog-name>.secondary.<zone_id>.database.windows.net. Som standardinställning inaktiveras omkopplingen för den skrivskyddade lyssnaren eftersom det säkerställer att primärinstansens prestanda inte påverkas när sekundärinstansen är offline. Men det innebär också att skrivskyddade sessioner inte kan ansluta förrän den sekundära servern har återställts. Om du inte kan tolerera driftstopp för skrivskyddade sessioner och kan använda den primära instansen för både skriv- och lästrafik på bekostnad av den potentiella prestandaförsämringen av den primära instansen, kan du aktivera failover för den skrivskyddade lyssnaren genom att konfigurera egenskapen AllowReadOnlyFailoverToPrimary. I så fall omdirigeras den skrivskyddade trafiken automatiskt till den primära om den sekundära inte är tillgänglig.

  Obs

  Egenskapen AllowReadOnlyFailoverToPrimary gäller endast om Microsofts hanterade redundansprincip är aktiverad och en tvingad redundans har utlösts. I så fall, om egenskapen är inställd på True, hanterar den nya primära instansen både läs- och skrivsessioner samt skrivskyddade sessioner.

Arkitektur för redundanskluster

Redundansgruppen måste konfigureras på den primära instansen och ansluta den till den sekundära instansen i en annan Azure-region. Alla användardatabaser på den primära instansen replikeras till den sekundära instansen. Systemdatabaser som master och msdb replikerade inte.

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

Om ditt program använder SQL Managed Instance som datanivå följer du de allmänna riktlinjer och metodtips som beskrivs i den här artikeln när du utformar för affärskontinuitet.

Skapa den geo-sekundära instansen

För att säkerställa oavbruten anslutning till den primära SQL Managed Instance efter redundansväxlingen måste både de primära och sekundära instanserna finnas i samma DNS-zon. Det garanterar att samma SAN-certifikat (multi-domain) kan användas för att autentisera klientanslutningar till någon av de två instanserna i redundansgruppen. När ditt program är redo för produktionsdistribution skapar du en sekundär SQL Managed Instance i en annan region och ser till att den 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 instansen. Om du använder PowerShell eller REST-API:et är namnet på den valfria parametern DNSZonePartner. Namnet på motsvarande valfria fält i Azure-portalen ä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 Konfigurera en redundansgrupp för Azure SQL Managed Instance.

Använda parkopplade regioner

Distribuera båda SQL-hanterade instanserna till parkopplade regioner av prestandaskäl. SQL Managed Instance-failovergrupper i parkopplade regioner har bättre prestanda jämfört med regioner som inte är parkopplade.

Azure SQL Managed Instance följer en säker distributionspraxis där azure-kopplade regioner vanligtvis inte distribueras till på samma gång. Det går dock inte att förutsäga vilken region som uppgraderas först, så distributionsordningen är inte garanterad. Ibland uppgraderas den primära instansen först och ibland uppgraderas den sekundära instansen först.

I situationer där Azure SQL Managed Instance ingår i en redundansgruppoch instanserna i gruppen inte finns i Azure-kopplade regionerväljer du olika underhållsfönsterscheman för din primära och sekundära databas. Välj till exempel en veckodagsunderhållsperiod för din geo-sekundära databas och en helgunderhållsperiod för din geo-primära databas.

Aktivera och optimera trafikflödet för geo-replikering mellan instanserna

Anslutningen mellan de virtuella nätverkens undernät som är värd för den primära och sekundära instansen måste upprättas och underhållas för att säkerställa ett oavbrutet trafikflöde för geo-replikering. Det finns flera sätt att tillhandahålla anslutning mellan de instanser som du kan välja mellan baserat på din nätverkstopologi och principer:

• Global peering för virtuella nätverk
• VPN-gatewayer
• Azure ExpressRoute

Global peering för virtuella nätverk (VNet-peering) är det rekommenderade sättet att upprätta anslutning mellan två instanser i en redundansgrupp. Det ger en privat anslutning med låg svarstid och hög bandbredd mellan peer-kopplade virtuella nätverk med hjälp av Microsofts staminfrastruktur. Vid kommunikation mellan peerkopplade virtuella nätverk krävs inget offentligt Internet, inga gatewayer och ingen ytterligare kryptering.

Inledande seeding

När du upprättar en redundansgrupp mellan SQL-hanterade instanser finns det en inledande seeding-fas innan datareplikeringen startar. Den inledande seedningsfasen är den längsta och dyraste delen av åtgärden. När den första seedingen är klar synkroniseras data och endast efterföljande dataändringar replikeras. Den tid det tar för den första seedningen att slutföras beror på storleken på data, antalet replikerade databaser, arbetsbelastningsintensiteten på de primära databaserna och hastigheten på länken mellan de virtuella nätverk som är värdar för den primära och sekundära instansen, vilket främst beror på hur anslutningen upprättas. Under normala omständigheter, och när anslutningen upprättas med rekommenderad global peering för virtuella nätverk, är starthastigheten upp till 360 GB i timmen för SQL Managed Instance. Seeding utförs för en batch med användardatabaser parallellt, men inte nödvändigtvis för alla databaser samtidigt. Flera batchar kan behövas om det finns många databaser på instansen.

Om länkens hastighet mellan de två instanserna är långsammare än nödvändigt påverkas sannolikt tiden för seedning märkbart. Du kan använda den angivna seedinghastigheten, 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 den inledande startfasen till exempel ta cirka 1,2 timmar om länken kan push-överföra 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 kan det ta cirka 10 timmar att skicka en databas på 100 GB. Om det finns flera databaser att replikera körs seeding parallellt. I kombination med en långsam länkhastighet kan den inledande seedningsfasen ta betydligt längre tid, särskilt om parallell seeding av data från alla databaser överskrider den tillgängliga länkbandbredden.

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

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

Använd läs- och skrivlyssnare (primär MI)

För läs- och skrivarbetsbelastningar använder du <fog-name>.zone_id.database.windows.net som servernamn. Anslutningar dirigeras automatiskt till den primära. Det här namnet ändras inte efter övergången. Geo-överflyttning innebär uppdatering av DNS-posten, så nya klientanslutningar dirigeras till den nya primärservern först efter att klientens DNS-cache har uppdaterats. Eftersom den sekundära instansen delar DNS-zonen med den primära kan klientprogrammet återansluta till den med samma SAN-certifikat på serversidan. De befintliga klientanslutningarna måste avslutas och sedan återskapas för att dirigeras till det nya primära systemet. Det går inte att nå läs-skrivlyssnaren och den skrivskyddade lyssnaren via den offentliga slutpunkten för SQL-hanterad instans.

Använd lyssnaren i skrivskyddat läge (sekundär MI)

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

På nivån Affärskritisk stöder SQL Managed Instance 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-replikerad sekundär kan du använda den här funktionen för att ansluta till antingen en skrivskyddad kopia på den primära platsen eller på den geo-replikerade platsen.

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

Den skrivskyddade lyssnaren och den skrivskyddade lyssnaren kan inte nås via offentlig slutpunkt för SQL-hanterad instans.

Potentiell prestandaförsämring efter omkoppling

Ett typiskt Azure-program använder flera Azure-tjänster och består av flera komponenter. Geo-redundans för gruppen utlöses baserat på tillståndet för enbart Azure SQL-komponenterna. Ett avbrott kanske inte påverkar andra Azure-tjänster i den primära regionen 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. Kontrollera redundansen för alla programmets komponenter i den sekundära regionen och redundansväxla programkomponenterna tillsammans med databasen så att högre svarstid mellan regioner inte påverkar programmets prestanda.

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.

DNS-uppdatering

DNS-uppdateringen av läs-skrivlyssnare sker omedelbart efter att en failover har initierats. Den här åtgärden resulterar inte i dataförlust. Det kan dock ta upp till fem minuter att byta databasroller under normala förhållanden. Tills det är klart är vissa databaser i den nya primära instansen fortfarande skrivskyddade. Om en failover initieras med PowerShell är åtgärden för att växla den primära replikrollen synkroniserad. Om det initieras med hjälp av Azure-portalen anger användargränssnittet slutförandestatus. Om det initieras med hjälp av REST API använder du Azure Resource Manager-avsökningsmekanismen som standard för att övervaka slutförandet.

Spara kostnader med en licensfri DR-replik

Du kan spara på SQL Server-licenskostnader genom att konfigurera din sekundära SQL-hanterade instans som endast ska användas för haveriberedskap (DR). Information om hur du konfigurerar detta finns i Konfigurera en licensfri standby-replik för Azure SQL Managed Instance.

Så länge den sekundära instansen inte används för läsarbetsbelastningar ger Microsoft dig ett kostnadsfritt antal virtuella kärnor som matchar den primära instansen. Du debiteras fortfarande för beräkning och lagring som används av den sekundära instansen. Redundansgrupper stöder endast en replik och repliken måste antingen vara en läsbar replik eller vara en DR-only-replik.

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

Systemdatabaser inte replikeras till sekundärinstansen i en failover-grupp. Om du vill aktivera scenarier som är beroende av objekt från systemdatabaserna måste du skapa samma objekt på den sekundära instansen. Håll dem synkroniserade med den primära instansen.

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

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

Mer information finns i Replikering av inloggningar och agentjobb.

Synkronisera instansegenskaper och kvarhållningsprincipinstanser

Instanser i en redundansgrupp förblir åtskilda från 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 på både den primära och sekundära instansen. Om du till exempel ändrar redundans för lagring av säkerhetskopior eller långsiktig kvarhållningsprincip för säkerhetskopiering på den primära instansen måste du också ändra den på den sekundära instansen.

Skala upp eller ner instanser

Konfigurationen av din primära och sekundära instans bör vara densamma. Detta omfattar beräkningsstorlek, lagringsstorlek och tjänstnivå. Om du behöver ändra konfigurationen för redundansgruppen kan du göra det genom att skala varje instans till samma konfiguration i enlighet med detta. Mer information finns i Skala instanser i en redundansgrupp.

Förhindra förlust av kritiska data

På grund av den långa svarstiden för nätverk i stora områden använder geo-replikering en asynkron replikeringsmekanism. Asynkron replikering gör risken för dataförlust oundviklig om den primära replikeringen misslyckas. Information om hur du kan skydda dina data finns i Förhindra dataförlust.

Status för failover-grupp

Failover-grupp rapporterar sin status som anger det aktuella tillståndet för datareplikering.

• Seeding: Inledande seeding sker efter att redundansgruppen har skapats tills alla användardatabaser initieras på den sekundära instansen. Avbrottshantering kan inte initieras när redundansgruppen är i seeding-status, då användardatabaser inte har kopierats till den sekundära instansen ännu.
• Synkronisering: Den vanliga statusen för redundansgruppen. Det innebär att dataändringar på den primära instansen replikeras asynkront till den sekundära instansen. Den här statusen garanterar inte att data synkroniseras fullständigt varje gång. Det kan finnas dataändringar från den primära som fortfarande ska replikeras till den sekundära på grund av replikeringsprocessens asynkrona karaktär mellan instanser i en redundansgrupp. Både automatiska och manuella redundansväxlingar kan initieras medan redundansgruppen är i synkroniseringstillståndet.
• Redundans pågår: Den här statusen anger att antingen automatisk eller manuellt initierad redundans pågår. Inga ändringar i redundansgruppen eller ytterligare redundansväxlingar kan initieras medan redundansgruppen är i det här tillståndet.

Å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. Återgång till det ursprungliga primärsystemet måste initieras manuellt.

Funktionskompatibilitet

Säkerhetskopior

En fullständig säkerhetskopia görs i följande scenarier:

• Innan den första seedingen börjar när du skapar en redundansgrupp.
• Efter en redundansväxling.

Fullständig säkerhetskopiering är en omfattande datahantering som inte kan hoppas över eller skjutas upp och som kan ta tid att genomföra. Den tid det tar att slutföra beror på storleken på data, antalet databaser och arbetsbelastningsintensiteten på de primära databaserna. En fullständig säkerhetskopia kan märkbart fördröja den inledande seedingen och kan antingen fördröja eller förhindra en felövergångsåtgärd på en ny instans strax efter en felövergång.

Tänk på följande:

• Databaser som finns på den sekundära instansen av en redundansgrupp säkerhetskopieras inte förrän den instansen blir primär efter en redundansväxling eller tills redundansgruppen har tagits bort.
• När en databas ändras till den primära rollen efter en redundansväxling eller blir fristående efter att en redundansgrupp har tagits bort initieras automatiskt en fullständig databassäkerhetskopia för att underlätta återställningar till tidpunkt.
• Det går inte att återställa en databas från en instans till en tidpunkt då den instansen var en sekundär replik i en redundansgrupp. Om du vill återställa till en tidpunkt måste du återställa databasen från den instans som var primär under den tidpunkten.
• Om du vill återskapa en borttagen redundansgrupp på samma par sql-hanterade instanser måste alla användardatabaser tas bort från den avsedda sekundära när redundansgruppen har tagits bort. En databas tas bara bort helt när alla väntande säkerhetskopieringsåtgärder har slutförts, inklusive en fullständig säkerhetskopia om en inte har tagits (vilket är storleken på dataåtgärden). Tillåt tid att rensa den sekundära instansen efter att en redundansgrupp har släppts med mycket stora databaser, eftersom varje databas kan ha en väntande fullständig säkerhetskopieringsåtgärd pågår.

En fullständig säkerhetskopia är en viktig dataåtgärd som inte kan bli utelämnad eller uppskjuten och kan ta tid att slutföra. Den tid det tar att slutföra beror på storleken på data, antalet databaser och arbetsbelastningsintensiteten på de primära databaserna. En fullständig säkerhetskopia kan märkbart fördröja inledande seedning och kan antingen fördröja eller förhindra en övergång på en ny instans strax efter en systemväxling.

Loggåterspelningstjänst

Databaser som migreras till Azure SQL Managed Instance med hjälp av Log Replay Service (LRS) kan inte läggas till i en redundansgrupp förrän snabbsteget har körts. En databas som migreras med LRS är i ett återställningsläge tills övergången, och databaser i återställningsläge kan inte läggas till i en failover-grupp. Försök att skapa en redundansgrupp med en databas i återställningstillstånd fördröjer skapandet av redundansgruppen tills databasåterställningen har slutförts.

Transaktionsreplikering

Användning av transaktionsreplikering med instanser som finns i en redundansgrupp stöds. Men om du konfigurerar replikering innan du lägger till din SQL-hanterade instans i en redundansgrupp pausar replikeringen när du börjar skapa redundansgruppen. Replikeringsövervakaren visar statusen Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Replikeringen återupptas när redundansgruppen har skapats framgångsrikt.

Om en utgivare-nod eller distributör-nod SQL-hanterad instans finns i en redundansgrupp, måste SQL-hanterad instansadministratören rensa alla publikationer på den gamla primära noden och konfigurera om dem på den nya primära noden när en redundansväxling inträffar. Granska transaktionsreplikeringsguiden för aktivitetsstegen som behövs i det här scenariot.

Behörigheter och begränsningar

Granska en lista över behörigheter och begränsningar innan du konfigurerar en redundansgrupp.

Hantera redundansgrupper programmatiskt

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

Haveriberedskapstest

Det rekommenderade sättet att utföra ett DR-test är att använda manuell planerad omkoppling, enligt följande handledning: Test failover.

Vi rekommenderar inte att du utför en övning med tvingat överlämnande eftersom denna åtgärd inte ger skydd mot dataförlust. Det är dock möjligt att uppnå dataförlustfri tvingad redundans genom att se till att följande villkor uppfylls innan den framtvingade redundansväxlingen initieras:

• Arbetsbelastningen stoppas på den primära SQL-hanterade instansen.
• Alla långvariga transaktioner har slutförts.
• Alla klientanslutningar till den primära SQL-hanterade instansen har kopplats från.
• Failover-gruppstatus är 'synkroniseras'.

Kontrollera att de två SQL-hanterade instanserna har växlade roller. Även att redundansgruppens status har växlat från "Redundans pågår" till "Synkronisering" innan du kan upprätta anslutningar till den nya primära SQL-hanterade instansen och starta läs-och skrivarbetsbelastning.

För att utföra en dataförlustfri återställning till de ursprungliga SQL-hanterade instansrollerna rekommenderar vi starkt att du använder manuell planerad redundans i stället för tvingad redundans. Om tvingad felåterställning används:

• Följ samma steg som för dataförlustfri övergång.
• Längre körningstid för återställning efter redundansväxling förväntas om den tvungna återställningen körs kort efter att den första tvungna redundansväxlingen har slutförts, eftersom den måste vänta på att de utestående automatiska säkerhetskopieringsåtgärderna har slutförts på den tidigare primära hanterade SQL-instansen.
• Eventuella utestående automatiska säkerhetskopieringsåtgärder på en instans som övergår från den primära till den sekundära rollen kan påverka databasens tillgänglighet på den här instansen.
• Använd statusen för redundansgrupper för att avgöra om båda instanserna har ändrat sina roller och är redo att acceptera klientanslutningar.

Relaterat innehåll

• Konfigurera en redundansgrupp för Azure SQL Managed Instance
• Använda PowerShell för att lägga till en SQL-hanterad instans i en redundansgrupp
• Konfigurera en licensfri standby-replik för Azure SQL Managed Instance
• Översikt över affärskontinuitet med Azure SQL Managed Instance
• Automatiserade säkerhetskopieringar i Azure SQL Managed Instance
• Återställa en databas från en säkerhetskopia i Azure SQL Managed Instance