Serwisanci dostępni teraz · czynne całą dobę, także w weekendy i świętaWarszawa i okolice · dojazd bezpłatny
Darmowa diagnoza laptopa
Darmowa diagnoza laptopa
Dojazd do klienta bezpłatnie
Dojazd do klienta bezpłatnie
Laptopy zastępcze bezpłatnie
Laptopy zastępcze bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie

Kompatybilność Always On

Termin Definicja
Kompatybilność Always On

Kompatybilność Always On określa, które funkcje bazy danych mogą działać w konfiguracji grup dostępności.

Co oznacza kompatybilność Always On w SQL Server

Kompatybilność Always On w SQL Server oznacza zgodność konkretnej funkcji, typu bazy danych albo sposobu wykonywania operacji z konfiguracją wysokiej dostępności. Określenie Always On obejmuje dwa różne mechanizmy: Always On Availability Groups oraz Always On Failover Cluster Instances. Grupa dostępności replikuje bazy danych między replikami, natomiast instancja FCI korzysta ze wspólnego magazynu i przenosi całą instancję SQL Server między węzłami klastra. Wymagania dotyczące obsługiwanych funkcji nie są więc identyczne dla obu rozwiązań.

W przypadku Always On Availability Groups podstawową jednostką ochrony jest pojedyncza baza danych. SQL Server przesyła rekordy dziennika transakcji z repliki podstawowej do replik pomocniczych, gdzie są one odtwarzane. Baza musi znajdować się w modelu odzyskiwania FULL, ponieważ mechanizm wymaga ciągłego łańcucha kopii zapasowych dziennika. Bazy systemowe, takie jak master, model, msdb i tempdb, nie są członkami grupy dostępności.

Funkcje bazodanowe a repliki grupy dostępności

Nie każda zawartość związana z aplikacją jest automatycznie replikowana razem z bazą. Dane tabel, indeksy, procedury składowane, widoki i wyzwalacze znajdujące się w chronionej bazie są przesyłane przez dziennik transakcji. Obiekty zapisane poza tą bazą nie są jednak synchronizowane w ten sam sposób. Dotyczy to między innymi loginów instancji, uprawnień na poziomie serwera, zadań SQL Server Agent, wpisów w msdb, certyfikatów oraz konfiguracji połączeń.

W praktyce oznacza to, że aplikacja może po przełączeniu awaryjnym połączyć się z nową repliką, ale nadal nie działać poprawnie, jeśli na tym serwerze brakuje loginu, odpowiednich uprawnień albo zadania agenta. Login jest obiektem instancji, a użytkownik bazy danych jest obiektem konkretnej bazy; ich zgodność obejmuje także identyfikator SID. Samo utworzenie loginu o tej samej nazwie na drugim serwerze może nie wystarczyć, jeżeli SID loginu nie odpowiada SID użytkownika zapisanym w bazie.

Obsługa dodatkowych funkcji zależy od wersji SQL Server, edycji, konfiguracji grupy oraz sposobu użycia danej funkcji. Przykładowo FILESTREAM może być używany w bazie należącej do grupy dostępności, ale wymaga poprawnej konfiguracji FILESTREAM na każdym odpowiednim węźle. FileTable ma dodatkowe zależności od udziałów plikowych i nie należy zakładać, że każda funkcja oparta na FILESTREAM zachowuje się tak samo. Z tego powodu zgodność trzeba sprawdzać dla konkretnej funkcji, a nie tylko na podstawie podobnej nazwy.

Rozdzielenie zgodności wersji, edycji i poziomu bazy

Kompatybilność Always On nie jest tym samym co poziom zgodności bazy danych. Poziom zgodności, na przykład zapisany jako wartość właściwości bazy, wpływa przede wszystkim na zachowanie parsera, optymalizatora i niektórych funkcji języka T-SQL. Nie potwierdza natomiast, że baza może zostać dodana do grupy dostępności ani że wszystkie operacje będą działały na replice pomocniczej.

Ważne są także wersje i edycje SQL Server uruchomione na poszczególnych replikach. Konfiguracja musi spełniać macierz obsługiwanych wersji, edycji, systemów Windows Server i funkcji klastra. W klasycznej grupie dostępności repliki powinny korzystać z kompatybilnego poziomu produktu; różnice wersji mogą ograniczać możliwość dołączenia repliki, wykonywania przełączeń lub korzystania z określonych funkcji. Nowsze mechanizmy, takie jak grupy dostępności rozproszone, mają własne zasady i nie należy przenosić ich wymagań na zwykłą grupę dostępności.

Przed wdrożeniem należy sprawdzić między innymi tryb dostępności, tryb failover, obsługę odczytu na replice pomocniczej, konfigurację endpointów, certyfikaty oraz uprawnienia kont usług. Tryb synchroniczny pozwala uzyskać zatwierdzanie transakcji na replice pomocniczej, ale wymaga stabilnej komunikacji i może zwiększać opóźnienie zapisu. Tryb asynchroniczny ogranicza wpływ opóźnień sieciowych na replikę podstawową, lecz przy awarii może wystąpić utrata jeszcze nieprzesłanych rekordów dziennika.

Weryfikacja przed przełączeniem i po awarii

Ocena zgodności powinna obejmować test odtworzenia pełnej ścieżki działania aplikacji. Sam status SYNCHRONIZED nie dowodzi, że aplikacja będzie działała po zmianie serwera. Trzeba sprawdzić połączenie przez listener grupy dostępności, rozwiązywanie nazwy DNS, uwierzytelnianie, mapowanie użytkowników, zadania cykliczne, certyfikaty używane przez aplikację oraz dostęp do zasobów wymaganych przez procesy działające poza bazą.

Stan replik można analizować w SQL Server za pomocą widoków dynamicznego zarządzania, między innymi sys.dm_hadr_database_replica_states, sys.dm_hadr_availability_replica_states i sys.availability_replicas. Przydatne są również katalogi sys.availability_groups, sys.availability_databases_cluster oraz właściwości baz odczytywane przez DATABASEPROPERTYEX. Weryfikacja powinna uwzględniać stan synchronizacji, rozmiar kolejki wysyłania dziennika, kolejkę odtwarzania i ostatni błąd zgłoszony przez replikę.

Test przełączenia powinien być zaplanowany i wykonany w kontrolowanym oknie. Po zmianie roli należy potwierdzić, że aplikacja korzysta z listenera, a nie ze stałej nazwy hosta repliki podstawowej. Należy też sprawdzić operacje zapisu, odczytu, kopie zapasowe oraz zadania agenta. Jeżeli kopie zapasowe są kierowane na repliki pomocnicze, konfiguracja zadań i preferencji backupu musi być obecna na wszystkich serwerach, ponieważ Always On nie replikuje automatycznie definicji zadań SQL Server Agent.

Podczas diagnostyki warto odróżnić błąd samej replikacji od błędu zależności aplikacji. Brak synchronizacji może wynikać z problemu endpointu, sieci, certyfikatu, logu transakcji albo niewystarczającego miejsca na dysku. Poprawna synchronizacja przy jednoczesnym błędzie logowania po failoverze wskazuje zwykle na brak loginu, niezgodny SID, nieobecną konfigurację agenta lub nieprawidłowy connection string. Takie rozdzielenie przyczyn pozwala ocenić, czy dana funkcja jest niekompatybilna z Always On, czy tylko nie została odtworzona na wszystkich replikach.

+48 22 100 48 29Zadzwoń teraz · serwisant w 1 godzinę