Konfiguracja Always On

Konfiguracja Always On to proces ustawienia grup dostępności zapewniających wysoką dostępność baz danych.

Rola konfiguracji Always On Availability Groups w SQL Server

Konfiguracja Always On w tym kontekście oznacza przygotowanie funkcji Always On Availability Groups dostępnej w systemie Microsoft SQL Server. Mechanizm służy do utrzymywania jednej lub kilku baz danych w grupie dostępności na wielu instancjach SQL Server. Jedna replika pełni rolę podstawowej i obsługuje zapis oraz odczyt zgodnie z konfiguracją, a pozostałe repliki utrzymują kopie baz danych i mogą przejąć rolę podstawową po awarii. Nie jest to pojedyncza opcja włączana bezpośrednio w bazie, lecz zestaw zależności obejmujących SQL Server, system Windows Server, klaster WSFC, sieć oraz konfigurację samych replik.

Always On Availability Groups działa na poziomie grupy baz danych. Do grupy dodaje się bazy użytkownika, które muszą spełniać wymagania funkcji, między innymi znajdować się w modelu odzyskiwania Full oraz posiadać wykonany pełny backup i backup dziennika transakcji przed rozpoczęciem inicjalizacji repliki. Mechanizm nie replikuje automatycznie wszystkich baz systemowych, loginów, zadań SQL Server Agent ani ustawień instancji. Dlatego konfiguracja wysokiej dostępności bazy wymaga osobnego zaplanowania elementów zależnych od instancji.

Elementy techniczne wymagane przed uruchomieniem grupy

Podstawą rozwiązania w klasycznej konfiguracji Always On jest Windows Server Failover Clustering, czyli WSFC. Węzły uczestniczące w rozwiązaniu muszą należeć do odpowiedniej domeny lub spełniać wymagania konkretnego wariantu wdrożenia, mieć poprawnie skonfigurowaną rozdzielczość nazw i komunikację sieciową oraz korzystać z obsługiwanych wersji SQL Server. Funkcję Always On Availability Groups włącza się w SQL Server Configuration Manager dla każdej instancji, a następnie restartuje usługę SQL Server. Samo włączenie funkcji nie tworzy jeszcze grupy dostępności.

Każda replika musi mieć dostęp do odpowiednich punktów końcowych mirroringu bazy danych, które SQL Server wykorzystuje do przesyłania rekordów dziennika transakcji. W typowej konfiguracji endpoint działa z użyciem protokołu TCP, a port musi być osiągalny między instancjami przez zaporę sieciową. Konta usług SQL Server na poszczególnych węzłach wymagają uprawnień pozwalających na wzajemne połączenie albo należy zastosować certyfikaty, jeśli architektura nie korzysta ze wspólnego kontekstu zabezpieczeń. Konieczne jest też zaplanowanie nazwy listenera grupy dostępności, adresu IP oraz portu, przez który aplikacje będą łączyć się z aktualną repliką podstawową.

Ważnym etapem jest ustalenie trybu dostępności i trybu przełączania. Replika synchroniczna potwierdza zapis po dostarczeniu i utrwaleniu logu na replice docelowej, co ogranicza ryzyko utraty zatwierdzonych transakcji, ale może zwiększać opóźnienie operacji zapisu. Replika asynchroniczna nie musi czekać na takie potwierdzenie, dlatego lepiej nadaje się do połączeń o większym opóźnieniu, lecz przy awarii może nie mieć jeszcze wszystkich zmian. Automatyczne przełączanie awaryjne wymaga odpowiedniej konfiguracji replik, trybu synchronicznego oraz udziału w klastrze WSFC.

Synchronizacja baz, listener i przełączenie po awarii

Podczas pracy grupy dostępności SQL Server przesyła rekordy dziennika transakcji z podstawowej repliki do replik pomocniczych. Na replice pomocniczej log jest odbierany, zapisywany, a następnie odtwarzany w bazie. Stan synchronizacji można kontrolować w widokach dynamicznego zarządzania, między innymi sys.dm_hadr_database_replica_states oraz sys.dm_hadr_availability_replica_states. Informacje te pozwalają rozróżnić bazę zsynchronizowaną, synchronizowaną, niesynchronizującą się albo znajdującą się w stanie, w którym występuje opóźnienie lub błąd transportu logu.

Listener grupy dostępności zapewnia stały punkt połączenia dla aplikacji. Połączenie klienta powinno wskazywać nazwę listenera, a nie nazwę konkretnego węzła, ponieważ po przełączeniu rola podstawowa może zostać przypisana innej replice. W parametrach połączenia może być wymagane ustawienie MultiSubnetFailover=True, szczególnie gdy listener korzysta z adresów w wielu podsieciach. To ustawienie wpływa na sposób próby nawiązywania połączenia przez sterownik klienta i powinno być zgodne z używaną wersją sterownika oraz konfiguracją sieci.

Przełączenie może być planowane albo wymuszone awarią. Planned manual failover powinien być wykonywany przy stanie synchronizacji pozwalającym na bezpieczne przejęcie roli, ponieważ wtedy docelowa replika posiada wymagane zmiany dziennika. Forced failover może być użyty w sytuacji utraty podstawowej repliki, ale przy replice asynchronicznej lub niepełnej synchronizacji istnieje ryzyko utraty transakcji, które zostały zatwierdzone na podstawowej instancji, lecz nie dotarły do repliki przejmującej pracę. Po przełączeniu trzeba sprawdzić stan listenera, połączenia aplikacji, zadania agenta oraz synchronizację pozostałych baz.

Weryfikacja konfiguracji i diagnostyka niespójności

Kontrola Always On powinna obejmować nie tylko fakt istnienia grupy, lecz także jej zachowanie podczas normalnej pracy i awarii. Należy sprawdzić role replik, tryb synchronizacji, tryb dostępności, stan endpointów, opóźnienie transportu logu oraz opóźnienie jego odtwarzania. Przydatne są także komunikaty SQL Server dotyczące zmian stanu grupy, błędów połączeń i problemów z klastrem WSFC. Sama obecność bazy na replice pomocniczej nie potwierdza poprawnej ochrony, ponieważ kopia może być nieaktualna albo zatrzymana w stanie niesynchronizującym się.

Typowe problemy wynikają z niedostępnego portu endpointu, błędnych uprawnień kont usług, różnic w konfiguracji instancji, braku miejsca na dysku, opóźnionego odtwarzania logu lub niepoprawnych ustawień DNS. Osobno trzeba zweryfikować backupy, ponieważ Always On nie zastępuje kopii zapasowych i nie chroni przed logicznym usunięciem danych, błędną aktualizacją ani uszkodzeniem powielonym na wszystkie repliki. Test powinien obejmować również rzeczywiste przełączenie kontrolowane, ponowne dołączenie aplikacji przez listener oraz powrót do pierwotnej repliki dopiero po potwierdzeniu jej prawidłowej synchronizacji.

W środowisku SQL Server warto dokumentować wersję i edycję silnika, ustawienia grupy, przypisanie replik, adres listenera, porty sieciowe, sposób wykonywania backupów oraz procedurę reakcji na awarię. Diagnostyka powinna rozdzielać problem samej bazy od problemu klastra, sieci, systemu operacyjnego i aplikacji klienckiej. Takie rozdzielenie pozwala ustalić, czy przyczyną jest utrata quorum, przerwanie transportu logu, opóźnienie odtwarzania, niedostępność listenera czy niezgodność parametrów połączenia.