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

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

Wat is de status herstellen?

De status herstellen treedt op wanneer de secundaire server wijzigingen ongedaan moet maken die al zijn toegepast om weer gesynchroniseerd te kunnen worden 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 tussen de primaire replica en de secundaire replica(s) hersteld. Tijdens deze eerste verbonden status wordt onderhandeld over een gemeenschappelijk herstelpunt waarin de nieuwe secundaire het herstel moet starten, zodat deze gesynchroniseerd is met de primaire.

Als er een grote transactie wordt uitgevoerd op het moment van de failover, ligt het nieuwe secundaire databaselogboek voor op de primaire replicadatabase. Voor het nieuwe algemene herstelpunt waarover is onderhandeld, moet de secundaire replica pagina's van de primaire replica ontvangen om de synchronisatie te kunnen hervatten. Het herstelproces wordt ook wel 'Opnieuw ongedaan maken' genoemd.

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

Symptomen en effect van een beschikbaarheidsgroepsdatabase in terugdraaiende status

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

AlwaysOn-dashboardrapporten worden niet gesynchroniseerd op de primaire

Na een failover van een beschikbaarheidsgroep ziet u mogelijk dat de secundaire groep niet wordt gesynchroniseerd terwijl de failover is geslaagd. Het dashboard AlwaysOn meldt niet synchroniseren op de primaire en Terugdraaien op de secundaire.

AlwaysOn-dashboardrapporten worden niet gesynchroniseerd op de primaire	AlwaysOn-dashboard meldt terugdraaien op de secundaire

AlwaysOn DMV's rapporteert NIET SYNCHRONISEREN 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 een query uitvoert op de DMV's op de secundaire, heeft de database van de beschikbaarheidsgroep de status HERSTELLEN .

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

Terwijl de secundaire database wordt hersteld, kan deze niet worden geopend of opgevraagd. Deze alleen-lezen werkbelastingen zijn offline en onderbroken. Afhankelijk van hoe lang de database zich in de herstelstatus bevindt, kan het nodig zijn om deze workloads om te leiden naar een andere secundaire replica of de primaire replica als deze werkbelastingen bedrijfskritiek zijn.

Als u een alleen-lezen workload hebt, zoals een rapportageworkload die wordt doorgestuurd naar de secundaire replica, 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 met de status Herstellen, 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 '<Gebruikersnaam>'. 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.

Schatting maken van de resterende tijd in de terugdraaistatus

Gebruik een van de volgende methoden om de resterende tijd in de terugdraaistatus te schatten:

De AlwaysOn_health XEvent-sessie gebruiken

Het uitgebreide diagnostische gebeurtenislogboek van AlwaysOn_health bevat een hadr_trace_message gebeurtenis die elke vijf minuten de voortgang van het herstellen van de status rapporteert.

Maak verbinding met de secundaire replica met behulp van SQL Server Management Studio (SSMS) 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 met de huidige status van de bewerking voor terugdraaien. De status wordt elke vijf minuten gerapporteerd via de hadr_trace_message gebeurtenis en het voltooide percentage van de herstelbewerking wordt gerapporteerd.

Opmerking

De uitgebreide gebeurtenis hadr_trace_message is toegevoegd aan de meest recente cumulatieve updates in SQL Server 2019 en hoger. U moet de meest recente cumulatieve updates uitvoeren om deze uitgebreide gebeurtenis in de AlwaysOn_health uitgebreide gebeurtenissessie te kunnen bekijken.

Het SQL Server foutenlogboek op de secundaire replica is niet veel hulp bij het schatten van het terugdraaien van de voltooiing. In de volgende afbeelding kunt u zien van 10:08 tot 11:03 , terwijl in de terugdraaistatus weinig wordt gerapporteerd. Zodra de secundaire alle pagina's van de primaire replica heeft ontvangen, kan deze nu de transactie terugdraaien die werd uitgevoerd op de oorspronkelijke primaire die het terugdraaien van de status heeft geactiveerd. Herstel wordt uitgevoerd van 11:03 tot 11:05. Kort nadat het herstel is voltooid, moet de database beginnen te synchroniseren met de primaire replica en alle wijzigingen in de primaire database inhalen terwijl de secundaire database de status herstelt.

Voltooiingstijd controleren met prestatiemeter

Bewaak de voortgang van het herstellen van de status met behulp van de prestatiemeteritems SQL Server:D atabase Replica:Total Log Waarvoor ongedaan maken is vereist en SQL Server:D atabase Replica:Log Remaining for Undo en kies de database van de beschikbaarheidsgroep voor het exemplaar. In het voorbeeld in de volgende schermopname wordt Het totaal aantal logboeken waarvoor ongedaan maken is vereist, gerapporteerd als 56,3 mb en wordt Log Remaining for Undo langzaam teruggezet naar 0 die de voortgang van het herstellen rapporteert.

Wat zijn uw andere opties dan wachten?

Microsoft raadt u aan een schatting te maken van de tijd voor het voltooien van de terugdraaistatus.

Een secundaire replica toevoegen aan een beschikbaarheidsgroep

Als de beschikbaarheidsgroep slechts twee replica's bevat, 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.

Belangrijk

Voer geen failover uit naar een replica waarvan de database(s) de status Herstellen heeft. Dit kan resulteren in een onbruikbare database waarvoor een back-up moet worden hersteld. Start het secundaire replica-exemplaar niet opnieuw op, dit versnelt dit proces niet en kan de status van de secundaire replicadatabase die zich in de herstelstatus bevindt, in gevaar komen.

Mislukte alleen-lezenwerkbelastingen oplossen

Omdat de secundaire replicadatabases die worden teruggezet, niet toegankelijk zijn, mislukken alleen-lezenwerkbelastingen. Werk de routeringstabel voor leesintentie bij om verkeer terug te leiden naar de primaire replica of naar een andere secundaire replica totdat de betrokken secundaire replicadatabase het herstelproces heeft voltooid.

Voorkomen dat de status wordt hersteld : bewaken voor grote transacties

Als u deze status regelmatig ziet tijdens geplande failovers, implementeert u een procedure waarmee vóór failovers wordt gecontroleerd op grote transacties. De volgende query rapporteert de begintijd van de transactie en de huidige tijd van alle geopende transacties op het systeem en biedt 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