Redundans- och redundanslägen (AlwaysOn-tillgänglighetsgrupper)

gäller för:SQL Server

I den här artikeln beskrivs redundans- och redundanslägen för SQL Server AlwaysOn-tillgänglighetsgrupper.

Översikt

Inom ramen för en tillgänglighetsgrupp är den primära och sekundära rollen för tillgänglighetsrepliker vanligtvis utbytbara i en process som kallas failover. Det finns tre former av överväxling: automatisk överväxling (utan dataförlust), planerad manuell överväxling (utan dataförlust) och tvingad manuell överväxling (med möjlig dataförlust), som vanligtvis kallas tvingad överväxling. Både automatisk och planerad manuell redundans bevarar alla dina data. En tillgänglighetsgrupp redundansväxlar på tillgänglighetsrepliknivå. En tillgänglighetsgrupp redundansväxlar till en av sina sekundära repliker (det aktuella redundansmålet).

Under redundansväxlingen tar redundansmålet över den primära rollen, återställer sina databaser och gör dem online som de nya primära databaserna. Den tidigare primära repliken, när den är tillgänglig, byter till den sekundära rollen, och dess databaser ändras till sekundära databaser. Dessa roller kan eventuellt växla fram och tillbaka (eller till ett annat redundansmål) som svar på flera fel eller i administrativa syften.

De former av redundans som en viss tillgänglighetsreplik stöder anges av egenskapen redundansläge . För en viss tillgänglighetsreplik beror möjliga redundanslägen på replikens tillgänglighetsläge enligt följande:

• Synkrona commit-repliker stöder två inställningar - automatiskt eller manuellt. Inställningen "automatisk" stöder både automatisk redundans och manuell redundans. För att förhindra dataförlust kräver automatisk redundans och planerad redundans att redundansmålet är en synkron incheckning av sekundär replik med ett felfritt synkroniseringstillstånd (detta indikerar att varje sekundär databas på redundansmålet synkroniseras med motsvarande primära databas). När en sekundär replik inte uppfyller båda dessa villkor stöder den endast tvungen omkoppling. Tvingad redundans stöds också på repliker i ett RESOLVEING-tillstånd.

• Asynkrona commit-repliker stöder endast manuellt failover-läge. Eftersom de aldrig synkroniseras stöder de dessutom endast tvingad redundans.

SQL Server 2025-ändringar

SQL Server 2025 introducerar följande ändringar:

Snabb redundans för beständiga hälsoproblem

I en AlwaysOn-tillgänglighetsgruppsmiljö övervakar Windows Redundanskluster (WSFC) hälsotillståndet för tillgänglighetsgruppen och dess repliker. När ett hälsoproblem identifieras på den primära repliken utlöser WSFC en sekvens med korrigerande åtgärder. Som standardinställning startar WSFC om resursen för tillgänglighetsgruppen på den aktuella repliken. Om WSFC inte kan aktivera resursen igen, flyttar WSFC över resursen för tillgänglighetsgruppen till en annan replik. Även om den här sekvensen med korrigerande åtgärder är effektiv för övergående fel kan det potentiellt leda till fördröjningar i failover för icke-övergående fel.

WSFC-redundansbeteendet styrs av värdet RestartThreshold . Som standard är RestartThreshold satt till 1 för en Always On-tillgänglighetsgrupp, vilket innebär att WSFC först försöker starta om resursen på den aktuella noden innan den säkrar övergången.

Från och med förhandsversionen av SQL Server 2025 (17.x) kan du ange RestartThreshold för en Always On-tillgänglighetsgrupp till 0, vilket instruerar WSFC att omedelbart redundansväxla resursen för tillgänglighetsgruppen när ett ihållande hälsoproblem upptäcks. Detta är användbart för scenarier där du vill minimera stilleståndstiden och se till att tillgänglighetsgruppen alltid är tillgänglig på en felfri replik.

Det finns en uppenbar kompromiss:

• Genom att ange RestartThreshold till 1 är din tillgänglighetsgrupp mer tolerant mot tillfälliga fel och kommer tillbaka online snabbare. Övergång och driftstopp kan dock vara längre vid beständiga fel.
• Genom att ange RestartThreshold till 0 är tillgänglighetsgruppen mindre tolerant mot tillfälliga fel, så redundansväxlingen kan vara onödig. Redundans och stilleståndstid kan dock vara kortare för beständiga fel.

Du kan använda Felöverklusterhanteraren eller PowerShell för att ange resursen RestartThreshold för en "Always On"-tillgänglighetsgrupp.

Om du till exempel vill ange RestartThreshold till 0 för tillgänglighetsgruppen med namnet ag1använder du följande kommando:

(Get-ClusterResource -Name "ag1").RestartThreshold = 0

Du kan verifiera den aktuella RestartThreshold inställningen genom att köra följande kommando:

Get-ClusterResource -Name "ag1" | Format-List *

Förbättring av asynkron sändning av sidförfrågningar

När en tillgänglighetsgrupp redundansväxlar måste varje replik hitta en gemensam återställningspunkt att synkronisera med. Återställningspunkten håller tillgänglighetsgruppen stabil så att den kan fortsätta att överföra ändringar. Ångra och återställ är en del av den här synkroniseringsprocessen. Ångra-of-redo sker när en sekundär replik måste återställa transaktioner för att komma till den gemensamma återställningspunkten. Undo-of-redo är vanligast vid haveriberedskap (DR) redundansväxling till en asynkron replik med FAILOVER_ALLOW_DATA_LOSS.

I vissa situationer, med en DR-övergång, när den sekundära repliken övergår till att bli den primära, har den nya primära repliken nätverksfördröjning från den ursprungliga primära repliken (nu nya sekundär), vilket saktar ner återställning av omspelning på den nya sekundära repliken.

SQL Server 2025 (17.x) Preview innehåller en uppdatering av synkroniseringsmekanismen, vilken gör att tillgänglighetsgruppen nu utför sidbegäranden asynkront och i batchar, för att förbättra återställningen i det här scenariot.

Tänk på följande:

• Förbättringen av synkroniseringsmekanismen är aktiverad som standard. Om du vill inaktivera förbättringen och återgå till standardbeteende aktiverar du spårningsflagga 12348 på alla repliker i en tillgänglighetsgrupp som för närvarande är sekundära, eller som kan vara sekundära i framtiden.
• Om tillgänglighetsgruppens repliker inte har nätverksfördröjning kanske denna förbättring inte påverkar återställningen av omrullningar.

Databaser växlar till ett återställningstillstånd efter ett fel

I sällsynta fall kan en eller flera databaser i en tillgänglighetsgrupp förbli i ett tillstånd som inte synkroniseras när en tillgänglighetsgrupp är offline under en kort tidsperiod på grund av en tillfällig förlust av WSFC-kvorum , till exempel från tillfällig nätverksavbrott eller majoriteten av klusternoderna startas om. Uppdateringen av tillgänglighetsgruppens återställningslogik som introducerades i SQL Server 2025 (17.x) Preview förbättrar den interna toleransen för den här typen av klusterkvorumförlust och förhindrar att tillgänglighetsgruppdatabaser fastnar i tillståndet Inte synkronisering när tillgänglighetsgruppen är online igen.

Villkor och definitioner

Automatisk avbrottshantering
En redundansväxling som sker automatiskt vid förlusten av den primära repliken. Automatisk redundans stöds endast när den aktuella primära och en sekundär replik båda är konfigurerade med redundansläget inställt på AUTOMATISK och den sekundära repliken synkroniseras för närvarande. Om redundansläget för antingen den primära eller sekundära repliken är MANUELL kan automatisk redundansväxling inte ske.

Planerad manuell redundans (utan dataförlust)
Planerad manuell redundans eller manuell redundans är en redundansväxling som initieras av en databasadministratör, vanligtvis i administrativt syfte. En planerad manuell redundans stöds endast om både den primära repliken och den sekundära repliken har konfigurerats för synkront incheckningsläge, och både den primära repliken och den sekundära repliken synkroniseras för närvarande (i synkroniserat tillstånd). När den sekundära målrepliken synkroniseras är manuell redundans (utan dataförlust) möjlig även om den primära repliken har kraschat eftersom de sekundära databaserna är redo för redundans. En databasadministratör initierar manuellt ett manuellt övertagande.

Tvungen växling (med risk för dataförlust)
En redundansväxling som kan initieras av en databasadministratör när ingen sekundär replik synkroniseras med den primära repliken eller om den primära repliken inte körs och ingen sekundär replik är redundansklar. Tvingad failover kan medföra dataförlust och rekommenderas endast för katastrofåterställning. Tvingad redundans kallas även för tvingad manuell redundans eftersom den endast kan initieras manuellt. Det här är den enda formen av redundans som stöds av i tillgänglighetsläget asynkron incheckning.

Automatisk redundansuppsättning

Inom en viss tillgänglighetsgrupp, ett par tillgänglighetsrepliker (inklusive den aktuella primära repliken) som är konfigurerade för synkron commit-läge med automatisk failover. En automatisk failover-inställning träder i kraft endast om den sekundära repliken just nu är SYNKRONISERAD med den primära repliken.

Redundansuppsättning för synkron incheckning

Inom en viss tillgänglighetsgrupp, en uppsättning med två eller tre tillgänglighetsrepliker (inklusive den aktuella primära repliken) som är konfigurerade för synkront incheckningsläge, om några. En synchronous-commit-redundansuppsättning börjar gälla endast om de sekundära replikerna har konfigurerats för manuellt redundansläge och minst en sekundär replik för närvarande synkroniseras med den primära repliken.

Hela redundansuppsättningen

I en viss tillgänglighetsgrupp är uppsättningen med alla tillgänglighetsrepliker vars drifttillstånd för närvarande är ONLINE, oavsett tillgänglighetsläge och redundansläge. Hela redundansuppsättningen blir relevant när ingen sekundär replik för närvarande synkroniseras med den primära repliken.

Översikt över redundans

I följande tabell sammanfattas vilka former av redundans som stöds under olika tillgänglighets- och redundanslägen. För varje parning bestäms det effektiva tillgänglighetsläget och redundansläget av skärningspunkten mellan lägena för den primära repliken plus lägena för en eller flera sekundära repliker.

¹ Om du utfärdar ett framtvingat redundanskommando på en synkroniserad sekundär replik fungerar den sekundära repliken på samma sätt som för en manuell redundansväxling.

Hur lång tid databasen inte är tillgänglig under en redundansväxling beror på typen av redundans och orsaken till den.

Redundansuppsättningar

De former av redundans som är möjliga för en viss tillgänglighetsgrupp kan förstås när det gäller redundansuppsättningar. En redundansuppsättning består av den primära repliken och sekundära repliker som stöder en viss form av redundans, enligt följande:

• Automatisk failover-uppsättning (valfritt): Inom en viss tillgänglighetsgrupp, ett par tillgänglighetsrepliker (inklusive den aktuella primära repliken) som är konfigurerade för synkron commit-läge med automatisk failover, om några. En automatisk failover-inställning träder i kraft endast om den sekundära repliken just nu är SYNKRONISERAD med den primära repliken.

• Redundansuppsättning för synkron incheckning (valfritt): Inom en viss tillgänglighetsgrupp, en uppsättning med två eller tre tillgänglighetsrepliker (inklusive den aktuella primära repliken) som är konfigurerade för synkront incheckningsläge, om några. En synchronous-commit-redundansuppsättning börjar gälla endast om de sekundära replikerna har konfigurerats för manuellt redundansläge och minst en sekundär replik för närvarande synkroniseras med den primära repliken.

• Hela redundansuppsättningen : I en viss tillgänglighetsgrupp är uppsättningen med alla tillgänglighetsrepliker vars drifttillstånd för närvarande är ONLINE, oavsett tillgänglighetsläge och redundansläge. Hela redundansuppsättningen blir relevant när ingen sekundär replik för närvarande synkroniseras med den primära repliken.

När du konfigurerar en tillgänglighetsreplik som synkron commit med automatisk failover, blir tillgänglighetsrepliken en del av den automatiska failovergruppen. Om uppsättningen börjar gälla beror dock på den aktuella primära inställningen. Vilka former av redundans som faktiskt är möjliga vid en viss tidpunkt beror på vilka redundansuppsättningar som för närvarande gäller.

Överväg till exempel en tillgänglighetsgrupp som har fyra tillgänglighetsrepliker enligt följande:

Redundansbeteendet för varje sekundär replik beror på vilken tillgänglighetsreplik som för närvarande är den primära repliken. För en viss sekundär replik är redundansbeteendet i princip det värsta fallet med tanke på den aktuella primära repliken. Följande bild illustrerar hur redundansbeteendet för sekundära repliker varierar beroende på den aktuella primära repliken och om den är konfigurerad för asynkront incheckningsläge (med endast framtvingad redundansväxling) eller synkront incheckningsläge (med eller utan automatisk redundans).

Automatisk övergång vid fel

En automatisk omkoppling gör att en kvalificerad sekundär kopia automatiskt övergår till den primära rollen när den primära kopian blir otillgänglig. Automatisk redundans passar bäst när den WSFC-nod som är värd för den primära repliken är lokal för noden som är värd för den sekundära repliken. Det beror på att datasynkronisering fungerar bäst med kort meddelandesvarstid mellan datorer och eftersom klientanslutningar kan förbli lokala.

i det här avsnittet:

• Villkor som krävs för automatisk omställning

• Så här fungerar automatisk redundans

• Aktivera automatisk failover

Nödvändiga villkor för en automatisk övergång

Automatisk omkoppling sker endast under följande villkor:

• Det finns en automatisk failover-konfiguration. Den här uppsättningen består av en primär replik och en sekundär replik ( det automatiska redundansmålet) som båda är konfigurerade för synkront incheckningsläge och som är inställda på AUTOMATISK redundans. Om den primära repliken är inställd på MANUELL redundans kan automatisk redundans inte ske, även om en sekundär replik är inställd på AUTOMATISK redundans.

  Mer information finns i tillgänglighetslägen (AlwaysOn-tillgänglighetsgrupper).

• Det automatiska redundansmålet har ett felfritt synkroniseringstillstånd (detta anger att varje sekundär databas på redundansmålet synkroniseras med motsvarande primära databas).

  Tips/Råd

  AlwaysOn-tillgänglighetsgrupper övervakar hälsotillståndet för båda replikerna i en automatisk redundansuppsättning. Om någon av replikerna misslyckas är tillgänglighetsgruppens hälsotillstånd inställt på KRITISK. Om den sekundära repliken misslyckas är automatisk redundans inte möjlig eftersom det automatiska redundansmålet inte är tillgängligt. Om den primära repliken misslyckas kommer tillgänglighetsgruppen att växla över till den sekundära repliken. Tills den tidigare primära repliken är online finns det inget automatiskt redundansmål. I båda fallen rekommenderar vi att du konfigurerar en annan sekundär replik som automatiskt redundansmål för att säkerställa tillgänglighet i det osannolika fallet av ett sekventiellt fel.

  Mer information finns i Använda AlwaysOn-principer för att visa hälsotillståndet för en tillgänglighetsgrupp (SQL Server) och ändra redundansläget för en tillgänglighetsreplik (SQL Server).

• WSFC-klustret (Windows Server Failover Clustering) har kvorum. Mer information finns i WSFC Quorum Modes and Voting Configuration (SQL Server).

• Den primära repliken har blivit otillgänglig och de redundansvillkorsnivåer som definieras av din flexibla redundansprincip har uppfyllts. Information om redundansvillkorsnivåer finns i Flexibel redundansprincip för automatisk redundans för en tillgänglighetsgrupp (SQL Server).

Så här fungerar automatisk failover

En automatisk redundans initierar följande sekvens av åtgärder:

1. Om serverinstansen som är värd för den aktuella primära repliken fortfarande körs ändrar den tillståndet för de primära databaserna till FRÅNKOPPLAD och kopplar från alla klienter.

2. Om några loggposter väntar i återställningsköer på den sekundära målrepliken tillämpar den sekundära repliken de återstående loggposterna för att slutföra framåtrullningen av de sekundära databaserna.

   Anmärkning

   Hur lång tid det tar att tillämpa loggen på en viss databas beror på systemets hastighet, den senaste arbetsbelastningen och mängden logg i återställningskön.

3. Den tidigare sekundära replikan övergår till den primära rollen. Deras databaser blir de primära databaserna. Den nya primära repliken återställer alla ogenomförda transaktioner (ångringsfasen av återställning) så snabbt som möjligt. Lås isolerar de här okomprifierade transaktionerna så att återställningen kan ske i bakgrunden medan klienter använder databasen. Den här processen återställer inte några bekräftade transaktioner.

   Tills en viss sekundär databas är ansluten markeras den kort som NOT_SYNCHRONIZED. Innan återställningen startar kan sekundära databaser ansluta till de nya primära databaserna och snabbt övergå till läget SYNKRONISERAD. Det bästa fallet är vanligtvis för en tredje synkron incheckningsreplik som förblir i den sekundära rollen efter redundansväxlingen.

4. Senare, när serverinstansen som är värd för den tidigare primära repliken startas om, identifierar den att en annan tillgänglighetsreplik nu äger den primära rollen. Den tidigare primära repliken övergår till den sekundära rollen och dess databaser blir sekundära databaser. Den nya sekundära repliken ansluter till den aktuella primära repliken och synkroniserar sin databas med de aktuella primära databaserna så snabbt som möjligt. Så snart den nya sekundära repliken har resynkroniserat sina databaser är omkoppling återigen möjlig i omvänd riktning.

Så här konfigurerar du automatisk failover

En tillgänglighetsreplik kan konfigureras för att stödja automatisk redundans när som helst.

Konfigurera automatisk övergång

1. Kontrollera att den sekundära repliken är konfigurerad för att använda synkron commit-läge. Mer information finns i Ändra tillgänglighetsläget för en tillgänglighetsreplik (SQL Server).

2. Ställ in redundansläget på automatiskt. För mer information, se Ändra failover-läge för en tillgänglighetsreplik (SQL Server).

3. Du kan också ändra tillgänglighetsgruppens flexibla redundansprincip för att ange vilka typer av fel som kan orsaka en automatisk redundansväxling. Mer information finns i Konfigurera flexibel redundansprincip för att kontrollera villkor för automatisk redundans (AlwaysOn-tillgänglighetsgrupper) och redundansprincip för redundansklusterinstanser.

Planerad manuell övergång (utan dataförlust)

En manuell failover gör att en synkroniserad sekundär replik övergår till den primära rollen efter att en databasadministratör utför ett manuellt failover-kommando på serverinstansen som är värd för den sekundära repliken. För att stödja manuell överlämning måste både den sekundära repliken och den aktuella primära repliken konfigureras för synkront commit-läge, om det finns något. Varje sekundär databas på tillgänglighetsrepliken måste vara ansluten till tillgänglighetsgruppen och synkroniseras med motsvarande primära databas (det vill: den sekundära repliken måste synkroniseras). Detta garanterar att varje transaktion som har checkats in på en tidigare primär databas också har checkats in på den nya primära databasen. Därför är de nya primära databaserna identiska med de gamla primära databaserna.

Följande bild illustrerar stegen i en planerad redundansväxling:

1. Före omkopplingen hanteras den primära repliken av serverinstansen på Node01.

2. En databasadministratör initierar ett planerat övertagande. Failovermålet är tillgänglighetsrepliken som värdas av serverinstansen på Node02.

3. Målet för failover (på Node02) blir den nya primära kopian. Eftersom det här är en planerad failöver, byter den tidigare primära repliken till den sekundära rollen under failövern och gör dess databaser tillgängliga som sekundära databaser omedelbart.

i det här avsnittet:

• Villkor som krävs för manuell övergång

• Så här fungerar manuell failover

• Upprätthålla tillgänglighet under uppgraderingar

Krav för en manuell övergång

För att stödja en manuell redundansväxling måste den aktuella primära repliken vara inställd på synkront incheckningsläge och en sekundär replik måste vara:

• Konfigurerad för synkron commit-läge.

• För närvarande synkroniserad med den primära replikan.

För att manuellt växla över en tillgänglighetsgrupp måste du vara ansluten till den sekundära replik som ska bli den nya primära repliken.

Så fungerar en planerad manuell överväxling

En planerad manuell redundans, som måste initieras på den sekundära målrepliken, initierar följande åtgärdssekvens:

1. För att säkerställa att inga nya användartransaktioner sker på de ursprungliga primära databaserna skickar WSFC-klustret en begäran till den primära repliken för att gå offline.

2. Om någon logg väntar i återställningskön för en sekundär databas slutförs den sekundära repliken med att rulla vidare den sekundära databasen. Hur lång tid som krävs beror på systemets hastighet, den nyliga arbetsbelastningen och mängden loggposter i återställningskön. Om du vill lära dig den aktuella storleken på återställningskön använder du prestandaräknaren för återställningskön . Mer information finns i SQL Server, Database Replica.

   Anmärkning

   Redundanstiden kan regleras genom att begränsa storleken på återställningskön. Detta kan dock göra att den primära repliken saktar ner så att den sekundära repliken kan hålla jämna steg med den.

3. Den sekundära repliken blir den nya primära repliken och den tidigare primära repliken blir den nya sekundära repliken.

4. Den nya primära repliken rullar tillbaka alla ogenomförda transaktioner och tar sina databaser online som primära databaser. Alla sekundära databaser markeras kort som INTE SYNKRONISERAde tills de ansluter och synkroniserar om till de nya primära databaserna. Den här processen återställer inte några bekräftade transaktioner.

5. När den tidigare primära repliken är online igen får den den sekundära rollen och den tidigare primära databasen blir den sekundära databasen. Den nya sekundära repliken synkroniserar snabbt om de nya sekundära databaserna med motsvarande primära databaser.

   Anmärkning

   Så snart den nya sekundära replikan har synkroniserat om databaserna är failover återigen möjlig, men denna gång i motsatt riktning.

Efter redundansväxlingen måste klienterna återansluta till den aktuella primära databasen. Mer information finns i Tillgänglighetsgrupplyssnare, Klientanslutning och Programredundans (SQL Server).

Upprätthålla tillgänglighet under uppgraderingar

Databasadministratören för dina tillgänglighetsgrupper kan använda manuella redundansväxlingar för att upprätthålla databasens tillgänglighet när du uppgraderar maskinvara eller programvara. Om du vill använda en tillgänglighetsgrupp för programvaruuppgraderingar måste serverinstansen och/eller datornoden som är värd för den sekundära målrepliken redan ha tagit emot uppgraderingarna. Mer information finns i Uppgradera AlwaysOn-tillgänglighetsgruppreplikinstanser.

Tvingad systemövergång (med möjlig dataförlust)

Att tvinga fram redundans för en tillgänglighetsgrupp (med möjlig dataförlust) är en haveriberedskapsmetod som gör att du kan använda en sekundär replik som en varm väntelägesserver. Eftersom tvingad redundans riskerar dataförlust, bör den användas försiktigt och sparsamt. Vi rekommenderar att du endast tvingar fram redundans om du måste återställa tjänsten till dina tillgänglighetsdatabaser omedelbart och är villig att riskera att förlora data. Mer information om förutsättningarna och rekommendationerna för att tvinga redundansväxling och ett exempelscenario som använder en tvingad redundansväxling för att återställa från ett oåterkalleligt fel finns i Utföra en tvingad manuell redundansväxling av en tillgänglighetsgrupp (SQL Server).

i det här avsnittet:

• Så här fungerar tvingad redundans

• Risker med att tvinga funktionsövergång

• Varför tvingad redundans krävs efter tvingad kvorum

• Spåra potentiell dataförlust

• Hantera potentiell dataförlust

Så här fungerar tvingad redundans

Att tvinga fram en felövergång initierar en övergång av den primära rollen till en målreplik vars roll är i tillståndet SECONDARY eller RESOLVING. Failover-målet blir den nya primära repliken och tillhandahåller omedelbart sina kopior av databaserna för klienterna. När den tidigare primära repliken blir tillgänglig övergår den till den sekundära rollen och dess databaser blir sekundära databaser.

Alla sekundära databaser (inklusive de tidigare primära databaserna, när de blir tillgängliga) pausas. Beroende på tidigare synkroniseringstillstånd för en pausad sekundär databas kan det vara lämpligt att återställa förlorade befintliga data för den primära databasen. På en sekundär replik som är konfigurerad för skrivskyddad åtkomst kan du fråga de sekundära databaserna om du vill identifiera saknade data manuellt. Sedan kan du utfärda Transact-SQL instruktioner för de nya primära databaserna för att göra nödvändiga ändringar.

Risker med att tvinga redundans

Det är viktigt att förstå att tvingad failover kan orsaka dataförlust. Dataförlust är möjligt eftersom målrepliken inte kan kommunicera med den primära repliken och därför inte kan garantera att databaserna synkroniseras. Tvingad redundans startar en ny återställningsgren. Eftersom de ursprungliga primära databaserna och de sekundära databaserna är på olika återställningspunkter, innehåller var och en av dem nu data som den andra databasen inte innehåller: varje ursprunglig primär databas omfattar de ändringar som ännu inte skickats från sin skickakö till tidigare sekundära databasen (den osända loggen); de tidigare sekundära databaserna innehåller de ändringar som inträffar efter att failover tvingades.

Om redundansväxlingen tvingas på grund av fel hos den primära repliken beror potentiell dataförlust på om några transaktionsloggar hade skickats till den sekundära repliken före felet. Under det asynkrona incheckningsläget är ackumulerad osänd logg alltid en möjlighet. I synkront incheckningsläge är detta endast möjligt tills de sekundära databaserna synkroniseras.

I följande tabell sammanfattas möjligheten för dataförlust för en viss databas på repliken som du tvingar överflyttning till.

Sekundära databaser spårar bara två återställningsbifurkationer, så om du utför flera framtvingade felövergångar kan det hända att en sekundär databas som startade datasynkroniseringen med den tidigare framtvingade felövergången kanske inte kan återuppta processen. Om detta inträffar måste alla sekundära databaser som inte kan återupptas tas bort från tillgänglighetsgruppen, återställas till rätt tidpunkt och återanslutas till tillgänglighetsgruppen. Fel 1408 med tillstånd 103 kan observeras i det här scenariot (fel: 1408, allvarlighetsgrad: 16, tillstånd: 103). En återställning fungerar inte för flera återställningsförgreningar, så se till att utföra en loggsäkerhetskopia efter att ha utfört mer än en tvingad felövergång.

Varför tvingad omkoppling krävs efter tvångskvorum

När kvorumet har tvingats på WSFC-klustret (tvingat kvorum) måste du utföra en tvingad omkoppling (med möjlig dataförlust) för varje tillgänglighetsgrupp. Den framtvingade redundansväxlingen krävs eftersom det verkliga tillståndet för WSFC-klustervärdena kan ha gått förlorat. Att förhindra normala redundansväxlingar efter att ett framtvingat kvorum krävs på grund av möjligheten att en osynkroniserad sekundär replik verkar synkroniseras i det omkonfigurerade WSFC-klustret.

Anta till exempel att ett WSFC-kluster som är värd för en tillgänglighetsgrupp på tre noder: Nod A är värd för den primära repliken och Nod B och Nod C är värdar för en sekundär replik. Node C kopplas från från WSFC-klustret medan den lokala sekundära repliken är SYNKRONISERAd. Nod A och Nod B behåller dock ett felfritt kvorum och tillgänglighetsgruppen förblir online. På nod A fortsätter den primära repliken att acceptera uppdateringar, och på Nod B fortsätter den sekundära repliken att synkroniseras med den primära repliken. Den sekundära repliken på Nod C blir osynkroniserad och hamnar allt efter den primära repliken. Men eftersom Nod C är frånkopplad förblir repliken felaktigt i tillståndet SYNKRONISERAD.

Om kvorum går förlorat och sedan tvingas på Nod A bör synkroniseringstillståndet för tillgänglighetsgruppen i WSFC-klustret vara korrekt med den sekundära repliken på Nod C som visas som OSYNKRONiserad. Men om kvorumet tvingas på Nod C är synkroniseringen av tillgänglighetsgruppen felaktig. Synkroniseringstillståndet i klustret har återställts till när Nod C kopplades från, med den sekundära repliken på Nod C visades felaktigt som SYNKRONISERAD. Eftersom planerade manuella överflyttningar garanterar säkerheten för data, tillåts de inte för att få en tillgänglighetsgrupp online igen efter att kvorumet har tvingats.

Spåra potentiell dataförlust

När WSFC-klustret har ett felfritt kvorum kan du uppskatta den aktuella risken för dataförlust på databaser. För en viss sekundär replik beror den aktuella risken för dataförlust på hur långt de lokala sekundära databaserna släpar efter motsvarande primära databaser. Eftersom fördröjningen varierar över tid rekommenderar vi att du regelbundet spårar potentiella dataförluster för dina osynkrona sekundära databaser. Spårningsfördröjning innebär att jämföra LSN för senaste kommittering och tidpunkt för senaste kommittering för varje primär databas och dess sekundära databaser på följande sätt:

1. Anslut till den primära repliken.

2. Fråga last_commit_lsn (LSN för den senaste transaktionen) och last_commit_time (tidpunkten för den senaste commit) i den dynamiska hanteringsvyn sys.dm_hadr_database_replica_states.

3. Jämför värdena som returneras för varje primär databas och var och en av dess sekundära databaser. Skillnaden mellan deras senaste åtagande LSN indikerar graden av fördröjning.

4. Du kan utlösa en avisering när mängden fördröjning på en databas eller uppsättning databaser överskrider den önskade maximala fördröjningen under en viss tidsperiod. Frågan kan till exempel köras av ett jobb som körs varje minut på varje primär databas. Om skillnaden mellan last_commit_time för en primär databas och någon av dess sekundära databaser har överskridit mål för återställningspunkt (RPO) (till exempel 5 minuter) sedan det senaste jobbet kördes, kan jobbet generera en avisering.

Hantera potentiell dataförlust

När redundansväxlingen har tvingats pausas alla sekundära databaser. Detta inkluderar de tidigare primärdatabaserna, efter att den tidigare primära repliken har kommit tillbaka online och upptäcker att den nu är en sekundär replik. Du måste återuppta varje pausad databas manuellt individuellt på varje sekundär replik.

När den tidigare primära repliken är tillgänglig, förutsatt att dess databaser är oskadade, kan du försöka hantera den potentiella dataförlusten. Den tillgängliga metoden för att hantera potentiell dataförlust beror på om den ursprungliga primära repliken har anslutits till den nya primära repliken. Förutsatt att den ursprungliga primära repliken kan komma åt den nya primära instansen sker återanslutning automatiskt och transparent.

Den ursprungliga primära repliken har återupprättat anslutningen.

Vanligtvis, efter ett fel, startar den ursprungliga primära repliken om och återansluter snabbt till sin partner. Vid återanslutning blir den ursprungliga primära repliken den sekundära repliken. Dess databaser blir de sekundära databaserna och går in i tillståndet SUSPENDED. De nya sekundära databaserna återställs inte om du inte återupptar dem.

De inaktiverade databaserna är dock otillgängliga, så du kan inte inspektera dem för att utvärdera vilka data som skulle gå förlorade om du skulle återuppta en viss databas. Beslutet om du vill återuppta eller ta bort en sekundär databas beror därför på om du är villig att acceptera dataförluster på följande sätt:

• Om det skulle vara oacceptabelt att förlora data bör du ta bort databaserna från tillgänglighetsgruppen för att rädda dem.

  Databasadministratören kan nu återställa de tidigare primära databaserna och försöka återställa de data som skulle ha gått förlorade. Men när en tidigare primär databas är online skiljer den sig från den aktuella primära databasen, så databasadministratören måste göra antingen den borttagna databasen eller den aktuella primära databasen otillgänglig för klienter för att undvika ytterligare skillnader i databaserna och för att förhindra problem med klientredundans.

• Om dataförlust skulle vara acceptabelt för dina affärsmål kan du återuppta de sekundära databaserna.

  Om du återupptar en ny sekundär databas återställs den som det första steget i synkroniseringen av databasen. Om några loggposter väntade i sändningskön vid tidpunkten för felet går motsvarande transaktioner förlorade, även om de har bekräftats.

Den ursprungliga huvudkopian har inte anslutits igen

Om du tillfälligt kan förhindra att den ursprungliga primära repliken återansluter över nätverket till den nya primära repliken kan du granska de ursprungliga primära databaserna för att utvärdera vilka data som skulle gå förlorade om de återupptogs.

• Om den potentiella dataförlusten är acceptabel

  Tillåt att den ursprungliga primära repliken återansluter till den nya primära repliken. Återanslutning gör att de nya sekundära databaserna pausas. Starta datasynkronisering på en databas genom att bara återuppta den. Den nya sekundära repliken släpper den ursprungliga återställningsgrenen för databasen och förlorar alla transaktioner som aldrig har skickats till eller tagits emot av den tidigare sekundära repliken.

• Om dataförlusten är oacceptabel

  Om den ursprungliga primära databasen innehåller kritiska data som skulle gå förlorade om du återupptog den pausade databasen kan du bevara data på den ursprungliga primära databasen genom att ta bort dem från tillgänglighetsgruppen. Detta gör att databasen går in i RESTORING-läget. I det här läget rekommenderar vi att du försöker säkerhetskopiera den senaste delen av loggen från den borttagna databasen. Sedan kan du uppdatera den aktuella primära (den tidigare sekundära databasen) genom att exportera de data som du vill rädda från den ursprungliga primära databasen och importera den till den aktuella primära databasen. Vi rekommenderar att du gör en fullständig databassäkerhetskopia av den uppdaterade primära databasen så snabbt som möjligt.

  På serverinstansen som är värd för den nya sekundära repliken kan du sedan ta bort den inaktiverade sekundära databasen och skapa en ny sekundär databas genom att återställa den här säkerhetskopian (och minst en efterföljande loggsäkerhetskopia) med HJÄLP av RESTORE WITH NORECOVERY. Vi rekommenderar att du fördröjer ytterligare loggsäkerhetskopior av de aktuella primära databaserna tills motsvarande sekundära databaser återupptas.

Relaterat innehåll

• översikt över AlwaysOn-tillgänglighetsgrupper (SQL Server)
• Tillgänglighetslägen (Always On-tillgänglighetsgrupper)
• Windows Server Failover Clustering (WSFC) (redundansklustring för Windows Server) med SQL Server
• Transaktioner mellan databaser och distribuerade transaktioner för AlwaysOn-tillgänglighetsgrupper och databasspegling (SQL Server)
• Redundansprincip för redundansklusterinstanser
• Flexibel redundansprincip för automatisk redundans för en tillgänglighetsgrupp (SQL Server)

Relaterade uppgifter

Konfigurera redundansbeteende

• Ändra tillgänglighetsläget för en tillgänglighetsreplik (SQL Server)
• Ändra failover-läget för en tillgänglighetsreplik (SQL Server)
• Konfigurera flexibel redundansprincip för att kontrollera villkor för automatisk redundans (AlwaysOn-tillgänglighetsgrupper)

Utför en manuell failover

• Utföra en planerad manuell failover av en tillgänglighetsgrupp (SQL Server)
• Utföra en tvingad manuell omkoppling av en tillgänglighetsgrupp (SQL Server)
• Använd guiden Växla över till en Tillgänglighetsgrupp (SQL Server Management Studio)
• Hantering av inloggningar och jobb för databaser i en tillgänglighetsgrupp (SQL Server)

Konfigurera WSFC-kvorumkonfiguration

• Konfigurera nodviktsinställningar för klusterkvorum
• Visa nodviktsinställningar för klusterkvorum
• Tvinga ett WSFC-kluster att starta utan kvorum