Błąd Always On Availability Group

Błąd Always On Availability Group sygnalizuje problem z prawidłowym działaniem mechanizmu wysokiej dostępności bazy danych.

Jak rozumieć błąd Always On Availability Group

Błąd Always On Availability Group oznacza, że grupa dostępności w Microsoft SQL Server nie realizuje prawidłowo jednego z zadań związanych z replikacją, synchronizacją lub udostępnianiem baz danych. Always On Availability Groups, często skracane do AG, jest mechanizmem wysokiej dostępności i odzyskiwania po awarii. Grupa obejmuje jedną lub większą liczbę baz danych użytkownika oraz repliki utrzymywane na oddzielnych instancjach SQL Server. Replika podstawowa przyjmuje operacje zapisu, a repliki pomocnicze otrzymują rekordy dziennika transakcji i odtwarzają je lokalnie.

Sam komunikat o błędzie nie wskazuje jeszcze konkretnej przyczyny. Problem może dotyczyć pojedynczej bazy, całej repliki, połączenia między instancjami albo konfiguracji klastra Windows Server Failover Clustering, na którym opiera się Always On Availability Groups. W zależności od miejsca wystąpienia awarii SQL Server może oznaczyć bazę jako NOT SYNCHRONIZING, NOT SYNCHRONIZED, RECOVERY_PENDING lub FAILED. Każdy z tych stanów opisuje inny etap problemu i wymaga odrębnej interpretacji.

Replikacja dziennika transakcji i stany synchronizacji

Podstawą działania AG jest przesyłanie rekordów dziennika transakcji z repliki podstawowej do repliki pomocniczej. Następnie dziennik jest zapisywany i odtwarzany na replice pomocniczej. W trybie synchronicznego zatwierdzania transakcja na replice podstawowej może oczekiwać na potwierdzenie zapisu dziennika na replice synchronicznej. W trybie asynchronicznym replika podstawowa nie czeka na takie potwierdzenie, dlatego opóźnienie pomocniczej repliki może być większe.

W widoku dynamicznego zarządzania sys.dm_hadr_database_replica_states można sprawdzić między innymi stan synchronizacji, liczbę oczekujących rekordów dziennika oraz liczbę rekordów oczekujących na odtworzenie. Widok sys.dm_hadr_availability_replica_states dostarcza informacji o stanie repliki, natomiast sys.availability_replicas i sys.availability_databases_cluster pokazują elementy konfiguracji grupy. Warto odróżnić opóźnienie przesyłania dziennika od opóźnienia jego odtwarzania: pierwsze wskazuje na problem z transportem lub obciążenie repliki podstawowej, drugie może wynikać z obciążenia dysków, blokad albo niewystarczających zasobów CPU i pamięci na replice pomocniczej.

Najczęstsze źródła nieprawidłowego działania grupy

Jedną z przyczyn jest utrata komunikacji między instancjami SQL Server. Należy wtedy sprawdzić rozwiązywanie nazw, dostępność portu używanego przez endpoint mirroringu oraz stan endpointu HADR. Informacje o endpointach można odczytać z sys.database_mirroring_endpoints. Endpoint musi być uruchomiony, a konta usług SQL Server muszą mieć możliwość uwierzytelnienia połączenia. Błąd transportu może również wystąpić po zmianie certyfikatów, kont usług, reguł zapory albo adresów sieciowych.

Inne przyczyny to brak odpowiedniej kopii dziennika, niezgodność konfiguracji baz, pełny dysk, uszkodzenie plików, długotrwała transakcja lub zatrzymanie procesu odtwarzania na replice pomocniczej. Jeżeli baza nie jest zsynchronizowana, pochopne usunięcie jej z grupy i ponowne dodanie może zwiększyć zakres prac. Najpierw trzeba ustalić, czy możliwe jest wznowienie synchronizacji, czy wymagana jest nowa pełna kopia bazy oraz kopia dziennika, a następnie przywrócenie ich na replice pomocniczej z opcją NORECOVERY.

Bezpieczna kolejność diagnostyki i naprawy

Diagnostykę rozpoczyna się od zebrania dokładnego komunikatu z dziennika SQL Server, dziennika zdarzeń systemu Windows oraz historii zmian konfiguracji. Następnie porównuje się stan grupy, repliki i każdej bazy. Istotne są także informacje o ostatnim pomyślnym wysłaniu, odebraniu i odtworzeniu dziennika. Jeżeli wystąpiło automatyczne przełączenie awaryjne, należy zweryfikować, czy nowa replika podstawowa rzeczywiście przyjmuje ruch aplikacji oraz czy listener kieruje połączenia do właściwego węzła.

Naprawa powinna zachować spójność danych i zależeć od ustalonego trybu pracy grupy. Nie należy wykonywać ręcznego failoveru bez potwierdzenia, że docelowa replika jest odpowiednio zsynchronizowana, ponieważ przy trybie asynchronicznym mogą istnieć nieprzesłane rekordy dziennika. Po usunięciu przyczyny sprawdza się ponownie stan synchronizacji, opóźnienie transportu, opóźnienie odtwarzania, działanie listenera oraz poprawność połączeń aplikacyjnych. W przypadku zastosowań serwerowych diagnostyka wymaga dostępu administracyjnego do SQL Server i klastra, a czynności naprawcze powinny być wykonywane na podstawie kopii zapasowych oraz udokumentowanej konfiguracji.