Alerty Always On

Alerty Always On to powiadomienia dotyczące stanu grup dostępności w konfiguracji wysokiej dostępności serwera SQL.

Rola alertów w grupach dostępności Always On

Alerty Always On dotyczą monitorowania stanu grup dostępności w funkcji Always On Availability Groups dostępnej w Microsoft SQL Server. Grupa dostępności łączy jedną replikę podstawową z jedną lub większą liczbą replik pomocniczych. Repliki mogą pracować w trybie synchronicznego albo asynchronicznego zatwierdzania danych, a ich stan wpływa na możliwość wykonywania odczytów, przełączania ról i utrzymania ochrony danych. Alert nie jest samą repliką ani mechanizmem replikacji. Jest informacją o wykrytym stanie, zdarzeniu lub pogorszeniu warunków pracy konfiguracji.

Źródłem informacji o stanie są między innymi widoki dynamicznego zarządzania Always On, komunikaty silnika SQL Server, dziennik błędów, sesje Extended Events oraz dashboard Always On Availability Groups w SQL Server Management Studio. W zależności od konfiguracji można obserwować stan synchronizacji, rolę repliki, dostępność bazy, opóźnienie przesyłania logu transakcyjnego i opóźnienie odtwarzania logu na replice pomocniczej. Samo pojawienie się ostrzeżenia nie zawsze oznacza utratę danych, ale wskazuje, że należy sprawdzić przyczynę i zakres wpływu na grupę dostępności.

Jakie stany mogą wywołać ostrzeżenie

Jednym z podstawowych sygnałów jest przejście bazy dostępności ze stanu SYNCHRONIZED do SYNCHRONIZING, NOT SYNCHRONIZING albo NOT SYNCHRONIZING, SUSPENDED. Stan SYNCHRONIZING oznacza, że replika pomocnicza nadal otrzymuje i odtwarza rekordy dziennika, lecz nie osiągnęła pełnej synchronizacji. Stan zawieszenia może mieć związek między innymi z problemem przesyłania danych, błędem odtwarzania logu, brakiem miejsca albo ręcznym zawieszeniem ruchu danych. Weryfikacja powinna obejmować zarówno stan bazy na replice podstawowej, jak i stan odpowiadającej jej kopii na replice pomocniczej.

Alert może również wskazywać brak połączenia między replikami, zmianę roli po przełączeniu awaryjnym, niedostępność punktu końcowego mirroringu bazy danych albo niezgodność konfiguracji między węzłami. W Always On punkt końcowy służy do komunikacji między replikami; jego działanie zależy od dostępności instancji SQL Server, poprawnego adresu endpointu, portu oraz uprawnień używanych przez konta usług. Jeżeli replika nie może przesyłać logu, rosną opóźnienia i może zwiększać się ilość danych oczekujących na wysłanie lub odtworzenie. Takie zjawisko należy odróżnić od zwykłego, krótkotrwałego wzrostu obciążenia.

Odczyt informacji diagnostycznych

Podczas analizy alertu należy zapisać czas jego wystąpienia, nazwę grupy dostępności, replikę, bazę oraz aktualną rolę. Następnie trzeba porównać stan odczytany z monitoringu ze stanem widocznym w SQL Server Management Studio i w widokach dynamicznego zarządzania. Przydatne są między innymi sys.dm_hadr_database_replica_states, sys.dm_hadr_availability_replica_states, sys.availability_groups oraz sys.availability_replicas. Widoki te pozwalają zestawić stan synchronizacji bazy, stan repliki i właściwości grupy. Warto sprawdzić także sys.dm_hadr_database_replica_cluster_states, jeżeli problem dotyczy relacji z klastrem.

Znaczenie ma rozdzielenie opóźnienia wysyłania logu od opóźnienia jego odtwarzania. Jeżeli log nie dociera do repliki pomocniczej, trzeba zbadać komunikację i obciążenie instancji podstawowej. Jeżeli log dociera, lecz nie jest szybko odtwarzany, przyczyną może być obciążenie dysków, blokowanie, duża liczba zmian albo ograniczona wydajność instancji pomocniczej. W trybie synchronicznym dodatkowe opóźnienia mogą wpływać na czas zatwierdzania transakcji na replice podstawowej. W trybie asynchronicznym aplikacja może działać dalej, ale zwiększa się różnica między stanem podstawowym a pomocniczym.

Reakcja na alert i przywrócenie synchronizacji

Nie należy kasować alertu bez ustalenia, czy stan powrócił do normy. Najpierw trzeba ustalić, czy problem jest przejściowy, czy utrzymuje się przez kolejne cykle monitorowania. Analiza obejmuje dzienniki SQL Server i systemu Windows, stan usługi SQL Server, dostępność klastra, stan endpointu oraz wolne miejsce na woluminach zawierających pliki danych i logów. Jeżeli baza ma stan SUSPENDED, należy sprawdzić komunikat opisujący powód zawieszenia, ponieważ wznowienie ruchu danych bez usunięcia przyczyny może spowodować ponowne zawieszenie albo dalsze narastanie zaległości.

Po usunięciu przyczyny trzeba potwierdzić, że replika ponownie przesyła i odtwarza log, a baza osiąga oczekiwany stan synchronizacji. W przypadku przełączenia awaryjnego należy zweryfikować nową rolę repliki podstawowej, dostępność baz dla aplikacji oraz poprawność tras odczytu, jeśli zostały skonfigurowane. Alerty powinny mieć jasno określone progi, źródło zdarzenia, czas utrzymywania się problemu i osobę odpowiedzialną za reakcję. Dzięki temu ostrzeżenie staje się punktem rozpoczęcia diagnostyki, a nie jedynie komunikatem rejestrowanym bez dalszej analizy.