Diagnostyka dostępności Always On

Diagnostyka dostępności Always On to proces weryfikacji prawidłowego działania mechanizmu wysokiej dostępności bazy danych.

Zakres diagnostyki mechanizmu Always On

Diagnostyka dostępności Always On w Microsoft SQL Server obejmuje sprawdzenie, czy grupa dostępności (Availability Group) prawidłowo utrzymuje kopie baz danych na skonfigurowanych replikach. Analizie podlega zarówno podstawowa dostępność instancji SQL Server, jak i stan klastra Windows Server Failover Clustering, który dostarcza mechanizm quorum oraz uczestniczy w automatycznym przełączaniu awaryjnym. Sama obecność bazy na replice nie oznacza jeszcze, że rozwiązanie jest gotowe do obsługi awarii.

Weryfikacja powinna rozdzielać kilka stanów: dostępność repliki, stan grupy dostępności, stan poszczególnych baz oraz status synchronizacji. Istotne są również role replik, czyli primary i secondary, tryb synchronizacji oraz tryb dostępności. Replika synchroniczna potwierdza zatwierdzenie transakcji po zapisaniu danych na replice pomocniczej, natomiast replika asynchroniczna nie zapewnia takiego samego poziomu aktualności w chwili awarii. Diagnostyka musi więc uwzględniać konfigurację konkretnej grupy, a nie tylko informację, że usługa SQL Server działa.

Sprawdzenie replik, baz i synchronizacji

Jednym z podstawowych elementów kontroli jest porównanie stanów raportowanych dla repliki i dla każdej bazy wchodzącej do grupy dostępności. Replika może być oznaczona jako dostępna, podczas gdy konkretna baza pozostaje w stanie synchronizacji innym niż SYNCHRONIZED albo SYNCHRONIZING. Taka rozbieżność może wskazywać na opóźnienie przesyłania dziennika transakcji, problem z ponownym wykonaniem operacji na replice pomocniczej lub zatrzymanie procesu przesyłania danych.

W SQL Server do odczytu informacji o grupach dostępności wykorzystywane są między innymi widoki dynamicznego zarządzania sys.availability_groups, sys.availability_replicas, sys.dm_hadr_availability_replica_states oraz sys.dm_hadr_database_replica_states. Przy ich interpretacji trzeba rozróżnić stan lokalny, znany bieżącej instancji, od informacji dotyczących innych replik. Przydatne są także wartości opisujące opóźnienie wysyłania i ponownego wykonania dziennika, rozmiar zalegającego dziennika oraz liczbę niezatwierdzonych zmian oczekujących na zastosowanie na replice pomocniczej.

Kontrola obejmuje również endpointy HADR odpowiedzialne za komunikację między replikami. Należy sprawdzić, czy endpoint jest uruchomiony, czy instancje mogą nawiązać połączenie oraz czy konto usługi SQL Server ma wymagane uprawnienia do komunikacji. Błąd endpointu, blokada portu sieciowego albo niezgodność konfiguracji certyfikatów w przypadku używanego uwierzytelniania mogą zatrzymać synchronizację mimo poprawnego działania samej bazy.

Przełączanie awaryjne i warunki utrzymania dostępności

Ważną częścią diagnostyki jest ocena gotowości do przełączenia roli primary na replikę pomocniczą. Automatyczne przełączenie awaryjne wymaga odpowiednio skonfigurowanych trybów dostępności i failover oraz spełnienia warunków dotyczących stanu replik. Replika przeznaczona do automatycznego failover powinna pozostawać w stanie SYNCHRONIZED, a partnerzy muszą prawidłowo komunikować się z mechanizmem klastra. Jeżeli baza jest niesynchronizowana, przełączenie może być niedostępne albo może wiązać się z ryzykiem utraty ostatnich nieprzesłanych zmian.

Sprawdzenie klastra obejmuje stan jego węzłów, zasobów i grupy klastra związanej z SQL Server. Szczególne znaczenie ma quorum, ponieważ jego utrata może doprowadzić do zatrzymania zasobów klastra w celu ochrony przed równoczesnym działaniem kilku stron klastra. Należy również analizować dzienniki zdarzeń systemu Windows, dziennik SQL Server oraz raporty klastra pod kątem utraty komunikacji, restartów usługi, błędów zasobów i nieudanych prób zmiany właściciela zasobu.

Test przełączenia nie powinien ograniczać się do obserwacji zmiany roli repliki. Po kontrolowanym failover trzeba potwierdzić dostęp do baz, poprawność listenera grupy dostępności, rozwiązywanie nazwy w sieci oraz możliwość ustanowienia nowych połączeń przez aplikacje. Weryfikuje się także, czy po powrocie na poprzednią replikę synchronizacja zostaje wznowiona i czy nie pozostają bazy w stanie NOT SYNCHRONIZING, RECOVERY_PENDING albo innym stanie wymagającym dalszej analizy.

Interpretacja objawów i dokumentowanie wyniku

Wynik diagnostyki powinien wskazywać konkretny etap przepływu, na którym pojawia się problem: wykrywanie repliki, komunikacja przez endpoint, przesyłanie dziennika, ponowne wykonywanie zmian, uczestnictwo w quorum albo obsługa połączeń przez listener. Przykładowo rosnące opóźnienie redo oznacza, że zmiany docierają do repliki, lecz są na niej stosowane z opóźnieniem. Inny przypadek występuje wtedy, gdy rośnie zaległość log send, ponieważ problem pojawia się wcześniej, podczas wysyłania dziennika z repliki primary.

Nie należy utożsamiać chwilowego statusu HEALTHY z pełną odpornością rozwiązania. Stan może zmienić się po przeciążeniu dysku, wzroście obciążenia procesora, braku miejsca na woluminie dziennika, przerwie sieciowej lub restarcie jednego z węzłów. Rzetelny zapis powinien zawierać czas obserwacji, nazwę grupy dostępności, role replik, stan baz, tryb synchronizacji, komunikaty błędów oraz rezultat ewentualnego testu przełączenia. Dopiero zestawienie tych informacji pozwala odróżnić usterkę konfiguracji od przejściowego opóźnienia.

Diagnostyka dostępności Always On dotyczy infrastruktury klasy serwerowej i administracji Microsoft SQL Server, dlatego jej wynik powinien pozostać opisem stanu technicznego, przyczyny oraz ryzyka dla ciągłości działania. W przypadku środowisk, w których wymagane są dalsze działania, zakres prac określa się na podstawie potwierdzonych objawów: od korekty komunikacji i konfiguracji repliki po analizę klastra, dzienników transakcji i zachowania aplikacji po zmianie roli.