SQL Server Always On

SQL Server Always On to zbiorcze określenie mechanizmów wysokiej dostępności opartych na grupach dostępności.

SQL Server Always On jako architektura wysokiej dostępności

SQL Server Always On to nazwa zbiorcza mechanizmów wysokiej dostępności dostępnych w Microsoft SQL Server. W kontekście grup dostępności (Availability Groups, AG) rozwiązanie polega na utrzymywaniu kilku kopii określonych baz danych na osobnych instancjach SQL Server. Jedna replika pełni rolę podstawową i obsługuje zapis, natomiast pozostałe repliki przechowują kopie synchronizowane z użyciem przesyłania rekordów dziennika transakcji. Always On Availability Groups nie jest pojedynczą usługą instalowaną niezależnie od SQL Server, lecz funkcją silnika bazy danych oraz mechanizmów klastra.

Grupa dostępności obejmuje zestaw baz, które mają być przełączane razem. Replika podstawowa zapisuje transakcje do dziennika, a SQL Server przekazuje rekordy dziennika do replik pomocniczych. Na replice pomocniczej rekordy są odtwarzane w odpowiednich bazach. Dzięki temu przełączenie dotyczy całej grupy, a nie pojedynczego pliku bazy. Always On Availability Groups różni się od Failover Cluster Instance, ponieważ AG utrzymuje osobne instancje i osobne kopie baz, podczas gdy FCI wykorzystuje współdzielony magazyn i przenosi rolę całej instancji między węzłami.

Repliki, tryby zatwierdzania i punkt przełączania

SQL Server Always On obsługuje synchroniczny oraz asynchroniczny tryb przesyłania danych. W trybie synchronicznego zatwierdzania replika podstawowa oczekuje na potwierdzenie zapisania odpowiednich rekordów dziennika przez replikę synchroniczną przed uznaniem transakcji za zatwierdzoną. Ogranicza to ryzyko utraty zatwierdzonych transakcji podczas przełączenia, ale zwiększa zależność czasu odpowiedzi od sieci, obciążenia dysków i wydajności serwera pomocniczego. W trybie asynchronicznym podstawowa replika nie czeka na pełne przetworzenie dziennika na replice pomocniczej, dlatego rozwiązanie lepiej toleruje większe opóźnienia sieciowe, lecz w chwili awarii może wystąpić utrata jeszcze nieprzekazanych lub nieodtworzonych rekordów.

Możliwe jest automatyczne, ręczne albo wymuszone przełączenie roli. Automatyczny failover wymaga odpowiedniej konfiguracji replik, synchronicznego trybu zatwierdzania oraz spełnienia warunków dotyczących stanu baz i komunikacji między uczestnikami. Ręczne przełączenie jest kontrolowaną operacją administracyjną wykonywaną zwykle podczas prac serwisowych. Wymuszone przełączenie może być użyte w sytuacji awaryjnej, gdy podstawowa replika jest niedostępna, ale należy uwzględnić możliwość utraty danych, jeżeli repliki nie były w pełni zsynchronizowane.

Połączenia aplikacji powinny korzystać z nazwy listenera grupy dostępności, a nie ze stałej nazwy konkretnego serwera. Listener udostępnia wirtualny punkt dostępu wskazujący aktualną replikę podstawową. W zależności od konfiguracji klienta i wersji sterownika mogą być używane parametry takie jak MultiSubnetFailover=True, szczególnie gdy listener jest powiązany z adresami w różnych podsieciach. Samo przełączenie roli nie gwarantuje poprawnego działania aplikacji, jeżeli aplikacja używa zapamiętanego adresu serwera, nie obsługuje ponownego połączenia albo posiada długie limity czasu oczekiwania.

Warunki działania grupy dostępności w SQL Server

Na działanie Always On wpływa konfiguracja instancji, systemu Windows Server, sieci i magazynów danych. W typowym wdrożeniu Windows grupy dostępności korzystają z Windows Server Failover Clustering, który monitoruje stan węzłów i uczestniczy w podejmowaniu decyzji o automatycznym przełączeniu. Klaster wymaga prawidłowego quorum. Jeżeli liczba dostępnych głosów spadnie poniżej wymaganego poziomu, automatyczne operacje mogą zostać zablokowane, aby uniknąć równoczesnego uznania dwóch węzłów za aktywną stronę rozwiązania, czyli tzw. split-brain.

Repliki komunikują się przez punkty końcowe Database Mirroring Endpoint. Każda instancja uczestnicząca w grupie musi mieć działający punkt końcowy, a zapora sieciowa musi przepuszczać jego port. Port 5022 jest często używany jako wartość domyślna, lecz administrator może skonfigurować inny port. Konto usługi SQL Server na jednej replice musi mieć możliwość uwierzytelnionej komunikacji z pozostałymi punktami końcowymi albo należy zastosować odpowiednią konfigurację certyfikatów. Błąd DNS, blokada portu, niezgodne uprawnienia lub zatrzymany punkt końcowy mogą zatrzymać przesyłanie dziennika mimo prawidłowego działania samej bazy.

Do grupy można dodać tylko bazy spełniające wymagania Always On, między innymi znajdujące się w modelu pełnego odzyskiwania i posiadające wykonany pełny backup poprzedzający dołączenie. Kopie baz pomocniczych muszą zostać zainicjalizowane, a ich struktura i stan synchronizacji muszą odpowiadać bazie podstawowej. Always On nie replikuje automatycznie wszystkich elementów znajdujących się poza bazą. Loginy na poziomie instancji, zadania SQL Server Agent, poświadczenia, konfiguracje serwera oraz zawartość baz systemowych wymagają osobnego odtworzenia lub synchronizacji. Nieprawidłowe przygotowanie tych elementów może spowodować, że po failoverze baza będzie dostępna, lecz aplikacja nie zaloguje się albo nie wykona zaplanowanego zadania.

Diagnostyka synchronizacji i przełączeń Always On

Podstawowym punktem kontroli jest rozróżnienie stanu repliki od stanu pojedynczej bazy. Replika może być dostępna, ale konkretna baza może mieć status NOT SYNCHRONIZING, NOT SYNCHRONIZED, SUSPENDED albo RECOVERY_PENDING. Przyczyną może być brak miejsca na dysku, zatrzymanie przesyłania dziennika, opóźnienie odtwarzania, błąd endpointu, niedostępność pliku bazy lub długotrwała transakcja. Warto analizować DMV sys.dm_hadr_database_replica_states oraz sys.dm_hadr_availability_replica_states, a konfigurację odczytywać między innymi z widoków katalogowych sys.availability_groups i sys.availability_replicas.

Podczas analizy należy porównywać opóźnienie wysyłania, opóźnienie odtwarzania, rozmiar zaległego dziennika oraz czas ostatniego przetworzonego numeru sekwencyjnego dziennika. Wysokie opóźnienie wysyłania wskazuje zwykle na problem po stronie sieci, endpointu lub obciążenia repliki podstawowej. Wysokie opóźnienie odtwarzania częściej wiąże się z wydajnością dysków, blokadami, dużymi operacjami modyfikującymi dane albo niewystarczającymi zasobami CPU i pamięci na replice pomocniczej. Dzienniki SQL Server i zdarzenia klastra pomagają ustalić, czy przełączenie nastąpiło z powodu awarii usługi, utraty quorum, błędu komunikacji czy ręcznej operacji administratora.

Przed planowanym failoverem trzeba potwierdzić, że docelowa replika jest zsynchronizowana, listener rozwiązuje się poprawnie w DNS, a aplikacje używają właściwego ciągu połączenia. Po przełączeniu należy sprawdzić rolę repliki, stan wszystkich baz, możliwość logowania, działanie zadań agenta i dostęp aplikacji do wymaganych obiektów. Jeżeli problem dotyczy komputera lub lokalnego narzędzia administracyjnego, diagnostyka powinna obejmować również sterownik klienta, cache DNS, reguły zapory i zapisane dane połączenia. W przypadku środowiska serwerowego naprawa wymaga zachowania kopii logów, konfiguracji grupy i informacji o ostatnim stanie synchronizacji, ponieważ pochopne usuwanie repliki może utrudnić odzyskanie danych i odtworzenie prawidłowej kolejności operacji.