SQL Server Always On Availability Groups

Always On Availability Groups to mechanizm SQL Server utrzymujący synchronizowane repliki baz na kilku serwerach dla wysokiej dostępności.

SQL Server Always On Availability Groups: czym jest ten mechanizm

SQL Server Always On Availability Groups to rozbudowana funkcja platformy Microsoft SQL Server, której zadaniem jest utrzymywanie kilku kopii wybranych baz danych oraz umożliwienie przełączenia obsługi na inną replikę w razie problemu z podstawowym wystąpieniem. W praktyce nie chodzi wyłącznie o wykonywanie kopii zapasowych. Dane są przesyłane pomiędzy wystąpieniami SQL Server w sposób ciągły albo z niewielkim opóźnieniem, a stan replik jest monitorowany przez mechanizmy klastra trybu failover systemu Windows Server.

Availability Groups pozwalają połączyć zestaw baz, które powinny przechodzić przez proces przełączenia jako spójna grupa. Każda grupa ma jedną replikę podstawową, przyjmującą operacje zapisu, oraz jedną lub kilka replik pomocniczych. Repliki pomocnicze mogą służyć do odczytu, raportowania lub wykonywania kopii zapasowych, zależnie od konfiguracji i możliwości używanej edycji SQL Server. Aplikacja nie musi znać wszystkich szczegółów topologii, ponieważ połączenie może być kierowane przez listener grupy dostępności.

Istotnym elementem jest rozdzielenie dwóch pojęć: wysokiej dostępności i odzyskiwania po awarii. Availability Groups może ograniczyć przerwę w pracy po awarii wystąpienia, lecz nie zastępuje poprawnej strategii backupu. Usunięcie danych, błędna aktualizacja albo logiczne uszkodzenie bazy może zostać szybko odwzorowane na replikach. Z tego powodu synchronizacja replik powinna współistnieć z kopiami pełnymi, różnicowymi oraz dziennika transakcji.

SQL Server Always On Availability Groups a synchronizacja i przełączanie

W trybie synchronicznego zatwierdzania transakcja na replice podstawowej jest uznawana za zakończoną dopiero wtedy, gdy odpowiednia informacja zostanie potwierdzona przez replikę synchroniczną. Zwiększa to ochronę przed utratą ostatnich zatwierdzonych zmian, ale może podnieść czas odpowiedzi, zwłaszcza przy dużym opóźnieniu sieci, przeciążeniu pamięci masowej albo różnicy wydajności pomiędzy węzłami. Tryb asynchroniczny pozwala ograniczyć wpływ odległości i opóźnień na aplikację, jednak w razie nagłego zatrzymania podstawowej repliki część nieprzesłanych transakcji może wymagać odtworzenia z innych źródeł lub zostać utracona.

Przełączenie kontrolowane, czyli planned manual failover, zwykle wymaga doprowadzenia replik do odpowiedniego stanu i świadomego wskazania nowej repliki podstawowej. Automatyczne przełączenie może nastąpić wtedy, gdy spełnione są warunki określone przez konfigurację, między innymi dostępność odpowiednich mechanizmów klastra, poprawny tryb synchronizacji oraz prawidłowa ocena stanu wystąpień. Nie każda awaria prowadzi zatem do natychmiastowego przełączenia. Najpierw analizowane są sygnały dotyczące usługi SQL Server, systemu Windows, sieci i zależności wymaganych przez aplikację.

Listener Availability Group działa jako logiczny punkt połączenia. Dzięki temu aplikacja może korzystać z nazwy grupy zamiast z adresu konkretnego serwera. Właściwości połączenia mogą wskazywać, czy żądania mają być kierowane do repliki podstawowej, czy do replik przeznaczonych do odczytu. Należy jednak sprawdzić obsługę tych parametrów przez sterownik, bibliotekę dostępu do danych i samą aplikację. Sama obecność listenera nie gwarantuje prawidłowej obsługi po zmianie roli.

Ważne jest także rozróżnienie pomiędzy repliką, bazą a wystąpieniem. Jedna replika może zawierać wiele baz należących do tej samej grupy, lecz każda z nich musi spełniać wymagania dotyczące odzyskiwania, pełnego modelu rejestrowania oraz spójności. Brak jednej bazy, odmienna konfiguracja bezpieczeństwa albo różnice w loginach i zadaniach agenta mogą sprawić, że przełączenie infrastruktury nie zapewni pełnej ciągłości działania aplikacji.

SQL Server Always On Availability Groups: typowe problemy

Jednym z częstszych problemów jest zatrzymanie synchronizacji. Przyczyną może być brak miejsca w dzienniku transakcji, przepełnienie dysku, zbyt wolne przesyłanie danych, przeciążenie repliki pomocniczej lub przerwa w komunikacji pomiędzy wystąpieniami. W dziennikach i widokach dynamicznego zarządzania należy rozdzielić opóźnienie przesyłania od opóźnienia odtwarzania. Pierwsze oznacza, że transakcje nie docierają wystarczająco szybko do repliki pomocniczej, a drugie, że dotarły, lecz nie są jeszcze odtwarzane.

Problematyczne bywają również certyfikaty, punkty końcowe komunikacji i uprawnienia kont usług. Repliki muszą móc nawiązać połączenie przez właściwy endpoint, a zapora sieciowa nie może blokować wymaganej komunikacji. Zmiana hasła konta usługi, odtworzenie wystąpienia z innej kopii lub modyfikacja reguł sieciowych może spowodować pozornie nagłą utratę synchronizacji.

Nieprawidłowe działanie może wynikać także z konfiguracji aplikacji. Po przełączeniu nazwa logiczna może działać, ale pula połączeń w aplikacji nadal przechowywać informacje o poprzednim wystąpieniu. Czas ponownego połączenia zależy między innymi od limitów sterownika, ustawień timeoutu i sposobu obsługi błędów. W aplikacjach wymagających zapisu trzeba zweryfikować, czy po zmianie roli połączenie rzeczywiście trafia do repliki przyjmującej zapis.

Wydajność należy oceniać całościowo. Wysokie użycie procesora nie zawsze jest główną przyczyną opóźnień, ponieważ wąskim gardłem może być pamięć masowa, przepustowość sieci, blokady, rozrost dziennika lub niewłaściwe zapytania. Przydatne jest porównanie czasu zatwierdzania transakcji, długości kolejki redo, opóźnienia logu oraz obciążenia zapytań na każdej replice. Bez takiej korelacji łatwo pomylić skutek z przyczyną.

SQL Server Always On Availability Groups: praktyczne wskazówki

Przed wdrożeniem należy opisać wymagania aplikacji: dopuszczalną długość przerwy, możliwą utratę danych, kolejność uruchamiania zależności oraz sposób zgłaszania błędu połączenia. Te założenia pomagają dobrać tryb synchronizacji, liczbę replik i zasady przełączania. Warto również ustalić, które bazy muszą należeć do jednej grupy, a które mogą być obsługiwane niezależnie.

Każdy węzeł powinien mieć porównywalne ustawienia instancji, poziomy aktualizacji, konfigurację pamięci, lokalizację plików baz i dzienników oraz dostęp do wymaganych zasobów. Należy kontrolować stan klastrów, quorum, role replik i kondycję baz, a także przechowywać historię alertów. Monitoring powinien ostrzegać nie tylko o awarii, ale również o narastającym opóźnieniu, rosnącym dzienniku transakcji, utracie połączenia z endpointem i nieudanym zadaniu kopii zapasowej.

Test przełączenia powinien być zaplanowany i przeprowadzony w warunkach możliwie zbliżonych do rzeczywistych. Sprawdza się wtedy nie tylko zmianę roli bazy, lecz także działanie listenera, ponowne łączenie aplikacji, zadania automatyczne, konta logowania, uprawnienia, raporty i procedury powrotu do poprzedniego układu. Po każdym teście należy odnotować czas niedostępności oraz wszystkie ręczne czynności wymagane do przywrócenia obsługi.

Warto zachować dokumentację obejmującą nazwy baz, role replik, tryb synchronizacji, reguły routingu odczytu, lokalizację kopii zapasowych oraz osoby uprawnione do wykonania przełączenia. Dokumentacja powinna być aktualizowana po zmianie wersji SQL Server, sterowników, zapory, systemu operacyjnego lub konfiguracji aplikacji. Sam mechanizm wysokiej dostępności nie zmniejsza ryzyka wynikającego z braku procedur i nieprzetestowanych zależności.

SQL Server Always On Availability Groups: kiedy zgłosić się do serwisu

Wsparcie techniczne może być potrzebne, gdy repliki pozostają w stanie niesynchronizowanym, listener nie kieruje połączeń zgodnie z oczekiwaniami, po przełączeniu aplikacja nie odzyskuje dostępu albo dziennik transakcji rośnie mimo prawidłowo działających kopii zapasowych. Zgłoszenie warto przygotować wraz z informacją o czasie wystąpienia problemu, komunikatach z systemu, stanie ról replik i ostatnich zmianach w konfiguracji. Pozwala to rozpocząć analizę od danych, a nie od przypadkowej modyfikacji ustawień.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się analizą problemów ze sprzętem komputerowym oraz środowiskiem pracy laptopa i komputera PC, w tym oceną objawów, połączeń sieciowych i działania systemu. W przypadku SQL Server Always On Availability Groups szczególne znaczenie ma rozdzielenie problemu sprzętowego od błędu konfiguracji bazy, dlatego sprawdzane są symptomy, logi i zależności pomiędzy urządzeniem a oprogramowaniem. Taka wstępna ocena ułatwia określenie, czy potrzebna jest naprawa komputera, uporządkowanie konfiguracji, czy konsultacja administratora baz danych.

Do serwisu warto zgłosić się także przed planowaną migracją, zmianą dysków, aktualizacją systemu lub testem przełączenia. Wcześniejsze sprawdzenie stanu urządzeń, miejsca na dane, stabilności sieci i sposobu wykonywania kopii może ograniczyć ryzyko przerwania pracy. Po zakończeniu analizy powinno zostać jasno wskazane, które elementy działają prawidłowo, jakie objawy wymagają dalszej obserwacji i jakie działania należy wykonać w ustalonej kolejności.