Problemen met een database van een beschikbaarheidsgroep oplossen met de status Herstellen

Dit artikel helpt u bij het oplossen van problemen met een database van een beschikbaarheidsgroep die de status terugdraait.

Wat is het terugdraaien van de status?

De status Herstellen treedt op wanneer de secundaire server wijzigingen ongedaan moet maken die al zijn toegepast om terug te gaan in synchronisatie met de primaire server.

Primaire en secundaire replica('s) van de beschikbaarheidsgroep blijven tijdens de normale werking verbonden, zodat wijzigingen op de primaire replica actief worden gesynchroniseerd met de secundaire replica('s).

Tijdens failovers wordt deze verbonden status verbroken. Zodra de nieuwe primaire replica online is gekomen, wordt de verbinding hersteld tussen de primaire replica en secundaire replica('s). Tijdens deze initiële verbonden status wordt onderhandeld over een gemeenschappelijk herstelpunt waarin de nieuwe secundaire moet worden hersteld, zodat deze gesynchroniseerd is met de primaire.

Als een grote transactie wordt uitgevoerd op het moment van de failover, loopt het nieuwe secundaire databaselogboek voor op de primaire replicadatabase. Het nieuwe gemeenschappelijke herstelpunt dat is onderhandeld, vereist dat de secundaire replica pagina's van de primaire replica ontvangt, zodat deze zich in een status bevindt waarin de synchronisatie kan worden hervat. Het terugdraaien van het proces wordt ook wel 'Ongedaan maken van opnieuw uitvoeren' genoemd.

Het terugdraaien van het proces is inherent traag, gebeurt vaak en meestal worden kleine transacties die de terugdraaiende status activeren nauwelijks opgemerkt. Het terugdraaien van de status wordt vaak opgemerkt wanneer failover een grote transactie onderbreekt, waardoor veel pagina's van de primaire naar de secundaire pagina worden verzonden om de secundaire replicadatabase terug te keren naar een herstelbare status.

Symptomen en effect van een database van een beschikbaarheidsgroep die de status terugdraait

Wanneer een database de status terugzet op de secundaire replica, wordt de database niet gesynchroniseerd en ontvangt deze dus geen wijzigingen van de primaire replica. Een plotseling verlies van de database op de primaire replica kan leiden tot gegevensverlies.

AlwaysOn-dashboardrapporten die niet worden gesynchroniseerd op de primaire

Nadat een failover van een beschikbaarheidsgroep is uitgevoerd, ziet u mogelijk dat de secundaire wordt gerapporteerd als niet gesynchroniseerd terwijl de failover is geslaagd. Het AlwaysOn-dashboard rapporteert niet synchroon op de primaire en wordt teruggezet op de secundaire.

AlwaysOn-dashboardrapporten die niet worden gesynchroniseerd op de primaire	AlwaysOn-dashboardrapporten worden teruggezet op de secundaire

AlwaysOn DMV-rapporten WORDEN NIET GESYNCHRONISEERD op de primaire

Wanneer u een query uitvoert op de volgende AlwaysOn-beschikbaarheidsgroepen (AG's) dynamische beheerweergaven (DMV's) op de primaire, heeft de database de status NIET SYNCHRONISEREN .

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

Wanneer u query's uitvoert op de DMV's op de secundaire database, heeft de database van de beschikbaarheidsgroep de status HERSTELLEN.

Alleen-lezen en rapportageworkloads hebben geen toegang tot de secundaire database

Hoewel de secundaire database wordt teruggedraaid, kan deze niet worden geopend of opgevraagd. Deze alleen-lezenworkloads zijn offline en onderbroken. Afhankelijk van hoe lang de database de status terugzet, kan het nodig zijn om deze workloads om te leiden naar een andere secundaire replica of de primaire replica als deze workloads bedrijfskritiek zijn.

Als u een alleen-lezen workload hebt, zoals een rapportworkload die naar de secundaire replica wordt gerouteerd, kunnen deze batches mislukken met bericht 922:

Msg 922, Niveau 14, Status 1, Regel 2 Database 'agdb' wordt hersteld. Wachten totdat het herstel is voltooid.

Een toepassing die zich probeert aan te melden bij de secundaire replicadatabase, kan geen verbinding maken en genereert fout 18456:

2023-01-26 13:01:13.100 Aanmeldingsfout: 18456, Ernst: 14, Status: 38. 2023-01-26 13:01:13.100 Aanmelding is mislukt voor gebruiker UserName<>. Reden: kan de expliciet opgegeven database agdb niet openen. [CLIENT: <lokale computer>]

Deze fout kan ook worden gerapporteerd in het SQL Server-foutenlogboek als mislukte aanmeldingen worden gecontroleerd.

Een schatting maken van de resterende tijd voor het terugdraaien van de status

Gebruik een van de volgende methoden om een schatting te maken van de resterende tijd voor het terugdraaien van de status:

De AlwaysOn_health XEvent-sessie gebruiken

Het AlwaysOn_health uitgebreide diagnostische logboek voor gebeurtenissen heeft een hadr_trace_message gebeurtenis die elke vijf minuten de statusvoortgang terugdraait.

Maak verbinding met de secundaire replica met behulp van SSMS (SQL Server Management Studio) Objectverkenner en zoom in op beheer, uitgebreide gebeurtenissen en vervolgens sessies. Klik met de rechtermuisknop op de gebeurtenis AlwaysOn_health en selecteer Livegegevens bekijken. U krijgt een nieuw venster met tabbladen dat de huidige status van het terugdraaien van de bewerking rapporteert. De status wordt elke vijf minuten gerapporteerd via de hadr_trace_message gebeurtenis en het voltooide percentage van de terugdraaibewerking wordt gerapporteerd.

Het SQL Server-foutenlogboek op de secundaire replica is niet veel handig bij het schatten van het herstellen van de voltooiing. In de volgende afbeelding kunt u zien van 10:08 tot 11:03 tijdens het terugdraaien van de status, wordt er weinig gerapporteerd. Zodra de secundaire alle pagina's van de primaire replica heeft ontvangen, kan de transactie die wordt uitgevoerd op de oorspronkelijke primaire replica, terugdraaien. Herstel wordt uitgevoerd van 11:03 tot 11:05. Kort nadat het herstel is voltooid, moet de database worden gesynchroniseerd met de primaire replica en alle wijzigingen in de primaire replica bijhouden terwijl de secundaire database de status terugdraaide.

De voltooiingstijd herstellen met behulp van Prestatiemeter

Bewaak de voortgang van de status met behulp van de prestatiemeteritems SQL Server:Database Replica:Total Log Requiring Undo en SQL Server:Database Replica:Log Remaining for Undo en choose the availability group database for the Instance. In het voorbeeld in de volgende schermopname wordt het totaal aantal logboeken waarvoor ongedaan maken is gerapporteerd als 56,3 mb en wordt logboek resterend voor ongedaan maken langzaam teruggezet naar 0 , waardoor de voortgang wordt teruggedraaid.

Wat zijn uw andere opties dan wachten?

Microsoft raadt u aan een schatting te maken van de tijd voor het terugdraaien van de status.

Een secundaire replica toevoegen aan een beschikbaarheidsgroep

Als er slechts twee replica's in de beschikbaarheidsgroep aanwezig zijn, voegt u indien mogelijk nog een secundaire replica toe die hoge beschikbaarheid en redundantie kan bieden en actief kan synchroniseren met de primaire replica terwijl de andere secundaire replica wordt teruggedraaid.

Het oplossen van mislukte werkbelastingen met het kenmerk Alleen-lezen

Omdat de secundaire replicadatabases die worden hersteld, niet toegankelijk zijn, mislukken alleen-lezenworkloads. Werk de routeringstabel voor leesintentie bij om verkeer terug te sturen naar de primaire replica of naar een andere secundaire replica totdat de betrokken secundaire replicadatabase het proces voor terugdraaien voltooit.

Voorkomen dat de status wordt teruggedraaid - controleren op grote transacties

Als u deze status regelmatig ziet tijdens geplande failovers, implementeert u een procedure die controleert op grote transacties voorafgaand aan failovers. De volgende query rapporteert de begintijd van de transactie en de huidige tijd van alle geopende transacties in het systeem en levert de invoerbuffer van de transacties.

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