Widok sys.dm_hadr_cluster

sys.dm_hadr_cluster zwraca informacje o klastrze wykorzystywanym przez grupy dostępności Always On.

Miejsce widoku w architekturze Always On

sys.dm_hadr_cluster jest dynamicznym widokiem zarządzania dostępnym w Microsoft SQL Server i służy do odczytu informacji o środowisku koordynującym pracę grup dostępności Always On. Nie przedstawia on danych użytkowników ani zawartości baz, lecz opisuje stan warstwy, która uczestniczy w utrzymaniu wysokiej dostępności instancji. W klasycznym wdrożeniu SQL Server ta warstwa jest związana z usługą Windows Server Failover Clustering, natomiast w innych obsługiwanych modelach wdrożeniowych sposób koordynacji może zależeć od platformy i wybranego typu grupy dostępności.

Widok jest przydatny dlatego, że pozwala oddzielić problemy samej bazy od problemów środowiska wysokiej dostępności. Jeżeli zapytania do bazy działają poprawnie, ale występują przełączenia ról, brak automatycznego failoveru albo ostrzeżenia dotyczące kworum, warto sprawdzić zarówno stan replik, jak i informacje udostępniane przez sys.dm_hadr_cluster. Wynik należy interpretować razem z innymi widokami Always On, ponieważ pojedynczy rekord nie opisuje pełnej topologii replik ani kondycji każdej bazy.

Wśród informacji zwracanych przez ten widok znajdują się dane identyfikujące środowisko oraz stan kworum. W zależności od wersji SQL Server i modelu wdrożenia można spotkać kolumny opisujące nazwę środowiska, rodzaj kworum, stan kworum oraz odpowiadające im wartości tekstowe. Nazwy i dostępność poszczególnych kolumn trzeba potwierdzić w dokumentacji wersji używanej instancji, ponieważ widoki systemowe mogą rozszerzać się między wydaniami produktu.

Kworum jest mechanizmem podejmowania decyzji, czy wystarczająca część uczestników środowiska może uznać je za działające. Jego stan ma znaczenie dla bezpiecznego utrzymania ról i automatycznego przełączania. Sam fakt, że instancja SQL Server odpowiada na zapytania, nie oznacza jeszcze, że warunki do automatycznego przejęcia roli są spełnione. Dlatego odczyt z tego widoku może wyjaśnić, dlaczego grupa dostępności działa w trybie ograniczonym mimo poprawnej pracy lokalnej instancji.

Jak czytać wynik i z czym go zestawiać

Najprostsza diagnostyka polega na wykonaniu zapytania odczytującego wszystkie kolumny widoku, na przykład przez SELECT * FROM sys.dm_hadr_cluster;. W środowisku produkcyjnym lepiej jawnie wymienić interesujące kolumny po sprawdzeniu ich definicji dla konkretnej wersji SQL Server. Dzięki temu skrypt nie przestanie działać po zmianie zakresu widoku, a dokumentacja incydentu będzie czytelniejsza. Odczyt DMV nie zmienia konfiguracji i zwykle może być traktowany jako czynność obserwacyjna.

Informacje o środowisku należy porównywać z widokiem sys.dm_hadr_availability_group_states, który pokazuje stan grup dostępności, oraz z sys.dm_hadr_availability_replica_states, opisującym stan replik. Dla przepływu danych między replikami istotny jest także sys.dm_hadr_database_replica_states. Taki zestaw pozwala ustalić, czy źródłem problemu jest warstwa kworum, niedostępna replika, zatrzymany ruch danych, opóźnienie synchronizacji czy stan konkretnej bazy.

Wynik z sys.dm_hadr_cluster nie jest listą wszystkich węzłów ani raportem o stanie każdej repliki. Nie zastępuje również dzienników SQL Server, dzienników systemowych ani narzędzi administracyjnych platformy. Jego zadaniem jest dostarczenie punktu widzenia instancji SQL Server na podstawowe właściwości środowiska koordynującego. Jeżeli potrzebna jest analiza przyczyn utraty kworum, sam odczyt DMV może wskazać objaw, lecz nie musi ujawnić zdarzenia, które go wywołało.

Warto też rozróżnić konfigurację grupy dostępności od bieżącego stanu. Nazwa środowiska, rodzaj kworum lub typ koordynacji opisują model działania, natomiast stan kworum informuje o aktualnej ocenie dostępności uczestników. Prawidłowa konfiguracja nie gwarantuje prawidłowego stanu w chwili awarii sieci, zatrzymania usługi lub utraty komunikacji między instancjami. Diagnostyka powinna więc obejmować co najmniej dwa momenty: czas wystąpienia problemu oraz stan po jego ustąpieniu.

Widok może być używany w skryptach monitorujących, ale alarm powinien uwzględniać kontekst. Chwilowa zmiana stanu podczas kontrolowanego restartu nie ma takiego znaczenia jak powtarzające się przejścia do stanu nieprawidłowego połączone z rozłączeniami replik. Dobrze zaprojektowany monitoring zapisuje czas odczytu, nazwę instancji, rezultat zapytań dotyczących grup i replik oraz komunikaty z dzienników. Bez tych danych późniejsze odtworzenie przebiegu zdarzeń jest trudniejsze.

Co może oznaczać nieoczekiwany rezultat

Brak oczekiwanego wiersza albo błąd podczas odczytu nie musi oznaczać uszkodzenia SQL Server. Przyczyną może być użycie wersji produktu, która nie udostępnia danej kolumny, połączenie z inną instancją niż zakładana, brak funkcji Always On w danej edycji lub ograniczenie uprawnień użytkownika. Zanim wynik zostanie uznany za dowód awarii, należy potwierdzić nazwę instancji, wersję SQL Server, bazę kontekstu oraz konto wykonujące zapytanie.

Nieprawidłowy stan kworum może wiązać się z utratą komunikacji, niedostępnością uczestnika, problemem z usługą koordynującą albo nieplanowaną zmianą konfiguracji. Z punktu widzenia SQL Server może to skutkować brakiem automatycznego przełączenia, zatrzymaniem określonych operacji związanych z rolą lub koniecznością ręcznej interwencji administratora. Nie należy jednak wyciągać wniosku, że każda wartość ostrzegawcza oznacza utratę danych. Ochrona danych zależy między innymi od trybu synchronizacji, potwierdzenia zapisów i aktualnego stanu baz na replikach.

Częstym błędem diagnostycznym jest sprawdzanie wyłącznie nazwy środowiska i pomijanie stanu replik. Sama obecność prawidłowej nazwy nie potwierdza, że wszystkie instancje widzą się wzajemnie ani że bazy są zsynchronizowane. Innym błędem jest traktowanie statusu grupy jako statusu pojedynczej bazy. Grupa może być dostępna, gdy jedna z baz ma problem z synchronizacją, odzyskiwaniem albo stanem lokalnym.

Wątpliwości może budzić także różnica między stanem odczytanym obecnie a komunikatem zapisanym wcześniej w dzienniku. DMV pokazuje stan bieżący, a nie pełną historię. Po przywróceniu komunikacji wynik może wyglądać poprawnie, mimo że wcześniej doszło do przerwy lub przełączenia. Do analizy incydentu trzeba zatem zachować logi, znaczniki czasu i informacje o wykonanych działaniach administracyjnych.

Wersja SQL Server ma znaczenie również przy przenoszeniu skryptów między środowiskami. Zapytanie odwołujące się do kolumny dostępnej w nowszym wydaniu może zakończyć się błędem na starszej instancji. Bezpiecznym podejściem jest sprawdzenie metadanych widoku i napisanie zapytania pod konkretną wersję, zamiast zakładania, że wszystkie instalacje mają identyczny zestaw pól.

Granica między odczytem diagnostycznym a interwencją

Samodzielny odczyt sys.dm_hadr_cluster jest rozsądnym pierwszym krokiem, gdy potrzebna jest szybka ocena stanu środowiska Always On. Jeżeli wynik wskazuje problem, dalsze działania powinny wykonywać osoby odpowiedzialne za administrację SQL Server i infrastrukturę, ponieważ zmiana trybu pracy, ról lub ustawień failover może wpłynąć na dostępność baz. Przed interwencją należy zebrać wyniki powiązanych DMV, komunikaty z dzienników oraz informacje o ostatnich zmianach.

Wsparcie specjalisty jest szczególnie potrzebne, gdy stan kworum zmienia się cyklicznie, przełączenia następują bez planowanej konserwacji, replika pozostaje niedostępna albo aplikacje zgłaszają błędy połączeń mimo pozornie poprawnego stanu grupy. W takich sytuacjach trzeba prześledzić zależności między SQL Server, systemem operacyjnym, komunikacją sieciową, nazwami usług i konfiguracją aplikacji. Pojedyncze zapytanie do DMV może rozpocząć analizę, ale nie zastąpi pełnej weryfikacji środowiska.

Warto również zachować ostrożność przy zgłoszeniach dotyczących laptopa lub komputera, z którego wykonywana jest administracja. Jeżeli problem polega na zawieszaniu się systemu, błędach dysku, uszkodzeniu pamięci, problemach z zasilaniem albo niestabilnym działaniu aplikacji narzędziowej, Warszawskie Pogotowie Komputerowe może zająć się fizyczną naprawą laptopa, komputera stacjonarnego lub jego podzespołów, a także podstawowym odzyskiem danych z uszkodzonego nośnika.

Przed przekazaniem sprzętu do diagnostyki warto zanotować komunikaty, godziny wystąpienia problemu i zakres utraconej funkcjonalności. Nie należy usuwać logów ani wielokrotnie restartować urządzenia, jeżeli podejrzewana jest awaria nośnika. Rozdzielenie awarii sprzętu używanego do administracji od problemu samego SQL Server pozwala szybciej ustalić, czy źródło zakłóceń znajduje się w komputerze klienta, połączeniu, czy w środowisku bazodanowym.