Problem z Always On

Problem z Always On wymaga sprawdzenia stanu synchronizacji replik i dostępności kworum klastra.

Problem z Always On – czym jest i na czym polega

Problem z Always On dotyczy najczęściej środowiska Microsoft SQL Server korzystającego z grup dostępności, w których jedna baza lub zestaw baz może być obsługiwany przez kilka instancji. Mechanizm ten służy do utrzymania ciągłości pracy danych, przełączania obsługi na inną replikę oraz ograniczania skutków awarii pojedynczego komputera. Gdy pojawia się błąd, nie zawsze oznacza to uszkodzenie samej bazy. Przyczyną może być zerwane połączenie między replikami, niezgodna konfiguracja endpointów, problem z usługą SQL Server, niedostępność dysku albo utrata prawidłowej komunikacji z mechanizmem rozstrzygającym, która replika może działać jako podstawowa.

W praktyce objawy bywają różne. Aplikacja może przestać łączyć się z bazą, status repliki może zmienić się na nierozwiązany albo niezsynchronizowany, a automatyczne przełączenie może nie nastąpić mimo awarii głównego węzła. Czasem system działa, lecz synchronizacja pozostaje opóźniona, przez co na replice pomocniczej widoczna jest starsza wersja danych. Znaczenie ma także rodzaj trybu dostępności. Replikacja synchroniczna wymaga potwierdzenia zapisu przez drugą stronę, natomiast w trybie asynchronicznym opóźnienie może być dopuszczalne, ale w razie awarii istnieje ryzyko utraty ostatnich zmian.

Problem z Always On – kontekst techniczny i porównanie trybów pracy

Analizę warto rozpocząć od ustalenia, czy problem dotyczy synchronizacji, dostępności, routingu połączeń, czy samego przełączania. Synchronizacja opisuje zgodność danych pomiędzy replikami. Dostępność odnosi się do tego, czy dana replika odpowiada i może przyjmować połączenia. Routing określa, gdzie kierowane są połączenia odczytu lub połączenia aplikacji. Przełączanie awaryjne jest osobnym procesem, zależnym od ustawień, stanu wszystkich wymaganych składników oraz warunków określonych dla danej grupy dostępności.

Replika synchroniczna działa podobnie do dwóch współpracujących kopii, które potwierdzają wzajemnie wykonanie operacji. Zapewnia to mniejsze opóźnienie między stronami, lecz zwiększa wrażliwość na problemy z siecią i wydajnością zapisu. Replika asynchroniczna może pracować z większym dystansem lub przy mniej stabilnym połączeniu, ale informacje o zmianach mogą docierać z opóźnieniem. Nie należy więc oceniać stanu wyłącznie na podstawie faktu, że instancja SQL Server odpowiada na zapytania. Należy sprawdzić, czy log transakcyjny jest przesyłany, czy wpisy są odbierane oraz czy zaległości nie narastają.

Ważną rolę odgrywa kworum. Jest to sposób ustalenia, czy wystarczająca liczba składników środowiska pozostaje dostępna, aby bezpiecznie kontynuować pracę. Utrata kworum może zablokować automatyczne działanie grupy, nawet gdy pojedyncza replika nadal odpowiada lokalnie. Takie zachowanie chroni przed sytuacją, w której dwie odseparowane części środowiska uznałyby jednocześnie, że mają prawo przyjmować zapisy. Przy porównywaniu objawów należy zatem odróżnić awarię usługi bazy od awarii komunikacji, utraty głosów wymaganych do działania oraz nieprawidłowego stanu zasobów systemowych.

Problem z Always On – typowe problemy i ich objawy

• Brak synchronizacji repliki. Status może wskazywać stan synchronizacji w toku, zawieszenie albo błąd. Warto wtedy sprawdzić, czy dziennik transakcji nie jest pełny, czy na serwerze pomocniczym znajduje się wystarczająca ilość miejsca oraz czy proces przesyłania zmian nadal działa.
• Błąd endpointu komunikacyjnego. Repliki komunikują się przez określone punkty końcowe. Nieprawidłowy port, zatrzymana usługa, blokada zapory lub zmiana certyfikatu może przerwać przesyłanie danych. Samo działanie połączenia administracyjnego nie potwierdza, że działa również komunikacja wymagana przez Always On.
• Niezgodność certyfikatów lub uprawnień. Zmiana konta usługi, odtworzenie konfiguracji albo modyfikacja zasad bezpieczeństwa może spowodować, że jedna strona nie będzie mogła uwierzytelnić drugiej. Konieczne jest wtedy porównanie konfiguracji wszystkich replik oraz sprawdzenie wpisów w dziennikach.
• Nieudane przełączenie awaryjne. Przyczyną może być wyłączona możliwość automatycznego przełączania, niewłaściwy tryb dostępności, niespełnienie warunków synchronizacji albo brak kworum. Próba ręcznego przełączenia bez wcześniejszej oceny stanu danych może pogłębić problem.
• Nieprawidłowy adres nasłuchiwacza. Aplikacja może korzystać z nazwy grupy dostępności, podczas gdy adres nie wskazuje aktualnej repliki podstawowej. Błąd DNS, nieaktualny wpis, niewłaściwy port lub problemy z trasą sieciową mogą wyglądać jak awaria bazy.
• Wzrost opóźnienia i zaległości. Replika może nadal być dostępna, lecz nie nadążać za zapisami. W takim przypadku należy porównać opóźnienie logu, kolejkę wysyłania oraz kolejkę ponownego wykonania zmian. Pomocne jest także sprawdzenie obciążenia procesora, pamięci, dysków i sieci.
• Uszkodzenie lub brak pliku bazy. Różnice w ścieżkach, uprawnieniach do katalogu, dostępności woluminu albo sposobie odtwarzania bazy mogą uniemożliwić dołączenie jej do grupy. Wymaga to ostrożnego porównania plików, ścieżek i kolejności operacji.

W diagnostyce nie powinno się ograniczać do pojedynczego komunikatu z konsoli. Ten sam objaw może wynikać z wielu przyczyn, a komunikat końcowy bywa tylko skutkiem wcześniejszego błędu. Najbardziej użyteczne jest zestawienie czasu wystąpienia problemu z dziennikami SQL Server, dziennikiem systemowym, informacjami o sieci oraz historią zmian administracyjnych. Pozwala to ustalić, czy problem zaczął się po restarcie, aktualizacji, zmianie reguł zapory, migracji danych lub przeciążeniu zasobów.

Problem z Always On – praktyczne wskazówki diagnostyczne

Najpierw należy opisać dokładny zakres zdarzenia: które bazy są objęte problemem, która replika była podstawowa, kiedy pojawiła się zmiana statusu i czy aplikacje utraciły połączenie. Następnie warto zebrać status grup dostępności, stan każdej repliki, tryb synchronizacji oraz informację o możliwości przełączenia. Przydatne jest porównanie wyników z obu stron, ponieważ jedna replika może raportować brak komunikacji, podczas gdy druga wskazuje na zatrzymany proces odbioru.

W dalszej kolejności sprawdza się podstawowe elementy systemu. Należy potwierdzić działanie usługi SQL Server i usługi odpowiedzialnej za pracę środowiska, dostępność wymaganych woluminów, wolne miejsce, stan dziennika transakcji oraz obciążenie zasobów. Warto także zweryfikować rozwiązywanie nazw, połączenie na właściwym porcie, reguły zapory i zgodność konfiguracji endpointów. Jeżeli stosowane są certyfikaty, trzeba sprawdzić ich ważność, zaufanie oraz uprawnienia kont usług.

Przed wykonaniem przełączenia należy ustalić, czy dane na wybranej replice są kompletne. W trybie synchronicznym ryzyko różnicy bywa mniejsze, lecz nadal trzeba potwierdzić rzeczywisty status. W trybie asynchronicznym należy uwzględnić opóźnienie i możliwą utratę ostatnich transakcji. Nie powinno się usuwać grupy dostępności, odłączać bazy ani wymuszać pracy kilku stron jednocześnie bez planu powrotu. Takie działania mogą utrudnić późniejsze odtworzenie spójności.

Po przywróceniu komunikacji należy obserwować, czy kolejki synchronizacji maleją, czy status przechodzi do stanu oczekiwanego oraz czy aplikacje ponownie korzystają z właściwego adresu. Dobrą praktyką jest zapisanie konfiguracji przed zmianą i po zmianie, aby można było wskazać przyczynę oraz zweryfikować, czy naprawa nie usunęła jedynie objawu. W środowisku używanym przez wiele aplikacji trzeba również potwierdzić działanie połączeń odczytu, zapisów, zadań cyklicznych i kopii zapasowych.

Problem z Always On – kiedy zgłosić się do serwisu

Zgłoszenie do specjalisty jest uzasadnione, gdy stan repliki zmienia się cyklicznie, synchronizacja zatrzymuje się mimo poprawnej pracy usług, nie można ustalić przyczyny błędu na podstawie dzienników albo przełączenie grozi utratą dostępu do danych. Warto przekazać opis objawów, czas wystąpienia, komunikaty z konsoli, informację o ostatnich zmianach oraz dane dotyczące tego, czy problem dotyczy jednej bazy, całej grupy czy połączeń aplikacji. Ułatwia to rozdzielenie problemu z bazą od problemu z systemem, siecią lub konfiguracją zabezpieczeń.

W przypadku sprzętu wykorzystywanego do pracy biurowej lub obsługi baz danych można skorzystać z pomocy Warszawskiego Pogotowia Komputerowego 24/7. Naprawy z reguły są wykonywane do 3 dni roboczych, przy czym zakres prac zależy od wyniku diagnozy i stanu urządzenia. Przed przekazaniem sprzętu warto zabezpieczyć kopie zapasowe oraz uzgodnić, które czynności mogą zostać wykonane na działającym środowisku, a które wymagają kontrolowanego zatrzymania usług.

Jeżeli problem z Always On pojawił się po awarii zasilania, zmianie konfiguracji, aktualizacji lub przeniesieniu baz, należy poinformować o tym już przy zgłoszeniu. Istotne jest również wskazanie, czy występuje tylko brak synchronizacji, czy także niedostępność aplikacji, błędny routing połączeń albo problemy z uruchomieniem instancji. Tak przygotowane zgłoszenie pozwala szybciej ustalić kolejność kontroli i ograniczyć ryzyko działań, które mogłyby utrudnić odzyskanie spójnego stanu danych.