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

Grupa dostępności

Termin Definicja
Grupa dostępności

Grupa dostępności to zestaw baz danych zarządzanych wspólnie w mechanizmie Always On, zapewniający wysoką dostępność.

Budowa grupy dostępności w SQL Server

Grupa dostępności (Availability Group, AG) jest mechanizmem wysokiej dostępności i odzyskiwania po awarii dostępnym w technologii SQL Server Always On. Obejmuje jeden lub kilka wskazanych użytkowych baz danych, które są replikowane pomiędzy instancjami SQL Server. W przeciwieństwie do pojedynczej bazy pracującej na jednym serwerze, grupa pozwala utrzymywać dodatkowe kopie danych na innych replikach. Zestaw baz należących do jednej grupy jest traktowany jako logiczna całość podczas wykonywania operacji przełączenia.

W grupie występuje replika podstawowa, na której odbywa się zapis i standardowa obsługa operacji modyfikujących dane, oraz repliki pomocnicze. Replika pomocnicza może działać w trybie synchronicznego albo asynchronicznego zatwierdzania transakcji. W trybie synchronicznym SQL Server przesyła rekordy dziennika transakcji do repliki pomocniczej i oczekuje na potwierdzenie odpowiedniego przetworzenia przed uznaniem transakcji za zatwierdzoną. Tryb asynchroniczny ogranicza oczekiwanie po stronie repliki podstawowej, ale w chwili awarii może wystąpić opóźnienie replikacji.

Replikacja dziennika i spójność baz

Synchronizacja w grupie dostępności opiera się na przesyłaniu rekordów dziennika transakcji, a nie na kopiowaniu plików bazy danych po każdym zapisie. Replika pomocnicza odtwarza otrzymane informacje w swojej kopii bazy. Dlatego baza pomocnicza musi znajdować się w stanie przywracania i pozostawać niedostępna dla zwykłych operacji zapisu. Do jednej grupy można dodać tylko bazy spełniające wymagania Always On, między innymi znajdujące się w modelu odzyskiwania FULL oraz posiadające pełną kopię zapasową.

Stan synchronizacji jest określany osobno dla każdej bazy i repliki. SQL Server rozróżnia między innymi stany SYNCHRONIZED, SYNCHRONIZING, NOT SYNCHRONIZING oraz niektóre stany przejściowe związane z uruchamianiem, odtwarzaniem lub zawieszaniem replikacji. Sama dostępność połączenia z repliką nie oznacza, że wszystkie transakcje zostały już odtworzone. Przy ocenie grupy należy sprawdzać również zaległość dziennika, opóźnienie odtwarzania i ewentualne błędy kanału komunikacyjnego.

Grupa nie zastępuje kopii zapasowych. Repliki przechowują zasadniczo te same dane, więc usunięcie lub logiczne uszkodzenie danych może zostać przeniesione na inne repliki. Kopie zapasowe pozostają potrzebne do odtworzenia po błędach użytkownika, uszkodzeniu logicznym, wymaganiach audytowych oraz sytuacjach, w których wszystkie dostępne repliki zawierają nieprawidłową wersję danych.

Przełączanie ról i dostęp aplikacji

Zmiana repliki podstawowej na pomocniczą jest nazywana przełączeniem awaryjnym albo failover. Przełączenie ręczne może być wykonane planowo, na przykład podczas prac serwisowych. Automatyczny failover jest możliwy wyłącznie przy spełnieniu warunków określonych przez konfigurację grupy, w tym odpowiedniej synchronizacji baz, trybu dostępności i ustawień klastrowych. W środowisku korzystającym z automatycznego przełączania SQL Server współpracuje z mechanizmem Windows Server Failover Clustering, który monitoruje role i stan zasobów.

Do połączeń aplikacji może służyć listener grupy dostępności. Jest to logiczny punkt dostępu obejmujący nazwę sieciową i port, który kieruje ruch do aktualnej repliki podstawowej. Po przełączeniu aplikacja korzystająca z poprawnie skonfigurowanego łańcucha połączenia może ponownie połączyć się przez ten sam adres logiczny. Sam listener nie naprawia jednak błędów aplikacji, DNS, zapory sieciowej ani nieprawidłowo ustawionego czasu oczekiwania na połączenie. Klient musi obsługiwać ponowne nawiązanie sesji, ponieważ istniejące połączenia mogą zostać przerwane podczas zmiany roli.

Repliki pomocnicze mogą być dodatkowo wykorzystywane do odczytu, raportowania albo wykonywania kopii zapasowych, jeżeli pozwala na to ich konfiguracja i edycja SQL Server. Ruch odczytowy może być kierowany przez routing tylko wtedy, gdy aplikacja i połączenie korzystają z odpowiednich ustawień. Nie każda operacja odczytu może być bezpośrednio przeniesiona na replikę pomocniczą, a rozwiązanie nie powinno być oceniane wyłącznie na podstawie tego, że druga kopia bazy odpowiada na połączenia.

Rozpoznawanie problemów w grupie Always On

Diagnostyka grupy dostępności powinna rozpocząć się od ustalenia aktualnej roli każdej repliki, stanu każdej bazy oraz trybu zatwierdzania transakcji. Następnie sprawdza się dzienniki SQL Server, zdarzenia klastra, konfigurację endpointów Database Mirroring oraz łączność pomiędzy instancjami. Endpoint używany przez Always On musi być uruchomiony, dostępny sieciowo i zabezpieczony poprawnie skonfigurowanymi uprawnieniami. Błąd uwierzytelniania lub blokada portu może zatrzymać synchronizację mimo prawidłowego stanu samej bazy.

Typowe symptomy problemu to status NOT SYNCHRONIZING, rosnąca liczba nieprzesłanych rekordów dziennika, opóźnienie odtwarzania, zatrzymany ruch danych albo brak możliwości wykonania failover. Przyczyną może być niedostępna replika, przeciążenie dysków, brak miejsca na woluminie, długie operacje wejścia i wyjścia, problemy z siecią lub niezgodność konfiguracji. W trybie asynchronicznym należy dodatkowo uwzględnić możliwość utraty ostatnich nieprzesłanych transakcji przy wymuszonym przełączeniu. W trybie synchronicznym zbyt wolna replika może natomiast zwiększać czas zatwierdzania transakcji na replice podstawowej.

Ocena poprawności działania wymaga porównania konfiguracji z rzeczywistym przebiegiem zdarzeń. Należy ustalić, czy problem dotyczy całej grupy, jednej repliki, pojedynczej bazy, listenera czy tylko konkretnej aplikacji. Przydatne są widoki dynamicznego zarządzania, między innymi sys.availability_groups, sys.availability_replicas, sys.dm_hadr_availability_replica_states oraz sys.dm_hadr_database_replica_states. Ich wyniki trzeba interpretować razem z logami i informacjami o zasobach systemowych, ponieważ chwilowy status synchronizacji nie zawsze opisuje przyczynę wcześniejszego przerwania replikacji.

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