Felsöka en tillgänglighetsgruppsdatabas i återställningstillstånd

Den här artikeln hjälper dig att felsöka en tillgänglighetsgruppdatabas i återställningstillstånd.

Vad är återställningstillstånd?

Återställningstillstånd inträffar när den sekundära servern måste ångra ändringar som redan har tillämpats för att kunna synkroniseras igen med den primära servern.

Tillgänglighetsgruppens primära och sekundära repliker förblir i ett anslutet tillstånd under normal drift så att ändringar på den primära repliken aktivt synkroniseras med de sekundära replikerna.

Under redundansväxlingar avbryts det här anslutna tillståndet. När den nya primära repliken är online återupprättas anslutningen mellan den primära repliken och de sekundära replikerna. Under det här inledande anslutna tillståndet förhandlas en gemensam återställningspunkt där den nya sekundära ska starta återställningen så att den är synkroniserad med den primära.

Om en stor transaktion körs vid tidpunkten för redundansväxlingen ligger den nya sekundära databasloggen före den primära replikdatabasen. Den nya gemensamma återställningspunkten som förhandlas kräver att den sekundära repliken tar emot sidor från den primära repliken för att den ska vara i ett tillstånd där synkroniseringen kan återupptas. Återställningsprocessen kallas även "Ångra om gör om".

Återställningsprocessen är i sig långsam, sker ofta och vanligtvis märks inte små transaktioner som utlöser återställningstillstånd. Återställningstillstånd visas ofta när redundans avbryter en stor transaktion, vilket gör att många sidor skickas från den primära till den sekundära för att återställa den sekundära replikdatabasen till ett återställningsbart tillstånd.

Symptom och effekt för en tillgänglighetsgruppdatabas i återställningstillstånd

När en databas är i återställningstillstånd på den sekundära repliken synkroniseras inte databasen och tar därför inte emot ändringar från den primära repliken. En plötslig förlust av databasen på den primära repliken kan leda till dataförlust.

AlwaysOn-instrumentpanelsrapporter synkroniseras inte på den primära

När du har redundansväxla en tillgänglighetsgrupp kan du observera att den sekundära rapporten inte har synkroniserats medan redundansväxlingen lyckades. Instrumentpanelen AlwaysOn rapporterar inte synkronisering på den primära och återgår på den sekundära.

AlwaysOn-instrumentpanelsrapporter synkroniseras inte på den primära	AlwaysOn-instrumentpanelsrapporter återställs på den sekundära

Always On DMV:er rapporterar INTE SYNKRONISERING PÅ den primära

När du kör frågor mot följande AlwaysOn-tillgänglighetsgrupper (AGs) Dynamic Management Views (DMV) på den primära databasen är databasen i tillståndet INTE SYNKRONISERING .

SELECT DISTINCT ar.replica_server_name, drcs.database_name, drs.database_id, drs.synchronization_state_desc, drs.database_state_desc
FROM sys.availability_replicas ar 
JOIN sys.dm_hadr_database_replica_states drs 
ON ar.replica_id=drs.replica_id 
JOIN sys.dm_hadr_database_replica_cluster_states drcs
ON drs.group_database_id=drcs.group_database_id

När du frågar DMV:erna på den sekundära databasen är tillgänglighetsgruppens databas i återställningstillstånd .

Skrivskyddade arbetsbelastningar och rapporteringsarbetsbelastningar kan inte komma åt den sekundära databasen

När den sekundära databasen återställs kan den inte nås eller efterfrågas. Dessa skrivskyddade arbetsbelastningar är offline och avbryts. Beroende på hur länge databasen är i återställningstillstånd kan det vara nödvändigt att omdirigera dessa arbetsbelastningar till en annan sekundär replik eller den primära repliken om dessa arbetsbelastningar är affärskritiska.

Om du har en skrivskyddad arbetsbelastning, till exempel en rapporteringsarbetsbelastning som dirigeras till den sekundära repliken, kan dessa batchar misslyckas med meddelande 922:

Msg 922, Level 14, State 1, Line 2 Database "agdb" återställs. Väntar tills återställningen är klar.

Ett program som försöker logga in på den sekundära replikdatabasen i återställningstillståndet kan inte ansluta och genererar fel 18456:

2023-01-26 13:01:13.100 Inloggningsfel: 18456, Allvarlighetsgrad: 14, Tillstånd: 38. 2023-01-26 13:01:13.100 Inloggningen misslyckades för användaren "<UserName>". Orsak: Det gick inte att öppna den uttryckligen angivna databasen agdb. [KLIENT: <lokal dator>]

Det här felet kan också rapporteras i SQL Server felloggen om misslyckade inloggningar granskas.

Uppskatta tiden som återstår i återställningstillståndet

Använd någon av följande metoder för att uppskatta tiden som återstår i återställningstillståndet:

Använda AlwaysOn_health XEvent-session

Den AlwaysOn_health utökade händelsediagnostikloggen har en hadr_trace_message händelse som rapporterar återställningsstatus förlopp var femte minut.

Anslut till den sekundära repliken med SQL Server Management Studio (SSMS) Object Explorer och öka detaljnivån för hantering, utökade händelser och sedan sessioner. Högerklicka på händelsen AlwaysOn_health och välj Titta på livedata. Du bör få ett nytt fönster med flikar som rapporterar det aktuella tillståndet för återställningsåtgärden. Tillståndet rapporteras var femte minut via hadr_trace_message händelsen och den slutförda procentandelen återställningsåtgärd rapporteras.

Obs!

Den utökade händelsen hadr_trace_message lades till i de senaste kumulativa uppdateringarna i SQL Server 2019 och senare. Du måste köra de senaste kumulativa uppdateringarna för att observera den här utökade händelsen i den AlwaysOn_health utökade händelsesessionen.

Den SQL Server felloggen på den sekundära repliken är inte till stor hjälp när du beräknar att återställningen är slutförd. Från följande bild kan du observera från 10:08 till 11:03 när du är i återställningstillstånd, lite rapporteras. När den sekundära har tagit emot alla sidor från den primära repliken kan den nu återställa transaktionen som kördes på den ursprungliga primära som utlöste återställningstillståndet. Återställningen körs från 11:03 till 11:05. Strax efter att återställningen har slutförts bör databasen börja synkronisera med den primära repliken och komma ikapp alla ändringar som gjorts på den primära medan den sekundära databasen var i återställningstillstånd.

Övervaka återställning av slutförandetid med prestandaövervakaren

Övervaka återställningsstatusförloppet med hjälp av prestandaräknarna SQL Server:D atabase Replica:Total Log Requiring Undo and SQL Server:D atabase Replica:Log Remaining for Undo och välj tillgänglighetsgruppdatabasen för instansen. I exemplet på följande skärmbild rapporteras total logg som kräver ångra som 56,3 MB, och loggen som återstår för Ångra sjunker långsamt till 0 som rapporterar återställningsstatus.

Vilka andra alternativ har du förutom att vänta?

Microsoft rekommenderar att du beräknar tiden för slutförandet av återställningstillståndet.

Lägga till en sekundär replik i en tillgänglighetsgrupp

Om det bara finns två repliker i tillgänglighetsgruppen lägger du om möjligt till en annan sekundär replik som kan ge hög tillgänglighet och redundans och aktivt synkronisera med den primära repliken medan den andra sekundära repliken återställs.

Viktigt

Redundansväxla inte till en replik vars databaser är i återställningstillstånd. Detta kan resultera i en oanvändbar databas som kräver en återställning från säkerhetskopian. Starta inte om den sekundära replikinstansen, den påskyndar inte den här processen och kan äventyra tillståndet för den sekundära replikdatabasen som är i återställningstillstånd.

Åtgärda misslyckade skrivskyddade arbetsbelastningar

Eftersom de sekundära replikdatabaserna som återställs inte är tillgängliga misslyckas skrivskyddade arbetsbelastningar. Uppdatera routningstabellen för lässyfte för att dirigera trafiken tillbaka till den primära repliken eller till en annan sekundär replik tills den berörda sekundära replikdatabasen har slutfört återställningsprocessen.

Undvik att återställa tillstånd – övervaka för stora transaktioner

Om du observerar det här tillståndet ofta under planerade redundansväxlingar implementerar du en procedur som söker efter stora transaktioner före redundansväxlingar. Följande fråga rapporterar transaktionens starttid och aktuella tid för alla öppna transaktioner i systemet och tillhandahåller indatabufferten för transaktionerna.

SELECT tat.transaction_begin_time, getdate() AS 'current time', es.program_name, es.login_time, es.session_id, tst.open_transaction_count, eib.event_info
FROM sys.dm_tran_active_transactions tat
JOIN sys.dm_tran_session_transactions tst ON tat.transaction_id=tst.transaction_id
JOIN sys.dm_exec_sessions es ON tst.session_id=es.session_id 
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) eib WHERE es.is_user_process = 1
ORDER BY tat.transaction_begin_time ASC