Udostępnij za pośrednictwem

Różnice między trybami dostępności dla grupy dostępności Always On

  • Artykuł

Dotyczy:programu SQL Server

W grupach dostępności Always On tryb dostępności jest właściwością repliki, która określa, czy dana replika dostępności może działać w trybie synchronicznego zatwierdzania. Dla każdej repliki dostępności tryb dostępności musi być skonfigurowany dla trybu zatwierdzania synchronicznego, trybu asynchronicznego lub tylko trybu konfiguracji. Jeśli replika podstawowa jest skonfigurowana w trybie zatwierdzania asynchronicznego, nie czeka na zapisanie na dysku przychodzących rekordów dziennika transakcji (aby zabezpieczyć dziennik). Jeśli dana replika pomocnicza jest skonfigurowana na potrzeby trybu zatwierdzania asynchronicznego, replika podstawowa nie czeka, aż ta replika pomocnicza utrwali dane w dzienniku. Jeśli zarówno replika podstawowa, jak i dana replika pomocnicza są skonfigurowane dla trybu zatwierdzania synchronicznego, replika podstawowa czeka na replikę pomocniczą, aby potwierdzić, że utrwaliła dziennik (chyba że replika pomocnicza nie może wysłać pingu do repliki podstawowej w okresie limitu czasu sesji podstawowej).

Uwaga

Jeśli okres limitu czasu sesji repliki podstawowej zostanie przekroczony przez replikę pomocniczą, replika podstawowa tymczasowo przejdzie w tryb zatwierdzania asynchronicznego dla tej repliki pomocniczej. Gdy replika pomocnicza ponownie łączy się z repliką podstawową, wznawiają tryb zatwierdzania synchronicznego.

Obsługiwane tryby dostępności

Grupy dostępności Always On obsługują trzy tryby dostępności:

  • Tryb zatwierdzania asynchronicznego
  • Tryb zatwierdzania synchronicznego
  • Tylko tryb konfiguracji

Tryb zatwierdzania asynchronicznego to rozwiązanie odzyskiwania po awarii, które działa dobrze, gdy repliki dostępności są rozproszone na znaczne odległości. Jeśli każda replika pomocnicza jest uruchomiona w trybie zatwierdzania asynchronicznego, replika podstawowa nie czeka na żadną replikę pomocniczą, aby utrwalić dziennik. Zamiast tego natychmiast po zapisaniu rekordu dziennika w lokalnym pliku dziennika replika podstawowa wysyła potwierdzenie transakcji do klienta. Replika podstawowa działa z minimalnym opóźnieniem transakcji w odniesieniu do repliki pomocniczej skonfigurowanej dla trybu zatwierdzania asynchronicznego. Jeśli obecny serwer główny jest skonfigurowany dla trybu dostępności zatwierdzania asynchronicznego, zatwierdza transakcje asynchronicznie, niezależnie od indywidualnych ustawień trybu dostępności wszystkich replik pomocniczych.

Aby uzyskać więcej informacji, zobacz Asynchronous-Commit tryb dostępności, w dalszej części tego tematu.

Tryb zatwierdzania synchronicznego kładzie nacisk na wysoką dostępność kosztem wydajności, co prowadzi do zwiększonego opóźnienia transakcji. W trybie zatwierdzania synchronicznego transakcje oczekują na wysłanie potwierdzenia transakcji do klienta, dopóki replika pomocnicza nie zapisze dziennika na dysku. Po rozpoczęciu synchronizacji danych w pomocniczej bazie danych replika pomocnicza rozpoczyna stosowanie przychodzących rekordów dziennika z odpowiedniej podstawowej bazy danych. Gdy tylko każdy rekord dziennika został utrwalony, pomocnicza baza danych przechodzi w stan SYNCHRONIZOWANY. Następnie każda nowa transakcja jest zatwierdzana przez pomocniczą replikę, zanim rekord dziennika zostanie zapisany w lokalnym pliku dziennika. Gdy wszystkie pomocnicze bazy danych danej repliki pomocniczej są synchronizowane, tryb zatwierdzania synchronicznego obsługuje ręczne przejście w tryb failover i, opcjonalnie, automatyczne przełączanie w tryb failover.

Aby uzyskać więcej informacji, zobacz Synchronous-Commit tryb dostępności, w dalszej części tego tematu.

Tryb konfiguracji dotyczy tylko grup dostępności, które nie są w klastrze trybu failover systemu Windows Server. Replika w trybie konfiguracji nie zawiera danych użytkownika. W trybie tylko konfiguracji główna baza danych repliki przechowuje metadane konfiguracji grupy dostępności. Aby uzyskać więcej informacji, zobacz Grupa dostępności z tylko repliką konfiguracji.

Rysunek przedstawia grupę dostępności z pięcioma replikami. Replika podstawowa i jedna replika pomocnicza są skonfigurowane do trybu zatwierdzania synchronicznego z automatycznym trybem failover. Inna replika pomocnicza jest skonfigurowana do trybu zatwierdzania synchronicznego tylko z zaplanowanym ręcznym przełączeniem awaryjnym, a dwie repliki pomocnicze są skonfigurowane dla trybu zatwierdzania asynchronicznego, który obsługuje tylko wymuszone ręczne przełączenie awaryjne (zwykle nazywane wymuszonym przełączeniem awaryjnym).

Tryby dostępności i przełączenia awaryjnego replik

Zachowanie synchronizacji i trybu failover między dwiema replikami dostępności zależy od trybu dostępności obu replik. Na przykład w celu wykonania synchronicznego zatwierdzenia należy skonfigurować zarówno replikę podstawową, jak i replikę pomocniczą na potrzeby zatwierdzenia synchronicznego. Podobnie w przypadku automatycznego trybu failover obie repliki muszą być skonfigurowane do automatycznego przejścia w tryb failover. W związku z tym zachowanie przedstawionego powyżej scenariusza wdrażania można podsumować w poniższej tabeli, w której przedstawiono zachowanie każdej potencjalnej repliki podstawowej:

Aktualna główna replika Automatyczne cele awaryjnego przełączania Zachowanie trybu Synchronous-Commit w określonych warunkach Zachowanie trybu Asynchronous-Commit w kontekście Możliwe automatyczne przejście w tryb failover
01 02 02 i 03 04 Tak
02 01 01 i 03 04 Tak
03 01 i 02 04 Nie.
04 01, 02 i 03 Nie.

Zazwyczaj węzeł 04, jako replika zatwierdzania asynchronicznego, jest wdrażany w miejscu odzyskiwania danych po awarii. Fakt, że węzły 01, 02 i 03 pozostają w trybie zatwierdzania asynchronicznego po przełączeniu na węzeł 04, pomaga zapobiec potencjalnemu pogorszeniu wydajności w grupie dostępności z powodu dużego opóźnienia sieci między dwiema witrynami.

Tryb dostępności zatwierdzania asynchronicznego

W trybie zatwierdzania asynchronicznego replika pomocnicza nigdy nie zostanie zsynchronizowana z repliką podstawową. Mimo że dana pomocnicza baza danych może nadrobić zaległości w odpowiedniej podstawowej bazie danych, każda pomocnicza baza danych może być opóźniana w dowolnym momencie. Tryb zatwierdzania asynchronicznego może być przydatny w scenariuszu odzyskiwania po awarii, w którym replika podstawowa i replika pomocnicza są oddzielone znaczną odległością i nie chcesz, aby małe błędy wpływały na replikę podstawową lub w sytuacjach, gdy wydajność jest ważniejsza niż zsynchronizowana ochrona danych. Ponadto, ponieważ replika podstawowa nie czeka na potwierdzenia z repliki pomocniczej, problemy z repliką pomocniczą nigdy nie wpływają na replikę podstawową.

Replika pomocnicza zatwierdzana asynchronicznie próbuje nadążyć za rekordami dziennika odebranymi z repliki podstawowej. Ale bazy danych wtórnych z asynchronicznym zatwierdzeniem zawsze pozostają niezsynchronizowane i prawdopodobnie nieco opóźniają się względem odpowiednich baz danych podstawowych. Zazwyczaj różnica między drugorzędną bazą danych zatwierdzania asynchronicznego a odpowiednią podstawową bazą danych jest niewielka. Jednak różnica może stać się znacząca, jeśli serwer obsługujący replikę pomocniczą zostanie przeciążony lub sieć działa wolno.

Jedyną formą trybu failover obsługiwanego przez tryb zatwierdzania asynchronicznego jest wymuszone przejście w tryb failover (z możliwością utraty danych). Wymuszanie trybu failover jest ostatecznością przeznaczoną tylko w sytuacjach, w których bieżąca replika podstawowa pozostanie niedostępna przez dłuższy czas, a natychmiastowa dostępność podstawowych baz danych jest bardziej krytyczna niż ryzyko ewentualnej utraty danych. Replika w trybie failover musi być w stanie POMOCNICZYM lub ROZWIĄZYWANIU. Docelowy zasób failover przyjmuje rolę podstawową, a jego kopie baz danych stają się podstawowymi bazami danych. Wszystkie pozostałe pomocnicze bazy danych, wraz z byłymi podstawowymi bazami danych, po ich udostępnieniu, są zawieszone do momentu ręcznego wznowienia ich osobno. W trybie zatwierdzania asynchronicznego wszelkie dzienniki transakcji, które oryginalna replika główna nie zdążyła jeszcze wysłać do byłej repliki pomocniczej, zostaną utracone. Oznacza to, że niektóre lub wszystkie nowe podstawowe bazy danych mogą nie mieć ostatnio zatwierdzonych transakcji. Aby uzyskać więcej informacji na temat działania wymuszonego przełączenia awaryjnego i najlepszych praktyk dotyczących korzystania z niego, zobacz Failover i Tryby Failover (Always On Availability Groups).

Tryb dostępności zatwierdzania synchronicznego

W trybie dostępności zatwierdzania synchronicznego (tryb zatwierdzania synchronicznego) po dołączeniu do grupy dostępności wtórna baza danych dogania odpowiednią podstawową bazę danych i wchodzi w stan SYNCHRONICZNEGO. Pomocnicza baza danych pozostaje zsynchronizowana, o ile synchronizacja danych będzie kontynuowana. Gwarantuje to, że każda transakcja zatwierdzona w danej podstawowej bazie danych jest zatwierdzana w odpowiedniej pomocniczej bazie danych. Gdy wszystkie pomocnicze bazy danych w danej replice pomocniczej są zsynchronizowane, stan zdrowotny synchronizacji repliki pomocniczej jako całości jest ZDROWY.

W tej sekcji:

Czynniki zakłócające synchronizację danych

Po zsynchronizowaniu wszystkich baz danych replika pomocnicza przechodzi w stan W DOBREJ KONDYCJI. Zsynchronizowana replika pomocnicza pozostanie w dobrej kondycji, chyba że wystąpi jedna z następujących sytuacji:

  • Opóźnienie lub usterka sieciowa lub komputerowa powoduje przekroczenie limitu czasu sesji między repliką pomocniczą a repliką podstawową.

    Uwaga

    Aby uzyskać informacje o właściwości czasu sesji dla replik dostępności, zobacz Omówienie Always On Availability Groups (SQL Server).

  • Zawieszasz pomocniczą bazę danych na pomocniczej replice. Replika pomocnicza przestaje być synchronizowana, a jej stan synchronizacji jest oznaczony jako NOT_HEALTHY. Replika pomocnicza nie może odzyskać dobrą kondycję, dopóki zawieszona baza danych repliki pomocniczej nie zostanie wznowiona i ponownie zsynchronizowana lub usunięta z grupy wysokiej dostępności.

  • Dodajesz podstawową bazę danych do grupy dostępności. Poprzednio zsynchronizowane repliki pomocnicze przechodzą w stan synchronizacji o kondycji NOT_HEALTHY. Ten stan wskazuje, że co najmniej jedna baza danych znajduje się w stanie NIE SYNCHRONIZUJE. Dana replika pomocnicza nie może być ponownie w dobrej kondycji, dopóki odpowiednia pomocnicza baza danych nie zostanie przygotowana na replikę, zostanie przyłączona do grupy dostępności i zostanie zsynchronizowana z nową podstawową bazą danych.

  • Zmieniasz replikę podstawową lub replikę pomocniczą na tryb dostępności z zatwierdzaniem asynchronicznym. Po przejściu na tryb zatwierdzania asynchronicznego, replika pomocnicza pozostanie w zdrowej kondycji synchronizacji, o ile synchronizacja danych będzie kontynuowana. Jeśli jednak tylko replika podstawowa zostanie zmieniona na tryb zatwierdzania asynchronicznego, to replika wtórna w trybie zatwierdzania synchronicznego wejdzie w stan kondycji synchronizacji określany jako PARTIALLY_HEALTHY. Ten stan wskazuje, że co najmniej jedna baza danych znajduje się w stanie SYNCHRONIZACJI, ale żadna z baz danych nie jest w stanie NIE SYNCHRONIZACJI.

  • Zmieniasz dowolną replikę pomocniczą na tryb dostępności zatwierdzania synchronicznego. Powoduje to, że replika pomocnicza jest oznaczana jako w stanie synchronizacji PARTIALLY_HEALTHY, dopóki wszystkie jej bazy danych nie przejdą do stanu synchronizacji SYNCHRONIZED.

Wskazówka

Aby wyświetlić kondycję synchronizacji grupy dostępności, repliki dostępności lub bazy danych dostępności, wykonaj zapytanie dotyczące odpowiednio kolumny synchronization_health lub synchronization_health_descsys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states lub sys.dm_hadr_database_replica_states.

Jak działa synchronizacja w repliki pomocniczej

W trybie zatwierdzania synchronicznego po dołączeniu repliki pomocniczej do grupy dostępności i ustanowieniu sesji z repliką podstawową:

  1. Replika pomocnicza zapisuje przychodzące rekordy logu na dysku (utwardza log).
  2. Replika pomocnicza wysyła komunikat potwierdzający do repliki podstawowej.

Po tym, jak utwardzony dziennik w pomocniczej bazie danych dogoni koniec dziennika w podstawowej bazie danych, stan pomocniczej bazy danych jest ustawiony na ZSYNCHRONIZOWANE.

Czas wymagany do synchronizacji zależy od tego, jak daleko pomocnicza baza danych znajdowała się za podstawową bazą danych na początku sesji. Ta delta jest mierzona przez liczbę rekordów dziennika, które początkowo odebrano z podstawowej repliki, obciążenie pracy na podstawowej bazie danych oraz szybkość hosta instancji repliki pomocniczej.

Proces transakcji

W trybie zatwierdzania synchronicznego transakcje są zatwierdzane w obu replikach w następującej kolejności:

  1. Replika podstawowa odbiera transakcję od klienta.

  2. Replika podstawowa zapisuje rekord w dzienniku transakcji i jednocześnie wysyła rekord dziennika do replik pomocniczych.

    Po zapisaniu rekordu do dziennika transakcji bazy danych nadrzędnej, transakcja może zostać cofnięta tylko wtedy, gdy nastąpi przełączenie awaryjne do pomocniczego węzła, który nie otrzymał dziennika.

  3. Replika podstawowa czeka na potwierdzenie od repliki pomocniczej uczestniczącej w synchronicznym zatwierdzaniu.

  4. Replika pomocnicza wzmacnia zabezpieczenia dziennika i zwraca potwierdzenie do repliki podstawowej.

  5. Replika podstawowa kończy proces zatwierdzania i wysyła wiadomość potwierdzającą do klienta.

Limit czasu zatwierdzania synchronicznego

Jeśli przekroczony zostanie limit czasu repliki pomocniczej z zatwierdzaniem synchronicznym bez potwierdzenia, że dziennik został zbuforowany, w grupie dostępności wykonywane są następujące działania:

  1. Replika podstawowa oznacza, że replika pomocnicza zakończyła się niepowodzeniem.
  2. Stan repliki pomocniczej zmienia się na ROZŁĄCZONE.
  3. Główny proces przestaje czekać na potwierdzenie.
  4. Grupa dostępności oznacza stan synchronizacji jako NIE SYNCHRONIZOWANY i stan repliki jako NIEZDROWY.

Takie zachowanie gwarantuje, że awaria pomocniczej repliki z zatwierdzaniem synchronicznym nie uniemożliwia wzmacniania dziennika w replice podstawowej.

Gdy replika pomocnicza powraca do trybu online:

  1. Stan repliki pomocniczej zmienia się na POŁĄCZONY.
  2. Replika pomocnicza przetwarza kolejkę wysyłania dziennika repliki podstawowej.
  3. Stan synchronizacji przechodzi na SYNCHRONIZACJĘ, a stan repliki na PARTIALLY_HEALTHY.

Po przetworzeniu kolejki wysyłania dziennika, stan synchronizacji zmienia się na ZSYNCHRONIZOWANY, a kondycja repliki staje się ZDROWA.

Tryb zatwierdzania synchronicznego chroni dane, wymagając synchronizacji danych między dwoma miejscami, kosztem nieco zwiększenia opóźnienia transakcji.

Tryb zatwierdzania synchronicznego z ręcznym przełączeniem awaryjnym

Gdy te repliki są połączone i baza danych jest synchronizowana, obsługiwana jest ręczna przełączalność awaryjna. Jeśli replika pomocnicza ulegnie awarii, nie ma to wpływu na replikę podstawową. Replika podstawowa działa w trybie odsłoniętym, jeśli nie istnieją żadne repliki zsynchronizowane (to znaczy, bez wysyłania danych do jakiejkolwiek repliki pomocniczej). Jeśli replika podstawowa zostanie utracona, repliki pomocnicze przechodzą w stan ROZWIĄZYWANIA, ale właściciel bazy danych może wymusić przełączenie się na replikę pomocniczą (z możliwością utraty danych). Aby uzyskać więcej informacji, zobacz Failover i tryby failover (Always On Availability Groups).

Tryb zatwierdzania synchronicznego z automatycznym przełączeniem awaryjnym

Automatyczne przełączanie w tryb failover zapewnia wysoką dostępność dzięki zapewnieniu, że baza danych zostanie ponownie udostępniona po utracie repliki podstawowej. Aby skonfigurować grupę dostępności na potrzeby automatycznego trybu failover, należy ustawić zarówno bieżącą replikę podstawową, jak i co najmniej jedną replikę pomocniczą do trybu zatwierdzania synchronicznego z automatycznym trybem failover. Program SQL Server 2019 (15.x) zwiększył maksymalną liczbę replik synchronicznych do 5, z 3 w programie SQL Server 2017 (14.x). Tę grupę pięciu replik można skonfigurować tak, aby w grupie występowało automatyczne przełączanie awaryjne. Istnieje jedna replika podstawowa oraz cztery synchroniczne repliki pomocnicze.

Ponadto aby automatyczne przejście w tryb failover było możliwe w danym momencie, ta replika pomocnicza musi być zsynchronizowana z repliką podstawową (czyli wszystkie pomocnicze bazy danych są synchronizowane), a klaster trybu failover systemu Windows Server (WSFC) musi mieć kworum. Jeśli replika podstawowa stanie się niedostępna w tych warunkach, nastąpi automatyczne przejście w tryb failover. Replika pomocnicza przełącza się do roli podstawowej i oferuje swoją bazę jako główną. Aby uzyskać więcej informacji, zobacz sekcję "Automatyczne przełączenie awaryjne" w temacie Przełączenie awaryjne i tryby przełączania awaryjnego (Grupy dostępności Always On).

Uwaga

Aby uzyskać informacje na temat kworum WSFC i grup dostępności Always On, zobacz Tryby kworum WSFC i konfigurację głosowania (SQL Server).

Opóźnienie danych w repliki pomocniczej

Implementowanie dostępu tylko do odczytu do replik pomocniczych jest przydatne, jeśli obciążenia tylko do odczytu mogą tolerować pewne opóźnienia danych. W sytuacjach, w których opóźnienie danych jest niedopuszczalne, rozważ uruchomienie obciążeń tylko do odczytu względem repliki podstawowej.

Replika podstawowa wysyła rekordy dziennika zmian w podstawowej bazie danych do replik pomocniczych. W każdej pomocniczej bazie danych dedykowany wątek ponownego wdrażania stosuje rekordy dziennika. Na pomocniczej bazie danych o dostępie tylko do odczytu, zmiana danych nie pojawia się w wynikach zapytania, dopóki rekord dziennika zawierający tę zmianę nie zostanie zastosowany do pomocniczej bazy danych oraz dopóki transakcja nie zostanie zatwierdzona w bazie danych głównej.

Oznacza to, że występuje pewne opóźnienie, zwykle tylko kilka sekund między replikami podstawowymi i pomocniczymi. Jednak w nietypowych przypadkach, na przykład jeśli problemy z siecią zmniejszają przepływność, opóźnienie może stać się znaczące. Wzrasta opóźnienie, gdy występują ograniczenia przepustowości wejścia/wyjścia i gdy przenoszenie danych jest zawieszone. Aby monitorować wstrzymany ruch danych, możesz użyć Always On Dashboard lub dynamicznego widoku zarządzania sys.dm_hadr_database_replica_states.

Aby uzyskać więcej informacji na temat badania opóźnienia ponownego wdrażania repliki pomocniczej, zobacz Rozwiązywanie problemów z podstawowymi zmianami, które nie zostały odzwierciedlone w repliki pomocniczej.

Powiązane zadania

Aby zmienić tryb dostępności i tryb failover

Aby dostosować głosy kworum

Aby wykonać ręczne przejście w tryb failover

Aby wyświetlić grupy dostępności, replikę dostępności i stany bazy danych

Powiązana zawartość

Zobacz też

Omówienie grup dostępności Always On (SQL Server)
Tryb awaryjny i tryby awaryjne (Grupy dostępności Always On)
Klaster trybu awaryjnego systemu Windows Server (WSFC) z programem SQL Server