Kompatybilność z Always On

Kompatybilność z Always On określa, czy dana funkcja bazy danych może działać w konfiguracji wysokiej dostępności.

Co oznacza kompatybilność funkcji z Always On

Kompatybilność z Always On oznacza, że określona funkcja silnika Microsoft SQL Server może działać w środowisku wysokiej dostępności opartym na technologii Always On. Nazwa Always On obejmuje przede wszystkim grupy dostępności Always On Availability Groups oraz instancje klastrowane Always On Failover Cluster Instances. Są to różne mechanizmy, dlatego zgodność funkcji trzeba oceniać względem konkretnego wariantu, wersji SQL Server, użytej edycji oraz sposobu wdrożenia.

W przypadku grup dostępności baza danych jest replikowana między repliką podstawową i replikami pomocniczymi. Replika podstawowa przyjmuje operacje zapisu, a repliki pomocnicze mogą obsługiwać odczyt, kopie zapasowe lub przejąć rolę podstawową po awarii, jeśli konfiguracja na to pozwala. Funkcja zgodna z Always On musi zachowywać poprawne działanie podczas synchronizacji, przełączenia ról i odtwarzania zmian z dziennika transakcji. Sama możliwość uruchomienia funkcji na jednej instancji nie oznacza jeszcze, że będzie ona obsługiwana w grupie dostępności.

Różnica między grupą dostępności a instancją klastrowaną

Always On Availability Groups zapewnia ochronę wybranych baz danych. Każda baza należąca do grupy jest synchronizowana na poziomie zmian zapisanych w dzienniku transakcji. Po przełączeniu awaryjnym połączenia aplikacji powinny korzystać z nazwy listenera grupy dostępności, a nie ze stałej nazwy pojedynczej instancji. Dzięki temu klient może zostać skierowany do aktualnej repliki podstawowej. Kompatybilność funkcji obejmuje więc nie tylko samą bazę, lecz także sposób nawiązywania połączeń, obsługę ponownego połączenia i zachowanie sesji po failoverze.

Always On Failover Cluster Instance działa na poziomie całej instancji SQL Server. W tym modelu przełączana jest instancja wraz z zasobami korzystającymi ze współdzielonej pamięci masowej, a nie pojedyncza baza replikowana do niezależnej instancji pomocniczej. Funkcja może być zgodna z jednym modelem, a ograniczona albo nieprzydatna w drugim. Przed wdrożeniem należy zatem ustalić, czy wymaganiem jest ochrona pojedynczych baz przez Availability Groups, czy przełączanie całej instancji przez Failover Cluster Instance.

Elementy wymagające sprawdzenia przed wdrożeniem

Podstawowym warunkiem dla grupy dostępności jest użycie baz użytkownika spełniających wymagania SQL Server dotyczące modelu odzyskiwania i synchronizacji dziennika. Baza dołączana do grupy musi korzystać z modelu odzyskiwania FULL oraz mieć wykonany pełny backup i backup dziennika, który pozwoli zainicjować replikę pomocniczą. Bazy systemowe, takie jak master, model, msdb i tempdb, nie są dodawane do grupy dostępności w taki sam sposób jak bazy użytkownika, dlatego funkcja zależna od ich lokalnego stanu może wymagać osobnej konfiguracji.

Trzeba również sprawdzić zgodność wersji i edycji SQL Server na wszystkich replikach. Replika pomocnicza nie może używać starszej wersji silnika niż replika podstawowa, natomiast w określonych scenariuszach kontrolowanej aktualizacji pomocnicza replika może działać na nowszej wersji. Różnice edycyjne wpływają na dostępność funkcji, liczbę obsługiwanych replik, możliwość wykonywania odczytów na replice pomocniczej oraz dostępne tryby wysokiej dostępności. Weryfikacja powinna obejmować także sterownik aplikacji, obsługę MultiSubnetFailover, certyfikaty, punkty końcowe HADR i reguły zapory.

Funkcje zapisujące stan poza chronioną bazą mogą wymagać dodatkowej analizy. Przykładem są zadania SQL Server Agent, loginy, uprawnienia na poziomie instancji, konfiguracje linked server, SQL Server Integration Services oraz obiekty przechowywane poza bazą. Po przełączeniu grupy dostępności baza może działać na innej instancji, ale elementy poziomu instancji nie są automatycznie replikowane przez mechanizm grupy. Zgodność funkcji oznacza więc nie tylko brak błędu technicznego podczas synchronizacji, lecz także zachowanie pełnego przepływu danych i operacji po zmianie repliki podstawowej.

Jak potwierdzić działanie w środowisku testowym

Ocena kompatybilności powinna rozpocząć się od dokumentacji dla dokładnej wersji SQL Server i konkretnej funkcji. Następnie należy utworzyć testową grupę dostępności, dodać kopię bazy użytkownika i sprawdzić stan synchronizacji w widokach dynamicznego zarządzania, między innymi sys.dm_hadr_database_replica_states oraz sys.dm_hadr_availability_replica_states. Warto potwierdzić, czy baza pozostaje w stanie SYNCHRONIZED lub SYNCHRONIZING, czy dziennik transakcji jest poprawnie przesyłany oraz czy nie rośnie opóźnienie redo na replice pomocniczej.

Test powinien obejmować ręczne przełączenie grupy dostępności, ponowne nawiązanie połączenia aplikacji przez listener oraz wykonanie operacji charakterystycznych dla analizowanej funkcji. Należy sprawdzić odczyt, zapis, transakcje, backupy i zachowanie zadań uruchamianych po stronie repliki podstawowej. Dopiero pozytywny wynik takiego testu pozwala uznać funkcję za praktycznie kompatybilną z daną konfiguracją Always On. W środowisku produkcyjnym trzeba dodatkowo monitorować stan punktów końcowych, synchronizację baz, opóźnienie przesyłania dziennika i wynik automatycznych przełączeń.

W przypadku problemu diagnostyka powinna rozdzielić błąd samej funkcji od błędu infrastruktury wysokiej dostępności. Inne przyczyny mogą mieć brak uprawnienia, nieosiągalny endpoint, niezgodna wersja sterownika, niedostępna współdzielona pamięć masowa, zatrzymany SQL Server Agent albo niepoprawny listener. Dopiero po sprawdzeniu tych zależności można wiarygodnie stwierdzić, że ograniczenie wynika z braku obsługi funkcji przez Always On, a nie z błędnej konfiguracji SQL Server lub aplikacji.