Rozproszona dostępność SQL Server Grupowe bazy danych nie synchronizują się po ponownym uruchomieniu serwera

Przygotowujemy się do przeprowadzenia dużej aktualizacji na naszych serwerach SQL i zauważamy nietypowe zachowanie w Grupach dostępności rozproszonej, które próbuję rozwiązać przed przejściem do przodu.

W zeszłym miesiącu zaktualizowałem zdalny serwer pomocniczy z SQL Server 2016 do SQL Server 2017. Serwer ten jest częścią wielu grup dostępności rozproszonej (DAG) i oddzielnej grupy dostępności (AG) . Kiedy zaktualizowaliśmy ten serwer, nie byliśmy świadomi, że stanie się on nieczytelny , więc w ciągu ostatniego miesiąca polegaliśmy wyłącznie na serwerze głównym.

W ramach nadchodzącej aktualizacji zastosowałem łatkę CU 4 na serwerze i zrestartowałem ją. Kiedy serwer wrócił do trybu online, właśnie łatane oprogramowanie dodatkowe pokazało, że wszystkie DAG / AG synchronizują się bez żadnych problemów.

Jednak głównym było pokazanie zupełnie innej historii. Zgłaszało to

• oddzielna AG synchronizowała się bez żadnych problemów
• ale DAG były w nie Synchronzing / nie jest zdrowe państwo

Po początkowej panice próbowałem następujących rzeczy, aby ponownie zsynchronizować rzeczy w DAG:

• Od podstawowego zatrzymałem i wznowiłem przepływ danych. Nie rozpoczęło się synchronizowanie danych.
• Na drugim (tym, który właśnie załatałem) uruchomiłem ALTER DATABASE [<database] SET HADR RESUME;- które działają bez błędów, ale nie wznowiły żadnej synchronizacji

Moją ostatnią próbą ponownej synchronizacji danych było zalogowanie się do pomocniczego i ręczne zrestartowanie usługi SQL Server. Ręczne ponowne uruchomienie usługi wydaje się nieco ekstremalne, ponieważ oczekiwałbym, że ponowne uruchomienie serwera byłoby wystarczające.

Czy ktoś napotkał ten problem polegający na tym, że DAG nie zaczyna synchronizować się z urządzeniem pomocniczym po ponownym uruchomieniu? Jeśli tak, to jak to rozwiązać?

Sprawdziłem zarówno dziennik błędów programu SQL Server, jak i przeglądarkę zdarzeń na serwerze pomocniczym, nic nie widziałem.

Uwaga: nie jest to ostateczna odpowiedź, ale najlepsza odpowiedź po rozmowie z Taryn .

Jednak głównym było pokazanie zupełnie innej historii. Zgłaszano, że oddzielna AG synchronizowała się bez żadnych problemów, ale DAG były w stanie Niezsynchronizowanym / Niezdrowym

Jeśli poszczególne bazy danych i AG leżące u podstaw rozproszonego ag twierdzą, że są zdrowe i synchronizowane, istnieje duża szansa, że ​​jest to tylko czkawka pulpitów nawigacyjnych DMV i / lub SSMS. Ponieważ w dzienniku błędów nie było niczego, co sugerowałoby, że replika nie łączy się lub jest w stanie rozłączonym.

Niestety, odkąd problem został rozwiązany, trudno jest powiedzieć dokładnie, co to było ... ale w przyszłości, jeśli zdarzy się to komuś:

• Sprawdź sys.dm_hadr_database_replica_states we wszystkich klastrach szukających czegokolwiek, co nie jest zdrowe. Jeśli wszystko pokazuje się dobrze, możliwe, że DMV jeszcze się nie zaktualizował
• Jeśli to niezdrowe, sprawdź dziennik błędów / DMV pod kątem problemów z łącznością (takich jak niemożność połączenia się z usługą przesyłania dalej / globalną podstawową)
• Odpowiedź Dana wymienia problemy, które mogą wyniknąć z uruchomienia bazy danych - choć w tym przypadku nie można odczytać instancji, więc najprawdopodobniej nie był to problem, ale mógł być w twoim przypadku
• Jeśli baza danych jest czytelna, wykonaj test dymu za pomocą ślepej tabeli / wkładki lub ...
• Rozszerzona sesja zdarzeń z wykorzystaniem elementów kanału DEBUG sqlserver.hadr_dump_log_blocklub w sqlserver.hadr_apply_log_blockcelu sprawdzenia, czy serwer dodatkowy faktycznie odbiera / stosuje bloki dziennika lub ...
• Obiekt Perfmon SQLServer:Database Replica\Log Bytes Received/sec

Jeśli otrzymujesz dane na tym drugim serwerze, ale rozproszony ag nadal pokazuje, że nie synchronizuje się lub nie jest w dobrej kondycji, pozwolę mu odejść na chwilę, aby zobaczyć, czy wartości DMV się zmieniają, ponieważ oczywiście odbiera i przetwarza bloki dziennika.

Jeśli jednak tak nie będzie, będziemy musieli zbadać dalej, co jest poza zakresem odpowiedzi.

Powiem to wszystko z zastrzeżeniem, że nie mam żadnych DAG w produkcji. Zasadniczo jednak ta rada powinna mieć zastosowanie zarówno do AG, jak i DAG.

Czy synchronizacja została wznowiona po ponownym uruchomieniu usługi? Jeśli tak, to moje najlepsze przypuszczenie, że przyczyną będzie blokowanie ponownej SPID. Jeśli nadal nie synchronizuje się nawet po ponownym uruchomieniu, oto, co najpierw sprawdzę:

Blokowanie AG redo SPID

Zasadniczo występuje tylko na czytelnym urządzeniu wtórnym. Aby to sprawdzić, uruchom następujące polecenie:

select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'

Jeśli pojawią się jakiekolwiek blokujące identyfikatory SPID, musisz je zabić, zanim będzie można wznowić pomocnicze (identyfikator DB STARTUPSPID obsługuje operacje ponawiania). Sugerowałbym wcześniej przejrzeć blokujący SPID, aby spróbować ustalić przyczynę (zwykle długotrwały raport).

Jeśli chcesz więcej informacji na ten temat, jest to świetny artykuł (w tym monitoringu dla tego typu zachowań, używając XES) tutaj .

Sprawdź DMV

Jeśli przenoszenie danych jest zawieszone, możesz odwołać się do DMV, aby uzyskać więcej informacji na temat przyczyny zawieszenia. Uruchom następujące czynności:

select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states

W artykule BOL nieco dalej opisano przyczynę zawieszenia.

Czy Twoja rozproszona grupa dostępności (DAG) jest podzielona na różne regiony? Jeśli tak, możesz cierpieć z powodu zbyt niskiej domyślnej wartości SESSION_TIMEOUT (10 sekund). Oznacza to, że opóźnienie między tymi dwoma regionami jest zbyt duże, aby niezawodnie zakończyć synchronizację.

Normalnej grupie dostępności można zwiększyć wartość SESSION_TIMEOUT, aby sesje synchronizacji były bardziej stabilne. Zauważyłem pod koniec ubiegłego roku, że nie można edytować parametru SESSION_TIMEOUT DAG. Oznaczało to, że DAG były wykonalne tylko w przypadku scenariuszy o niskim opóźnieniu. Zalogowaliśmy bilet w firmie Microsoft i na początku tego roku wydano poprawkę.

Ulepszenie: Skonfiguruj wartość SESSION_TIMEOUT dla repliki grupy rozproszonej dostępności w SQL Server 2016 i 2017