Co to jest grupa dostępności Always On?

• 04/29/2020
• 14 minut na przeczytanie
• • c
  • M
  • D
  • B
  • v
  • +13

Dotyczy: SQL Server (wszystkie obsługiwane wersje)

Ten temat wprowadza koncepcje grup dostępności Always On, które są centralne dla konfigurowania i zarządzania jedną lub wieloma grupami dostępności w SQL Server. Aby uzyskać podsumowanie korzyści oferowanych przez grupy dostępności i przegląd terminologii grup dostępności Always On, zobacz Always On Availability Groups (SQL Server).

Grupa dostępności obsługuje replikowane środowisko dla dyskretnego zestawu baz danych użytkowników, zwanych bazami dostępności. Można utworzyć grupę dostępności dla wysokiej dostępności (HA) lub dla skali odczytu. Grupa dostępności HA to grupa baz danych, które razem ulegają awarii. Grupa dostępności dla skali odczytu to grupa baz danych, które są kopiowane do innych instancji SQL Server dla obciążenia tylko do odczytu. Grupa dostępności obsługuje jeden zestaw podstawowych baz danych oraz od jednego do ośmiu zestawów odpowiadających im baz drugorzędnych. Wtórne bazy danych nie są kopiami zapasowymi. Należy kontynuować regularne tworzenie kopii zapasowych baz danych i ich dzienników transakcji.

Każdy zestaw baz danych dostępności jest hostowany przez replikę dostępności. Istnieją dwa rodzaje replik dostępności: pojedyncza replika główna, która hostuje podstawowe bazy danych oraz od jednej do ośmiu replik drugorzędnych, z których każda hostuje zestaw drugorzędnych baz danych i służy jako potencjalne cele awaryjne dla grupy dostępności. Grupa dostępności ulega awarii na poziomie repliki dostępności. Replika dostępności zapewnia redundancję tylko na poziomie bazy danych dla zbioru baz danych w jednej grupie dostępności. Awarie nie są powodowane przez problemy z bazami danych, takie jak podejrzana baza danych z powodu utraty pliku danych lub uszkodzenia dziennika transakcji.

Podstawowa replika udostępnia podstawowe bazy danych dla połączeń typu odczyt-zapis od klientów. Replika pierwotna wysyła rekordy dziennika transakcji każdej pierwotnej bazy danych do każdej wtórnej bazy danych. Proces ten – znany jako synchronizacja danych – zachodzi na poziomie bazy danych. Każda replika wtórna buforuje zapisy dziennika transakcji (utwardza dziennik), a następnie stosuje je do odpowiadającej jej wtórnej bazy danych. Synchronizacja danych zachodzi pomiędzy główną bazą danych a każdą podłączoną bazą drugorzędną, niezależnie od innych baz danych. W związku z tym wtórna baza danych może zostać zawieszona lub ulec awarii bez wpływu na inne wtórne bazy danych, a pierwotna baza danych może zostać zawieszona lub ulec awarii bez wpływu na inne pierwotne bazy danych.

Opcjonalnie można skonfigurować jedną lub więcej replik wtórnych, aby obsługiwały dostęp tylko do odczytu do wtórnych baz danych, a także można skonfigurować dowolną replikę wtórną, aby zezwalała na tworzenie kopii zapasowych na wtórnych bazach danych.

SQL Server 2017 wprowadza dwie różne architektury dla grup dostępności. Grupy dostępności Always On zapewniają wysoką dostępność, odzyskiwanie po awarii oraz równoważenie skali odczytu. Te grupy dostępności wymagają menedżera klastra. W systemie Windows menedżerem klastra jest klaster failover. W systemie Linux można użyć programu Pacemaker. Inną architekturą jest grupa dostępności w skali odczytu. Grupa dostępności w skali odczytu zapewnia repliki dla obciążeń tylko do odczytu, ale nie zapewnia wysokiej dostępności. W grupie dostępności w skali odczytu nie ma menedżera klastra.

Deponowanie grup dostępności Always On dla HA w systemie Windows wymaga Windows Server Failover Cluster(WSFC). Każda replika danej grupy dostępności musi znajdować się na innym węźle tego samego WSFC. Jedynym wyjątkiem jest to, że podczas migracji do innego klastra WSFC, grupa dostępności może tymczasowo znajdować się pomiędzy dwoma klastrami.

W konfiguracji HA, rola klastra jest tworzona dla każdej utworzonej grupy dostępności. Klaster WSFC monitoruje tę rolę, aby ocenić stan zdrowia repliki podstawowej. Kworum dla grup dostępności Always On opiera się na wszystkich węzłach w klastrze WSFC, niezależnie od tego, czy dany węzeł klastra hostuje jakiekolwiek repliki dostępności. W przeciwieństwie do mirroringu bazy danych, w grupach dostępności Always On nie ma roli świadka.

Następująca ilustracja przedstawia grupę dostępności, która zawiera jedną replikę pierwotną i cztery repliki wtórne. Obsługiwanych jest do ośmiu replik drugorzędnych, w tym jedna replika podstawowa i dwie repliki drugorzędne synchronous-commit.

Dostępne bazy danych

Aby dodać bazę danych do grupy dostępności, baza danych musi być bazą danych online, z możliwością odczytu i zapisu, istniejącą na instancji serwera, która hostuje replikę podstawową. Gdy dodajesz bazę danych, dołącza ona do grupy dostępności jako baza podstawowa, pozostając dostępną dla klientów. Nie istnieje odpowiednia drugorzędna baza danych, dopóki kopie zapasowe nowej bazy danych nie zostaną przywrócone na instancję serwera, na której znajduje się replika drugorzędna (za pomocą polecenia RESTORE WITH NORECOVERY). Nowa wtórna baza danych znajduje się w stanie RESTORING, dopóki nie zostanie dołączona do grupy dostępności. Aby uzyskać więcej informacji, zobacz temat Rozpoczynanie przenoszenia danych na zawsze włączonej wtórnej bazie danych (SQL Server).

Połączenie powoduje przejście wtórnej bazy danych do stanu ONLINE i rozpoczęcie synchronizacji danych z odpowiednią bazą pierwotną. Synchronizacja danych jest procesem, w którym zmiany w głównej bazie danych są odtwarzane na bazie wtórnej. Synchronizacja danych polega na wysyłaniu przez pierwotną bazę danych zapisów dziennika transakcji do wtórnej bazy danych.

Repliki dostępności

Każda grupa dostępności definiuje zestaw dwóch lub więcej partnerów failover znanych jako repliki dostępności. Repliki dostępności są składnikami grupy dostępności. Każda replika dostępności hostuje kopię baz danych dostępności w grupie dostępności. Dla danej grupy dostępności, repliki dostępności muszą być hostowane przez oddzielne instancje SQL Server rezydujące na różnych węzłach klastra WSFC. Każda z tych instancji serwera musi mieć włączoną opcję Always On.

Dana instancja może hostować tylko jedną replikę dostępności na grupę dostępności. Jednak każda instancja może być używana dla wielu grup dostępności. Dana instancja może być zarówno samodzielną instancją, jak i instancją klastra SQL Server failover (FCI). Jeśli wymagana jest redundancja na poziomie serwera, należy użyć instancji Failover Cluster.

Każda replika dostępności ma przypisaną rolę początkową – primary lub secondary, która jest dziedziczona przez bazy dostępności tej repliki. Rola danej repliki określa czy hostuje ona bazy danych typu read-write czy read-only. Jedna replika, zwana repliką podstawową, ma przypisaną rolę podstawową i hostuje bazy danych odczytu-zapisu, które są znane jako podstawowe bazy danych. Co najmniej jedna inna replika, zwana repliką drugorzędną, ma przypisaną rolę drugorzędną. Replika drugorzędna jest gospodarzem baz danych tylko do odczytu, zwanych bazami drugorzędnymi.

Tryby dostępności

Tryb dostępności jest właściwością każdej repliki dostępności. Tryb dostępności określa, czy replika pierwotna czeka na zatwierdzenie transakcji na bazie danych do czasu, aż dana replika wtórna zapisze rekordy dziennika transakcji na dysku (utwardzi dziennik). Grupy dostępności Always On obsługują dwa tryby dostępności-asynchronous-commit mode i synchronous-commit mode.

• Asynchronous-commit mode

  Replika dostępności, która korzysta z tego trybu dostępności, jest znana jako replika asynchronous-commit. W trybie asynchronous-commit replika pierwotna wykonuje transakcje bez oczekiwania na potwierdzenie, że replika wtórna asynchronous-commit utwardziła dziennik. Tryb asynchronous-commit minimalizuje opóźnienia transakcji na drugorzędnych bazach danych, ale pozwala im pozostawać w tyle za głównymi bazami danych, przez co możliwa jest utrata niektórych danych.

• Tryb synchronous-commit

  Replika dostępności, która używa tego trybu dostępności, jest znana jako replika synchronous-commit. W trybie synchronous-commit mode, przed zleceniem transakcji, replika synchronous-commit primary czeka na potwierdzenie przez replikę synchronous-commit secondary, że zakończyła utwardzanie dziennika. Tryb synchronous-commit zapewnia, że gdy dana drugorzędna baza danych jest zsynchronizowana z bazą podstawową, dokonane transakcje są w pełni chronione. Ochrona ta odbywa się kosztem zwiększonego opóźnienia transakcji.

Więcej informacji można znaleźć w temacie Tryby dostępności (grupy dostępności Always On).

Rodzaje failover

W kontekście sesji pomiędzy repliką główną a repliką drugorzędną, role główna i drugorzędna są potencjalnie wymienne w procesie zwanym failover. Podczas przełączania awaryjnego docelowa replika drugorzędna przechodzi do roli głównej, stając się nową repliką główną. Nowa replika główna udostępnia swoje bazy danych w trybie online jako podstawowe bazy danych, a aplikacje klienckie mogą się z nimi łączyć. Gdy poprzednia replika główna jest dostępna, przechodzi do roli drugorzędnej, stając się repliką drugorzędną. Poprzednie podstawowe bazy danych stają się bazami drugorzędnymi, a synchronizacja danych zostaje wznowiona.

Istnieją trzy formy przełączania awaryjnego – automatyczna, ręczna i wymuszona (z możliwą utratą danych). Forma lub formy przełączania awaryjnego obsługiwane przez daną replikę wtórną zależą od jej trybu dostępności, a w przypadku trybu synchronicznego-komitetu od trybu awaryjnego repliki pierwotnej i docelowej repliki wtórnej, w następujący sposób.

• Tryb synchronicznego-komitetu obsługuje dwie formy przełączania awaryjnego – planowane ręczne przełączanie awaryjne i automatyczne przełączanie awaryjne, jeśli docelowa replika wtórna jest aktualnie zsynchronizowana z repliką pierwotną. Obsługa tych form przełączania awaryjnego zależy od ustawienia właściwości trybu awaryjnego na partnerach przejmujących. Jeśli tryb awaryjny jest ustawiony na „ręczny” na replikę główną lub drugorzędną, to tylko ręczne przełączanie awaryjne jest obsługiwane dla tej repliki drugorzędnej. Jeśli tryb awaryjny jest ustawiony na „automatyczny” zarówno na replikach głównych, jak i drugorzędnych, obsługiwane jest zarówno automatyczne, jak i ręczne przełączanie awaryjne na tej replikę drugorzędną.

  • Planowane ręczne przełączanie awaryjne (bez utraty danych)

    Przełączenie ręczne następuje po wydaniu przez administratora bazy danych polecenia przełączenia awaryjnego i powoduje przejście zsynchronizowanej repliki drugorzędnej do roli głównej (z gwarantowaną ochroną danych), a repliki głównej do roli drugorzędnej. Ręczne przełączenie awaryjne wymaga, aby zarówno replika główna, jak i docelowa replika drugorzędna działały w trybie synchronous-commit, a replika drugorzędna musi być już zsynchronizowana.

  • Automatyczne przełączenie awaryjne (bez utraty danych)

    Automatyczne przełączenie awaryjne następuje w odpowiedzi na awarię, która powoduje przejście zsynchronizowanej repliki drugorzędnej do roli głównej (z gwarantowaną ochroną danych). Gdy poprzednia replika główna staje się dostępna, przechodzi do roli drugorzędnej. Automatyczne przełączanie awaryjne wymaga, aby zarówno replika główna, jak i docelowa replika drugorzędna działały w trybie synchronous-commit z trybem przełączania awaryjnego ustawionym na „Automatic”. Ponadto replika drugorzędna musi być już zsynchronizowana, posiadać kworum WSFC oraz spełniać warunki określone w elastycznej polityce failover grupy dostępności.

    Ważne

    Instancje Failover Cluster serwera MySQL (FCI) nie obsługują automatycznego failover przez grupy dostępności, dlatego repliki dostępności hostowane przez FCI mogą być skonfigurowane tylko do ręcznego failover.

  Uwaga

  Zauważ, że jeśli wydasz polecenie wymuszonego przełączenia awaryjnego na zsynchronizowanej replikę wtórną, replika wtórna zachowuje się tak samo jak w przypadku planowanego ręcznego przełączenia awaryjnego.

• W trybie asynchronous-commit jedyną formą przełączania awaryjnego jest wymuszone przełączanie ręczne (z możliwą utratą danych), zwykle nazywane wymuszonym przełączaniem awaryjnym. Wymuszone przełączanie awaryjne jest uważane za formę ręcznego przełączania awaryjnego, ponieważ może być zainicjowane tylko ręcznie. Wymuszone przełączanie awaryjne jest opcją odzyskiwania danych po awarii. Jest to jedyna forma przełączania awaryjnego, która jest możliwa, gdy docelowa replika drugorzędna nie jest zsynchronizowana z repliką podstawową.

Więcej informacji można znaleźć w sekcji Przełączanie awaryjne i tryby przełączania awaryjnego (grupy dostępności Always On).

Połączenia klienckie

Można zapewnić łączność klienta z repliką podstawową danej grupy dostępności, tworząc listener grupy dostępności. Słuchacz grupy dostępności zapewnia zestaw zasobów, który jest dołączony do danej grupy dostępności, aby kierować połączenia klientów do odpowiedniej repliki dostępności.

Słuchacz grupy dostępności jest powiązany z unikalną nazwą DNS, która służy jako nazwa sieci wirtualnej (VNN), jeden lub więcej wirtualnych adresów IP (VIP) oraz numer portu TCP. Więcej informacji znajdziesz w temacie Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

Aktywne repliki drugorzędne

Grupy dostępności Always On obsługują aktywne repliki drugorzędne. Możliwości aktywnych replik drugorzędnych obejmują obsługę:

• Wykonywanie operacji tworzenia kopii zapasowych na replikach drugorzędnych

  Repliki drugorzędne obsługują wykonywanie kopii zapasowych logów i kopii zapasowych całej bazy danych, pliku lub grupy plików. Można skonfigurować grupę dostępności, aby określić preferencje dotyczące miejsca wykonywania kopii zapasowych. Ważne jest, aby zrozumieć, że preferencje te nie są wymuszane przez SQL Server, więc nie mają wpływu na wykonywanie kopii zapasowych ad hoc. Interpretacja tych preferencji zależy od logiki, jeśli takowa istnieje, jaką wpiszemy w zadania tworzenia kopii zapasowych dla każdej z baz danych w danej grupie dostępności. Dla pojedynczej repliki dostępności można określić priorytet wykonywania kopii zapasowych na tej replice w stosunku do innych replik w tej samej grupie dostępności. Więcej informacji znajdziesz w rozdziale Aktywne repliki drugorzędne: Backup on Secondary Replicas (Always On Availability Groups).

• Dostęp tylko do odczytu do jednej lub więcej replik drugorzędnych (repliki drugorzędne do odczytu)

  Każdą drugorzędną replikę dostępności można skonfigurować tak, aby zezwalała tylko na dostęp tylko do odczytu do swoich lokalnych baz danych, chociaż niektóre operacje nie są w pełni obsługiwane. Zapobiegnie to próbom połączenia z repliką drugorzędną w trybie odczytu i zapisu. Możliwe jest również uniemożliwienie pracy w trybie tylko do odczytu na replice głównej poprzez zezwolenie na dostęp tylko do odczytu i zapisu. Uniemożliwi to wykonywanie połączeń tylko do odczytu z repliką podstawową. Aby uzyskać więcej informacji, zobacz sekcję Aktywne repliki wtórne: Readable Secondary Replicas (Always On Availability Groups).

  Jeśli grupa dostępności posiada obecnie nasłuch grupy dostępności i jedną lub więcej replik wtórnych z możliwością odczytu, SQL Server może kierować żądania połączeń tylko do odczytu do jednej z nich (routing tylko do odczytu). Więcej informacji znajdziesz w rozdziale Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

Okres wyłączenia sesji

Okres wyłączenia sesji jest właściwością availability-replica, która określa jak długo połączenie z inną repliką dostępności może pozostać nieaktywne zanim połączenie zostanie zamknięte. Repliki pierwotna i wtórna pingują się wzajemnie, aby zasygnalizować, że są nadal aktywne. Otrzymanie pinga od drugiej repliki podczas okresu timeout wskazuje, że połączenie jest nadal otwarte i że instancje serwera komunikują się ze sobą. Po otrzymaniu pingu replika dostępności resetuje swój licznik session-timeout na tym połączeniu.

Okres session-timeout zapobiega sytuacji, w której któraś z replik czeka w nieskończoność na otrzymanie pingu od drugiej repliki. Jeśli w czasie trwania sesji nie zostanie odebrany żaden ping od drugiej repliki, replika przestaje działać. Połączenie jest zamykane, a replika, która utraciła czas oczekiwania, przechodzi w stan DISCONNECTED. Nawet jeśli rozłączona replika jest skonfigurowana w trybie synchronous-commit, transakcje nie będą czekać na ponowne połączenie i resynchronizację tej repliki.

Domyślny czas zakończenia sesji dla każdej repliki dostępności wynosi 10 sekund. Wartość ta jest konfigurowalna przez użytkownika, przy czym minimalna wartość może wynosić 5 sekund. Ogólnie zalecamy utrzymywanie okresu time-out na poziomie 10 sekund lub wyższym. Ustawienie wartości na mniej niż 10 sekund stwarza możliwość, że mocno obciążony system zgłosi fałszywą awarię.

Automatyczna naprawa stron

Każda replika dostępności próbuje automatycznie odzyskać uszkodzone strony w lokalnej bazie danych poprzez rozwiązywanie pewnych typów błędów uniemożliwiających odczyt strony danych. Jeśli replika drugorzędna nie może odczytać strony, żąda ona świeżej kopii strony od repliki podstawowej. Jeśli replika główna nie może odczytać strony, replika rozgłasza żądanie świeżej kopii do wszystkich replik drugorzędnych i pobiera stronę od pierwszej, która odpowie. Jeśli to żądanie się powiedzie, nieczytelna strona zostaje zastąpiona kopią, co zazwyczaj rozwiązuje problem.

Więcej informacji można znaleźć w temacie Automatyczna naprawa stron (Grupy dostępności: Mirroring bazy danych).

Powiązane zadania

• Getting Started with Always On Availability Groups (SQL Server)

Powiązana zawartość

• Blogi:

  Always On – HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases

  Serwer SQL Always On Team Blogs: The official SQL Server Always On Team Blog

  CSS SQL Server Engineers Blogs

• Videos:

  Microsoft SQL Server Code-Named „Denali” Always On Series,Part 1: Introducing the Next Generation High Availability Solution

  Microsoft SQL Server Code-Named „Denali” Always On Series,Part 2: Building a Mission-Critical High Availability Solution Using Always On

• Whitepapers:

  Microsoft SQL Server Always On Solutions Guide for High Availability and Disaster Recovery

  Microsoft White Papers for SQL Server 2012

  SQL Server Customer Advisory Team. Whitepapers

Zobacz także

Tryby dostępności (Always On Availability Groups)
Tryby awaryjne i Failover (Always On Availability Groups)
Overview of Transact-SQL dla Always On Availability Groups (SQL Server)
Przegląd poleceń PowerShell dla Always On Availability Groups (SQL Server)
Wysoka dostępność dla baz danych In-Memory OLTP
Warunki wstępne, Ograniczenia i zalecenia dla grup dostępności Always On (SQL Server)
Tworzenie i konfiguracja grup dostępności (SQL Server)
Active Secondaries: Readable Secondary Replicas (Always On Availability Groups)
Active Secondaries: Kopie zapasowe na drugorzędnych replikach (zawsze włączone grupy dostępności)
Słuchawki grup dostępności, łączność z klientami i awaryjność aplikacji (SQL Server)