Rozwiązywanie problemów z bazą danych grupy dostępności w stanie przywracania

Ten artykuł ułatwia rozwiązywanie problemów z bazą danych grupy dostępności w stanie przywracania.

Co to jest stan przywracania?

Przywracanie stanu występuje, gdy serwer pomocniczy musi cofnąć zmiany, które zostały już zastosowane, aby wrócić do synchronizacji z serwerem podstawowym.

Repliki podstawowe i pomocnicze grupy dostępności pozostają w stanie połączonym podczas normalnego działania, dzięki czemu zmiany w repliki podstawowej są aktywnie synchronizowane z replikami pomocniczymi.

Podczas pracy w trybie failover ten stan połączenia jest przerywany. Po przejściu nowej repliki podstawowej do trybu online łączność zostanie ponownie nawiązana między repliką podstawową a replikami pomocniczymi. Podczas tego początkowego połączonego stanu negocjowany jest wspólny punkt odzyskiwania, w którym nowy pomocniczy powinien rozpocząć odzyskiwanie, aby był zsynchronizowany z podstawowym.

Jeśli duża transakcja jest uruchomiona w momencie przejścia w tryb failover, nowy pomocniczy dziennik bazy danych jest przed podstawową bazą danych repliki. Nowy wspólny wynegocjowany punkt odzyskiwania będzie wymagał repliki pomocniczej odbierania stron z repliki podstawowej, aby była w stanie, w którym można wznowić synchronizację. Proces przywracania jest również nazywany "Cofnij ponowne".

Proces przywracania jest z natury powolny, często występuje, a zazwyczaj małe transakcje wyzwalające stan przywracania nie są zauważane. Stan przywracania jest często zauważany, gdy tryb failover przerywa dużą transakcję, powodując wysłanie wielu stron z podstawowej do pomocniczej bazy danych w celu przywrócenia pomocniczej bazy danych repliki do stanu możliwego do odzyskania.

Objawy i efekt bazy danych grupy dostępności w stanie przywracania

Gdy baza danych jest w stanie przywracania repliki pomocniczej, baza danych nie jest synchronizowana i dlatego nie otrzymuje zmian z repliki podstawowej. Nagła utrata bazy danych w repliki podstawowej może spowodować utratę danych.

Zawsze włączone raporty pulpitu nawigacyjnego Nie są synchronizowane z elementem podstawowym

Po przejściu w tryb failover do grupy dostępności można zauważyć, że pomocnicza jest zgłaszana jako niezrównoważona, gdy przejście w tryb failover zakończyło się pomyślnie. Pulpit nawigacyjny Always On zgłasza, że synchronizacja nie jest synchronizowana z elementem podstawowym i przywracana w pomocniczej wersji.

Zawsze włączone raporty pulpitu nawigacyjnego Nie są synchronizowane z elementem podstawowym	Zawsze włączone raporty pulpitu nawigacyjnego Przywracane w pomocniczej wersji

Zawsze włączone dynamiczne widoki zarządzania nie są synchronizowane z podstawowymi widokami ZARZĄDZANIA

W przypadku wykonywania zapytań dotyczących następujących dynamicznych widoków zarządzania (DMV) zawsze włączonych grup dostępności (DMV) w podstawowej bazie danych nie jest synchronizowana .

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

Podczas wykonywania zapytań dotyczących widoków DMV w pomocniczej bazie danych grupy dostępności jest w stanie PRZYWRACANIA .

Nie można uzyskać dostępu do pomocniczej bazy danych tylko do odczytu i obciążeń raportowania

Podczas przywracania pomocniczej bazy danych nie można uzyskać do niej dostępu ani wykonywać zapytań. Te obciążenia tylko do odczytu są w trybie offline i przerywane. W zależności od tego, jak długo baza danych jest w stanie przywracania, może być konieczne przekierowanie tych obciążeń do innej repliki pomocniczej lub repliki podstawowej, jeśli te obciążenia mają krytyczne znaczenie dla działania firmy.

Jeśli masz obciążenie tylko do odczytu, takie jak obciążenie raportowania kierowane do repliki pomocniczej, te partie mogą zakończyć się niepowodzeniem z komunikatem 922:

Msg 922, Level 14, State 1, Line 2 Database "agdb" jest odzyskiwany. Oczekiwanie na zakończenie odzyskiwania.

Aplikacja próbująca zalogować się do pomocniczej bazy danych repliki w stanie przywracania nie może nawiązać połączenia i zgłasza błąd 18456:

2023-01-26 13:01:13.100 Błąd logowania: 18456, Ważność: 14, Stan: 38. 2023-01-26 13:01:13.100 Logowanie nie powiodło się dla użytkownika "<UserName>". Przyczyna: Nie można otworzyć jawnie określonej bazy danych "agdb". [KLIENT: <maszyna lokalna>]

Ten błąd można również zgłosić w dzienniku błędów programu SQL Server, jeśli logowanie nie powiodło się.

Szacowanie czasu pozostałego w stanie przywracania

Użyj jednej z następujących metod, aby oszacować pozostały czas w stanie przywracania:

Korzystanie z sesji AlwaysOn_health XEvent

Rozszerzony dziennik diagnostyczny zdarzeń AlwaysOn_health zawiera zdarzenie hadr_trace_message , które zgłasza postęp przywracania stanu co pięć minut.

Połącz się z repliką pomocniczą przy użyciu programu SQL Server Management Studio (SSMS) Eksplorator obiektów i przejdź do szczegółów zarządzania, zdarzeń rozszerzonych, a następnie sesji. Kliknij prawym przyciskiem myszy zdarzenie AlwaysOn_health i wybierz pozycję Obejrzyj dane na żywo. Powinno zostać wyświetlone nowe okno z kartami, które zgłasza bieżący stan operacji przywracania. Stan jest zgłaszany co pięć minut za pośrednictwem hadr_trace_message zdarzenia, a ukończony procent operacji przywracania jest zgłaszany.

Uwaga 16.

Zdarzenie hadr_trace_message rozszerzone zostało dodane do najnowszych aktualizacji zbiorczych w programie SQL Server 2019 i nowszych wersjach. Aby obserwować to zdarzenie rozszerzone w rozszerzonej AlwaysOn_health sesji zdarzeń, należy uruchomić najnowsze aktualizacje zbiorcze.

Dziennik błędów programu SQL Server w replice pomocniczej nie jest bardzo pomocny podczas szacowania zakończenia przywracania. Na poniższej ilustracji można obserwować od 10:08 do 11:03 w stanie przywracania, niewiele jest zgłaszane. Gdy pomocnicza otrzyma wszystkie strony z repliki podstawowej, będzie teraz w stanie wycofać transakcję uruchomioną na oryginalnym podstawowym, który wyzwolił stan przywracania. Odzyskiwanie jest uruchamiane od 11:03 do 11:05. Wkrótce po zakończeniu odzyskiwania baza danych powinna rozpocząć synchronizację z repliką podstawową i nadrobić zaległości we wszystkich zmianach wprowadzonych w podstawowej bazie danych, gdy pomocnicza baza danych była w stanie przywracania.

Monitorowanie przywracania czasu ukończenia przy użyciu monitor wydajności

Monitoruj postęp przywracania stanu przy użyciu liczników wydajności SQL Server:Database Replica:Total Log Wymaga cofnij i SQL Server:Database Replica:Log Remaining for Undo i wybierz bazę danych grupy dostępności dla wystąpienia. W przykładzie na poniższym zrzucie ekranu łączna liczba operacji cofania w dzienniku jest zgłaszana jako 56,3 mb, a pozostały dziennik dla cofania jest powoli spada do 0, który zgłasza postęp przywracania.

Jakie są inne opcje niż oczekiwanie?

Firma Microsoft zaleca oszacowanie czasu zakończenia przywracania stanu.

Dodawanie repliki pomocniczej do grupy dostępności

Jeśli istnieją tylko dwie repliki w grupie dostępności, jeśli to możliwe, dodaj kolejną replikę pomocniczą, która może zapewnić wysoką dostępność i nadmiarowość i aktywnie zsynchronizować z repliką podstawową, podczas gdy inne pomocnicze kończy przywracanie.

Ważne

Nie należy przełączania w tryb failover do repliki, której bazy danych są w stanie przywracania. Może to spowodować bezużyteczną bazę danych, która wymaga przywrócenia z kopii zapasowej. Nie uruchamiaj ponownie wystąpienia repliki pomocniczej, nie przyspieszy tego procesu i może naruszyć stan pomocniczej bazy danych repliki, która jest w stanie przywracania.

Jak rozwiązać problem z nieudanymi obciążeniami tylko do odczytu

Ponieważ pomocnicze bazy danych repliki w przywracaniu są niedostępne, obciążenia tylko do odczytu kończą się niepowodzeniem. Zaktualizuj tabelę routingu intencji odczytu, aby skierować ruch z powrotem do repliki podstawowej lub do innej repliki pomocniczej do momentu zakończenia procesu przywracania bazy danych repliki pomocniczej, której dotyczy problem.

Unikaj przywracania stanu — monitorowanie dużych transakcji

Jeśli ten stan jest często obserwowany podczas planowanych przełączeń w tryb failover, zaimplementuj procedurę sprawdzającą duże transakcje przed przejściem w tryb failover. Poniższe zapytanie zgłasza czas rozpoczęcia transakcji i bieżącą godzinę otwarcia transakcji w systemie i udostępnia bufor wejściowy transakcji.

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