Dela via

Skillnader mellan tillgänglighetslägen för en AlwaysOn-tillgänglighetsgrupp

gäller för:SQL Server

I AlwaysOn-tillgänglighetsgrupper är tillgänglighetsläget en replikegenskap som avgör om en viss tillgänglighetsreplik kan köras i synkront incheckningsläge. För varje tillgänglighetsreplik måste tillgänglighetsläget konfigureras för antingen läget synchronous-commit, asynchronous-commit eller endast konfiguration.

Om den primära repliken har konfigurerats för asynkront incheckningsläge väntar den inte på att någon sekundär replik ska skriva inkommande transaktionsloggposter till disken (för att härda loggen).

Om en viss sekundär replik har konfigurerats för asynkront incheckningsläge väntar inte den primära repliken på att den sekundära repliken ska härda loggen. Om både den primära repliken och en viss sekundär replik är konfigurerade för synkron-kommitteringsläge, väntar den primära repliken på att den sekundära repliken ska bekräfta att loggen har säkerställts (såvida inte den sekundära repliken misslyckas med att pinga den primära repliken inom den primära repliken sessionens tidsgränsperiod).

Anmärkning

Om en synkron commit sekundär replik överskrider sessionens tidsgräns för den primära repliken (standardvärdet är 10 sekunder), markerar den primära repliken tillfälligt databasens synkroniseringstillstånd på den sekundära repliken som NOT SYNCHRONIZING och repliktillståndet som NOT_HEALTHY. När den sekundära repliken återansluter till den primära repliken återupptar de synkront bekräftelseläge.

Tillgänglighetslägen som stöds

AlwaysOn-tillgänglighetsgrupper stöder tre tillgänglighetslägen:

  • Asynkront åtagandeläge
  • Synkront åtagandeläge
  • Endast konfigurationsläge

Asynkront commit-läge är en katastrofåterställningslösning som fungerar bra när tillgänglighetskopiorna fördelas över stora avstånd. Om varje sekundär replik körs i asynkront åtagandeläge väntar inte den primära repliken på att någon av de sekundära replikerna ska säkra loggen. I stället skickar den primära repliken transaktionsbekräftelsen till klienten direkt efter att loggposten har skrivits till den lokala loggfilen. Den primära repliken körs med minsta möjliga transaktionsfördröjning i relation till en sekundär replik som är konfigurerad för asynkront commitläge.

Om den aktuella primära repliken är konfigurerad för asynkront bekräftelsetillgänglighetsläge bekräftar den transaktioner asynkront för alla sekundära repliker oavsett deras individuella tillgänglighetslägesinställningar.

Mer information finns iAsynchronous-Commit tillgänglighetsläge senare i den här artikeln.

Synkront bekräftelseläge betonar hög tillgänglighet framför prestanda, på bekostnad av ökad transaktionsfördröjning. I synkront commitläge väntar transaktionerna med att skicka transaktionsbekräftelsen till klienten tills den sekundära repliken har skrivit ned loggen till disken. När datasynkroniseringen börjar på en sekundär databas börjar den sekundära repliken tillämpa inkommande loggposter från motsvarande primära databas. När alla loggposter har härdats går den sekundära databasen in i SYNCHRONIZED-tillståndet. Därefter härdas varje ny transaktion av den sekundära repliken innan loggposten skrivs till den lokala loggfilen. När alla sekundära databaser för en viss sekundär replik är synkroniserade stöder synkront säkerhetskopieringsläge manuellt överlämnande och, om du vill, automatiskt överlämnande.

Mer information finns iSynchronous-Commit tillgänglighetsläge senare i den här artikeln.

Konfigurationsläget gäller endast för tillgänglighetsgrupper som inte finns i ett Windows Server-redundanskluster. En replik i konfigurationsläge innehåller inte användardata. I konfigurationsläge lagrar replikdatabasen master konfigurationsmetadata för tillgänglighetsgrupp. Mer information finns i Hög tillgänglighet och dataskydd för konfigurationer av tillgänglighetsgrupper.

Följande bild visar en tillgänglighetsgrupp med fem tillgänglighetsrepliker. Den primära repliken och en sekundär replik är konfigurerade för synkron commit-läge med automatisk överlämning. En annan sekundär replik konfigureras för synkront incheckningsläge med endast planerad manuell redundans och två sekundära repliker konfigureras för asynkront incheckningsläge, som endast stöder tvingad manuell redundans (kallas vanligtvis tvingad redundans).

Diagram över tillgänglighets- och redundanslägen för repliker.

Synkroniserings- och redundansbeteendet mellan två tillgänglighetsrepliker beror på tillgänglighetsläget för båda replikerna. För att synkron incheckning ska ske måste till exempel både den primära repliken och den sekundära repliken konfigureras för synkron incheckning. På samma sätt måste båda replikerna konfigureras för automatiska failöver. Sammanfattningsvis kan beteendet för det tidigare illustrerade distributionsscenariot beskrivas i följande tabell, där beteendet med varje möjlig primärreplik utforskas.

Aktuell primär kopia Automatiska redundansmål Beteende för synkront kommittéringsläge med Beteende för asynkront commit-läge med Automatisk failover är möjlig
01 02 02 och 03 04 Ja
02 01 01 och 03 04 Ja
03 01 och 02 04 Nej
04 01, 02 och 03 Nej

Vanligtvis distribueras Nod 04 som en asynkront replika på en katastrofåterhämtningsanläggning. Det faktum att Noderna 01, 02 och 03 förblir i asynkront incheckningsläge efter redundansväxling till nod 04 hjälper till att förhindra potentiell prestandaförsämring i tillgänglighetsgruppen på grund av hög nätverksfördröjning mellan de två platserna.

Tillgänglighetsläge för asynkront åtagande

I asynkron-committeringsläge blir den sekundära repliken aldrig synkroniserad med den primära repliken. Även om en viss sekundär databas kan komma ikapp motsvarande primära databas, kan alla sekundära databaser släpa efter när som helst. Asynkront commit-läge kan vara användbart i ett katastrofåterhämtningsscenario där den primära repliken och den sekundära repliken åtskiljs av ett betydande avstånd och där du inte vill att mindre fel ska påverka den primära repliken eller i situationer där prestanda är viktigare än synkroniserat dataskydd. Eftersom den primära repliken inte väntar på bekräftelser från den sekundära repliken påverkar problem på den sekundära repliken aldrig den primära repliken.

En sekundär replik med asynkront åtagande försöker hålla jämna steg med loggposter som tas emot från den primära repliken. Men sekundära databaser med asynkron commit förblir alltid osynkroniserade och kommer sannolikt att ligga något efter de motsvarande primära databaserna. Vanligtvis är klyftan mellan en sekundär databas med asynkron incheckning och motsvarande primära databas liten. Men klyftan kan bli betydande om servern som är värd för den sekundära repliken är överladdad eller om nätverket är långsamt.

Den enda formen av övergång som stöds av asynkront åtagandeläge är tvingad övergång (med möjlig dataförlust). Att tvinga redundans är en sista utväg som endast är avsedd för situationer där den aktuella primära repliken förblir otillgänglig under en längre period och omedelbar tillgänglighet för primära databaser är viktigare än risken för eventuell dataförlust. Redundansmålet måste vara en replik vars roll har antingen tillståndet SECONDARY eller RESOLVING. Målet för övergång övergår till den primära rollen, och dess kopior av databasen blir den primära databasen. Alla återstående sekundära databaser, tillsammans med de tidigare primära databaserna, när de blir tillgängliga, pausas tills du återupptar dem manuellt individuellt. I asynkront commit-läge, förloras alla transaktionsloggar som den ursprungliga primära repliken ännu inte har skickat till den tidigare sekundära repliken. Det innebär att vissa eller alla nya primära databaser kanske saknar nyligen genomförda transaktioner. Mer information om hur tvingad redundans fungerar och om metodtips för att använda den finns i Redundans- och redundanslägen (AlwaysOn-tillgänglighetsgrupper).

Synkron-commit-tillgänglighetsläge

Under synkront tillgänglighetsläge (synkront incheckningsläge) efter att ha anslutits till en tillgänglighetsgrupp, kommer en sekundär databas ikapp motsvarande primära databas och anger SYNCHRONIZED tillståndet. Den sekundära databasen förblir SYNCHRONIZED så länge datasynkroniseringen fortsätter. Detta garanterar att varje transaktion som checkas in på en viss primär databas har checkats in på motsvarande sekundära databas. När varje sekundär databas på en viss sekundär replik är synkroniserad är synkroniseringshälsotillståndet för den sekundära repliken i sin helhet HEALTHY.

I det här avsnittet:

Faktorer som stör datasynkronisering

När alla dess databaser har synkroniserats, går en sekundär replik in i HEALTHY-tillståndet. Den synkroniserade sekundära repliken förblir felfri om inget av följande inträffar:

  • En nätverks- eller datorfördröjning eller glitch orsakar att sessionen mellan den sekundära repliken och den primära repliken blir otillgänglig.

    Anmärkning

    Information om sessionstidsegenskapen för tillgänglighetsrepliker finns i Vad är en AlwaysOn-tillgänglighetsgrupp?

  • Du pausar en sekundär databas på den sekundära repliken. Den sekundära repliken upphör att synkroniseras och dess tillstånd för synkronisering och hälsotillstånd markeras som NOT_HEALTHY. Den sekundära repliken kan inte bli i gott skick igen förrän den tillfälligt stoppade sekundära databasen återstartas och synkroniseras på nytt eller tas bort från tillgänglighetsgruppen.

  • Du lägger till en primär databas i tillgänglighetsgruppen. Tidigare synkroniserade sekundära repliker går in i NOT_HEALTHY synkronisering-hälsotillståndet. Det här tillståndet anger att minst en databas är i synkroniseringstillståndet NOT SYNCHRONIZING . En viss sekundär replik kan inte vara HEALTHY igen förrän en motsvarande sekundär databas har förberetts på repliken, har anslutits till tillgänglighetsgruppen och har synkroniserats med den nya primära databasen.

  • Du ändrar den primära repliken eller den sekundära repliken till asynkront tillgänglighetsläge. När den sekundära repliken har ändrats till asynkront incheckningsläge förblir den i synchronization-health-tillståndet så länge datasynkroniseringen fortsätter. Men om endast den primära repliken ändras till asynkront commit-läge kommer den synkrona sekundära repliken att gå in i PARTIALLY_HEALTHY tillståndet synchronization-health. Det här tillståndet anger att minst en databas är i synkroniseringstillståndet SYNCHRONIZING , men ingen av databaserna är i NOT SYNCHRONIZING tillståndet .

  • Du ändrar någon sekundär replik till synkront commit-tillgänglighetsläge. Detta gör att den sekundära repliken markeras som i PARTIALLY_HEALTHY tillståndet synchronization-health tills alla dess databaser är i synkroniseringstillståndet SYNCHRONIZED .

Tips/Råd

För att visa synkroniseringshälsan för en tillgänglighetsgrupp, tillgänglighetsreplik eller tillgänglighetsdatabas, ställ en fråga till kolumnen synchronization_health eller synchronization_health_desc i respektive sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states, eller sys.dm_hadr_database_replica_states.

Så här fungerar synkronisering på en sekundär replik

När en sekundär replik ansluter sig till tillgänglighetsgruppen i synkront bekräftelseläge och upprättar en session med den primära repliken:

  1. Den sekundära repliken skriver inkommande loggposter till disken (härdar loggen).
  2. Den sekundära repliken skickar ett bekräftelsemeddelande till den primära repliken.

När den härdade loggen på den sekundära databasen har kommit ikapp till slutet på loggen på den primära databasen, är tillståndet för den sekundära databasen inställt på SYNCHRONIZED.

Den tid som krävs för synkronisering beror på hur långt den sekundära databasen låg bakom den primära databasen i början av sessionen. Det här deltat mäts med antalet loggposter som ursprungligen togs emot från den primära repliken, arbetsbelastningen på den primära databasen och hastigheten på instansvärden för den sekundära repliken.

Transaktionsprocessen

I synkront åtagandeläge åtagas transaktionerna till båda replikerna i den här ordningen:

  1. Den primära repliken tar emot en transaktion från en klient.

  2. Den primära repliken skriver loggposten till transaktionsloggen och skickar samtidigt loggposten till de sekundära replikerna.

    När en loggpost har skrivits till transaktionsloggen för huvuddatabasen kan transaktionen bara ångras om en failover sker till en sekundär som ännu inte tog emot loggen.

  3. Den primära repliken väntar på bekräftelse från den sekundära repliken synchronous-commit.

  4. Den sekundära repliken härdar loggen och returnerar en bekräftelse till den primära repliken.

  5. Den primära repliken slutför commit-behandlingen och skickar ett bekräftelsemeddelande till klienten.

Tidsgräns för synkron bekräftelse

Om en synkron incheckning av sekundär replik överskrider tidsgränsen utan att bekräfta att loggen har förstärkts sker följande åtgärder i tillgänglighetsgruppen:

  1. Den primära repliken markerar den sekundära repliken som felaktig.
  2. Det sekundära repliktillståndet ändras till DISCONNECTED.
  3. Det primära stoppet väntar på bekräftelse.
  4. Tillgänglighetsgruppen markerar synkroniseringstillståndet som NOT SYNCHRONIZING och repliktillståndet som NOT_HEALTHY.

Det här beteendet säkerställer att en misslyckad sekundär replik med synkron incheckning inte förhindrar logghärdning på den primära repliken.

När den sekundära repliken är online igen:

  1. Det sekundära repliktillståndet ändras till CONNECTED.
  2. Den sekundära repliken hanterar den primära replikens loggöverföringskö.
  3. Synkroniseringstillståndet övergår till SYNCHRONIZINGoch replikens hälsotillstånd till PARTIALLY_HEALTHY.

När loggens sändningskö har bearbetats blir synkroniseringstillståndet SYNCHRONIZED och replikens hälsotillstånd blir HEALTHY.

Synkront incheckningsläge skyddar dina data genom att kräva att data synkroniseras mellan två platser, vilket innebär att transaktionens svarstid ökar något.

Synkroniserad commit-läge med endast manuell failover

När dessa repliker är anslutna och databasen synkroniseras stöds manuell redundans. Om den sekundära repliken slutar fungera påverkas inte den primära repliken. Den primära repliken körs utan skydd om det inte finns några SYNCHRONIZED repliker (d.v.s. utan att överföra data till någon sekundär replik). Om den primära repliken går förlorad anger RESOLVING de sekundära replikerna tillståndet, men databasägaren kan tvinga fram en redundansväxling till den sekundära repliken (med möjlig dataförlust). Mer information finns i redundans- och redundanslägen (AlwaysOn-tillgänglighetsgrupper).

Synkront bekräftelseläge med automatisk övergång

Automatisk redundans ger hög tillgänglighet genom att säkerställa att databasen snabbt blir tillgänglig igen efter förlusten av den primära repliken. För att konfigurera en tillgänglighetsgrupp för automatisk redundans måste du ange både den aktuella primära repliken och minst en sekundär replik till synkront incheckningsläge med automatisk redundans. SQL Server 2019 (15.x) ökade det maximala antalet synkrona repliker till 5, upp från 3 i SQL Server 2017 (14.x). Du kan konfigurera den här gruppen med fem repliker så att den har automatisk redundans i gruppen. Det finns en primär replik, plus fyra synkrona sekundära repliker.

För att en automatisk redundansväxling ska vara möjlig vid en viss tidpunkt måste den sekundära repliken dessutom synkroniseras med den primära repliken (dvs. de sekundära databaserna synkroniseras alla) och WSFC-klustret (Windows Server Failover Clustering) måste ha kvorum. Om den primära repliken blir otillgänglig under dessa förhållanden sker automatisk redundans. Den sekundära repliken växlar till rollen primär och erbjuder sin databas som primär databas. Mer information finns i avsnittet "Automatisk redundans" i artikeln Redundanslägen och redundanslägen (AlwaysOn-tillgänglighetsgrupper).

Anmärkning

Information om WSFC-kvorum och AlwaysOn-tillgänglighetsgrupper finns i Mer information finns i WSFC Quorum Modes and Voting Configuration (SQL Server).

Datafördröjning på sekundär replik

Det är användbart att implementera skrivskyddad åtkomst till sekundära repliker om dina läsintensiva arbetsbelastningar kan tolerera viss datafördröjning. I situationer där datafördröjningen är oacceptabel kan du överväga att köra skrivskyddade arbetsbelastningar mot den primära repliken.

Den primära repliken skickar loggposter med ändringar i den primära databasen till de sekundära replikerna. På varje sekundär databas tillämpar en dedikerad redo-tråd loggposter. I en sekundär databas med läsåtkomst visas inte en viss dataändring i frågeresultatet förrän loggposten som innehåller ändringen har tillämpats på den sekundära databasen och transaktionen har checkats in på den primära databasen.

Det innebär att det finns viss svarstid, vanligtvis bara några sekunder, mellan de primära och sekundära replikerna. I ovanliga fall, till exempel om nätverksproblem minskar dataflödet, kan svarstiden bli betydande. Svarstiden ökar när I/O-flaskhalsar inträffar och när dataöverföringen suspenderas. Om du vill övervaka suspenderad dataflytt kan du använda instrumentpanelen för Always On Tillgänglighetsgrupp (SQL Server Management Studio) eller den dynamiska hanteringsvyn sys.dm_hadr_database_replica_states.

Om du vill minska svarstiden i SQL Server 2025 (17.x) förhandsversioner och senare versioner kan du minska den tid (i millisekunder) som den primära repliken tar för att checka in transaktioner till den sekundära repliken. Mer information finns i Serverkonfiguration: begärningstid för tillgänglighetsgrupp (ms).

Ändra tillgänglighetsläge och redundansläge

Justera kvorumröster

För att utföra en manuell överflyttning

Visa tillgänglighetsgrupp, tillgänglighetsreplik och databastillstånd

Relaterat innehåll