Wysoka dostępność i ochrona danych dla konfiguracji grup dostępności

Dotyczy:programu SQL Server — Linux

W tym artykule przedstawiono obsługiwane konfiguracje wdrażania dla zawsze włączonych grup dostępności programu SQL Server na serwerach z systemem Linux. Grupa dostępności obsługuje wysoką dostępność i ochronę danych. Automatyczne wykrywanie błędów, automatyczne przełączenie awaryjne i przezroczyste ponowne łączenie po przełączeniu awaryjnym zapewniają wysoką dostępność. Zsynchronizowane repliki zapewniają ochronę danych.

W klastrze trybu failover systemu Windows Server (WSFC) typowa konfiguracja wysokiej dostępności używa dwóch synchronicznych replik i trzeciego serwera lub udziału plików do zapewnienia kworum. Świadek udostępniania plików weryfikuje konfigurację grupy dostępności, na przykład, oceniając stan synchronizacji i rolę repliki. Ta konfiguracja gwarantuje, że replika pomocnicza wybrana jako element docelowy trybu failover ma najnowsze dane i zmiany konfiguracji grupy dostępności.

WSFC synchronizuje metadane konfiguracji na potrzeby arbitrażu przełączenia awaryjnego między replikami grupy dostępności a świadkiem udziału plików. Kiedy grupa dostępności nie znajduje się w klastrze WSFC, wystąpienia programu SQL Server przechowują metadane konfiguracji w bazie danych master.

Na przykład grupa dostępności w klastrze systemu Linux ma CLUSTER_TYPE = EXTERNAL. Nie ma WSFC do zarządzania przełączeniem awaryjnym. W takim przypadku metadane konfiguracji są zarządzane i obsługiwane przez wystąpienia programu SQL Server. Ponieważ w tym klastrze nie ma serwera monitora, aby przechowywać metadane stanu konfiguracji, jest wymagana trzecia instancja SQL Server. Wszystkie trzy wystąpienia programu SQL Server razem zapewniają rozproszony magazyn metadanych dla klastra.

Menedżer klastra może wykonywać zapytania dotyczące wystąpień programu SQL Server w grupie dostępności i organizować tryb failover w celu zachowania wysokiej dostępności. W klastrze systemu Linux program Pacemaker jest menedżerem klastra.

Program SQL Server 2017 (14.x) CU 1 zapewnia wysoką dostępność dla grupy dostępności z CLUSTER_TYPE = EXTERNAL dla dwóch replik synchronicznych oraz repliki konfiguracyjnej. Replika konfiguracji może być hostowana tylko w dowolnej wersji programu SQL Server 2017 (14.x) CU 1 lub nowszej wersji (w tym w wersji SQL Server Express). Replika wyłącznie konfiguracji przechowuje informacje o konfiguracji grupy dostępności w bazie danych master, ale nie zawiera baz danych użytkowników w grupie dostępności.

Jak konfiguracja wpływa na domyślne ustawienia zasobów

Program SQL Server 2017 (14.x) wprowadza ustawienie zasobów klastra REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. To ustawienie gwarantuje, że określona liczba replik pomocniczych zapisuje dane transakcji do dziennika przed zatwierdzeniem każdej transakcji przez replikę podstawową. W przypadku korzystania z zewnętrznego menedżera klastra to ustawienie ma wpływ zarówno na wysoką dostępność, jak i ochronę danych. Wartość domyślna ustawienia zależy od architektury w momencie utworzenia zasobu klastra. Podczas instalowania agenta zasobów programu SQL Server — mssql-server-ha — i utworzenia zasobu klastra dla grupy dostępności menedżer klastra wykrywa konfigurację grupy dostępności i ustawia odpowiednio REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

Jeśli konfiguracja jest obsługiwana, parametr agenta zasobów REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT jest ustawiony na wartość zapewniającą wysoką dostępność i ochronę danych. Aby uzyskać więcej informacji, zapoznaj się z sekcją Zrozumieć agenta zasobów SQL Server dla pacemakera.

W poniższych sekcjach opisano domyślne zachowanie zasobu klastra.

Wybierz projekt grupy dostępności, aby spełnić określone wymagania biznesowe dotyczące wysokiej dostępności, ochrony danych i skali odczytu.

W poniższych konfiguracjach opisano wzorce projektowania grupy dostępności i możliwości każdego wzorca. Te wzorce projektowe mają zastosowanie do grup dostępności CLUSTER_TYPE = EXTERNAL w kontekście rozwiązań o wysokiej dostępności.

• trzy synchroniczne repliki
• dwie repliki synchroniczne
• dwie repliki synchroniczne i replika tylko do konfiguracji

Trzy repliki synchroniczne

Ta konfiguracja składa się z trzech synchronicznych replik. Domyślnie zapewnia wysoką dostępność i ochronę danych. Może również zapewnić skalę odczytu.

Grupa dostępności z trzema synchronicznymi replikami może zapewnić skalę odczytu, wysoką dostępność i ochronę danych. W poniższej tabeli opisano zachowanie w zakresie dostępności.

Zachowanie dostępności	skalowanie odczytu	Wysoka dostępność & ochrona danych	Ochrona danych
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0	1 1	2
Główna awaria	Automatyczne przełączanie awaryjne. Może to spowodować utratę danych. Nowy element podstawowy to R/W.	Automatyczne przełączanie awaryjne. Nowy element podstawowy to R/W.	Automatyczne przełączanie awaryjne. Nowy serwer podstawowy nie jest dostępny dla transakcji aktualizacyjnych użytkownika, dopóki były podstawowy nie odzyska i nie dołączy do grupy dostępności jako wtórny.
Awaria jednej repliki pomocniczej	Podstawowy jest R/W.	Podstawowy tryb to odczyt/zapis.	Główna baza danych nie jest dostępna dla transakcji aktualizacji użytkownika, dopóki nie zostanie odzyskana pomocnicza baza danych i dołączona do grupy dostępności.

domyślne ¹

Dwie repliki synchroniczne

Ta konfiguracja umożliwia ochronę danych. Podobnie jak w przypadku innych konfiguracji grup dostępności, może włączyć funkcję skalowania do odczytu. Konfiguracja dwóch synchronicznych replik nie zapewnia automatycznej wysokiej dostępności. Konfiguracja dwóch replik ma zastosowanie tylko do programu SQL Server 2017 (14.x) RTM i nie jest już obsługiwana z nowszymi (CU1 i nowszymi) wersjami programu SQL Server 2017 (14.x).

Grupa dostępności z dwiema synchronicznymi replikami zapewnia ochronę danych i skalowanie odczytu. W poniższej tabeli opisano cechy dostępności.

Zachowanie związane z dostępnością	skalowanie odczytu	Ochrona danych
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0 1	1
Główna awaria	Automatyczne przełączanie awaryjne. Może to spowodować utratę danych. Nowy element podstawowy to R/W.	Automatyczne przełączanie awaryjne. Nowy element podstawowy nie jest dostępny dla transakcji aktualizacji użytkownika, dopóki były podstawowy nie odzyska i nie dołączy do grupy dostępności jako drugorzędny.
Awaria jednej repliki pomocniczej	Główna instancja to R/W, działa z ryzykiem utraty danych.	Główna nie jest dostępna dla transakcji aktualizacji użytkownika, dopóki sekunda nie odzyska sprawności.

domyślne ¹

Dwie repliki synchroniczne i replika wyłącznie do konfiguracji

Grupa dostępności z dwiema (lub więcej) synchronicznymi replikami i repliką konfiguracji zapewnia ochronę danych, a także może zapewnić wysoką dostępność. Na poniższym diagramie przedstawiono tę architekturę:

1. Synchroniczna replikacja danych użytkownika do repliki pomocniczej. Zawiera również metadane konfiguracji grupy dostępności.
2. Synchroniczna replikacja metadanych konfiguracji grupy dostępności. Nie zawiera ona danych użytkownika.

Na diagramie grupy dostępności replika podstawowa przekazuje dane konfiguracji do repliki pomocniczej oraz do repliki zawierającej tylko konfigurację. Replika pomocnicza odbiera również dane użytkownika. Tylko replika konfiguracji nie odbiera danych użytkownika. Replika wtórna jest w trybie dostępności synchronicznej. Replika służąca tylko do konfiguracji nie zawiera baz danych w grupie dostępności — przechowuje jedynie metadane dotyczące tej grupy. Dane konfiguracji w replice przechowującej wyłącznie dane konfiguracyjne są zatwierdzane synchronicznie.

Notatka

Grupa dostępności z repliką tylko do konfiguracji jest nowa dla programu SQL Server 2017 (14.x) CU 1. Wszystkie wystąpienia programu SQL Server w grupie dostępności muszą być w wersji SQL Server 2017 (14.x) CU 1 lub nowszej.

Wartość domyślna REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT to 0. Zachowanie dotyczące dostępności opisano w poniższej tabeli.

Zachowanie dostępności	Wysoka dostępność & ochrona danych	Ochrona danych
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0 1	1
Główna awaria	Automatyczne przełączanie awaryjne. Nowy element podstawowy to R/W. Może to spowodować utratę danych.	Automatyczne przełączanie awaryjne. Nowy podstawowy nie jest dostępny dla aktualizacji transakcji użytkownika.
Awaria repliki wtórnej	Tryb podstawowy jest R/W, działa narażona na utratę danych (jeśli podstawowy system zawiedzie i nie można go będzie odzyskać). Nie ma automatycznego przełączania awaryjnego, jeśli podstawowy również ulegnie awarii.	Podstawowa nie jest dostępna dla transakcji aktualizacji użytkownika. Brak repliki do przejścia w tryb failover w przypadku awarii podstawowej.
Awaria repliki ograniczona do konfiguracji	Podstawowy jest R/W. Nie ma automatycznego przełączenia awaryjnego, jeśli system główny również zawiedzie.	Tryb podstawowy to R/W. Brak automatycznego przełączenia, jeśli podstawowy system również zawiedzie.
Awaria synchronicznej repliki podrzędnej oraz repliki tylko konfiguracyjnej	Podstawowa nie jest dostępna dla transakcji aktualizacji użytkownika. Brak automatycznego przełączania awaryjnego.	Funkcja podstawowa nie jest dostępna dla transakcji aktualizacji użytkownika. Brak repliki do przejścia w tryb failover w przypadku awarii podstawowej.

domyślne ¹

Nota

Wystąpienie programu SQL Server, które hostuje tylko replikę konfiguracji, może również hostować inne bazy danych. Może również działać wyłącznie jako baza danych konfiguracji dla więcej niż jednej grupy dostępności.

Wymagania

• Wszystkie repliki w grupie dostępności, które mają replikę tylko do konfiguracji, muszą działać na SQL Server 2017 (14.x) CU 1 lub nowszych wersjach.
• Dowolna wersja programu SQL Server może hostować tylko replikę konfiguracji, w tym program SQL Server Express.
• Grupa dostępności wymaga co najmniej jednej repliki pomocniczej — oprócz repliki podstawowej.
• Repliki wyłącznie do konfiguracji nie są liczone do maksymalnej liczby replik na wystąpienie programu SQL Server. Wersja Standardowa programu SQL Server umożliwia maksymalnie trzy repliki— program SQL Server Enterprise Edition umożliwia maksymalnie 9.

Zagadnienia dotyczące

• Nie więcej niż jedna konfiguracja repliki tylko na grupę dostępności.
• Replika przeznaczona wyłącznie do konfiguracji nie może być repliką główną.
• Nie można zmodyfikować trybu dostępności repliki wyłącznie konfiguracyjnej. Aby zmienić replikę wyłącznie konfiguracyjną na synchroniczną lub asynchroniczną replikę pomocniczą, usuń replikę wyłącznie konfiguracyjną i dodaj replikę pomocniczą o wymaganym trybie dostępności.
• Replika tylko konfiguracji jest synchroniczna z metadanymi grupy dostępności. Brak danych użytkownika.
• Grupa dostępności z jedną repliką podstawową i jedną repliką wyłącznie konfiguracyjną, ale bez żadnej repliki pomocniczej, nie jest prawidłowa.
• Nie można utworzyć grupy dostępności w wystąpieniu programu SQL Server Express.

Omówienie agenta zasobów programu SQL Server dla programu Pacemaker

SQL Server 2017 (14.x) wprowadził sequence_number i sys.availability_groups, aby pokazać, czy replika oznaczona jako SYNCHRONOUS_COMMIT była aktualna. sequence_number jest monotonicznie zwiększającym bigINT, który reprezentuje, jak up-to-date lokalna replika grupy dostępności jest w odniesieniu do pozostałych replik w grupie dostępności. Wykonywanie przełączeń awaryjnych, dodawanie lub usuwanie replik oraz inne operacje w grupach dostępności aktualizują tę liczbę. Liczba jest aktualizowana na serwerze podstawowym, a następnie przekazywana do replik pomocniczych. W związku z tym replika pomocnicza up-to-date ma taki sam sequence_number jak replika główna.

Gdy program Pacemaker zdecyduje się podwyższyć poziom repliki do wersji podstawowej, najpierw wysyła powiadomienie do wszystkich replik w celu wyodrębnienia numeru sekwencji i zapisania go (to powiadomienie jest nazywane powiadomieniem przed podwyższeniem poziomu). Następnie, gdy program Pacemaker próbuje przekształcić replikę w replikę podstawową, zostaje ona przekształcona tylko wtedy, gdy jej numer sekwencji jest najwyższy ze wszystkich numerów sekwencji ze wszystkich replik, w przeciwnym razie odrzuca operację przekształcenia. W ten sposób można awansować tylko replikę z najwyższym numerem sekwencji do podstawowego, zapewniając brak utraty danych.

Awans jest gwarantowany tylko pod warunkiem, że co najmniej jedna replika dostępna do awansu ma ten sam numer sekwencji co poprzednia instancja podstawowa. Domyślne zachowanie polega na tym, że agent zasobów Pacemaker automatycznie ustawia REQUIRED_COPIES_TO_COMMIT tak, aby co najmniej jedna druga replika pomocnicza zatwierdzenia synchronicznego była aktualna i dostępna, jako cel automatycznego przełączenia awaryjnego. Przy każdym działaniu monitorującym wartość REQUIRED_COPIES_TO_COMMIT jest obliczana (i aktualizowana w razie potrzeby) jako (liczba synchronicznych replik potwierdzenia / 2). Następnie, w momencie przełączenia awaryjnego, agent zasobów wymaga (total number of replicas - required_copies_to_commit replik) odpowiedzi na powiadomienie przed promowaniem, aby móc promować jedną z nich do poziomu podstawowego. Replika o najwyższym sequence_number jest awansowana do podstawowej.

Rozważmy na przykład przypadek grupy dostępności z trzema synchronicznymi replikami — jedną repliką podstawową i dwie repliki pomocnicze zatwierdzania synchronicznego.

• REQUIRED_COPIES_TO_COMMIT jest 3 / 2 = 1

• Wymagana liczba replik do reagowania na akcję przed podwyższeniem poziomu wynosi 3 – 1 = 2. W związku z tym, aby wyzwolić przełączenie awaryjne, muszą być uruchomione dwie repliki. Jeśli wystąpi awaria główna, a jedna z replik pomocniczych nie odpowiada i tylko jedna z pozostałych replik odpowiada na akcję przed promowaniem, agent zasobów nie może zagwarantować, że replika, która odpowiedziała, ma najwyższy sequence_number, i tryb failover nie zostanie wyzwolony.

Użytkownik może wybrać zastąpienie domyślnego zachowania i skonfigurować zasób grupy dostępności tak, aby nie ustawiał REQUIRED_COPIES_TO_COMMIT automatycznie, jak pokazano wcześniej.

Ważny

Gdy REQUIRED_COPIES_TO_COMMIT jest 0, istnieje ryzyko utraty danych. W przypadku awarii podstawowego zasobu agent zasobów nie będzie automatycznie wyzwalał przełączenia awaryjnego. Użytkownik musi zdecydować, czy chce poczekać, aż system podstawowy zostanie odzyskany, czy przełączyć się ręcznie w tryb awaryjny.

Aby ustawić REQUIRED_COPIES_TO_COMMIT na 0, uruchom polecenie:

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

Równoważne polecenie używające crm (w systemie SLES) to:

sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0

Aby przywrócić domyślną obliczoną wartość, uruchom polecenie:

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Notatka

Aktualizowanie właściwości zasobu powoduje zatrzymanie i ponowne uruchomienie wszystkich replik. Oznacza to, że rola podstawowa zostanie tymczasowo zdegradowana do pomocniczej, a następnie ponownie awansowana, co spowoduje tymczasową niedostępność do zapisu. Nowa wartość dla REQUIRED_COPIES_TO_COMMIT zostanie ustawiona tylko po ponownym uruchomieniu replik, więc nie nastąpi natychmiast po uruchomieniu polecenia pcs.

Równoważenie wysokiej dostępności i ochrony danych

Powyższe zachowanie domyślne dotyczy również dwóch synchronicznych replik (podstawowej i pomocniczej). Program Pacemaker domyślnie REQUIRED_COPIES_TO_COMMIT = 1, aby upewnić się, że replika pomocnicza jest zawsze aktualna w celu zapewnienia maksymalnej ochrony danych.

Ostrzeżenie

Wiąże się to z większym ryzykiem niedostępności repliki podstawowej z powodu planowanych lub nieplanowanych awarii w działaniu wtórnym. Użytkownik może zmienić domyślne zachowanie agenta zasobów i zastąpić REQUIRED_COPIES_TO_COMMIT0:

sudo pcs resource update <ag1> required_copies_to_commit=0

Po zastąpieniu agent zasobów używa nowego ustawienia dla REQUIRED_COPIES_TO_COMMIT i zatrzymuje jego przetwarzanie. Użytkownicy muszą odpowiednio zaktualizować ją (na przykład jeśli zwiększą liczbę replik).

W poniższych tabelach opisano wynik awarii replik podstawowych lub pomocniczych w różnych konfiguracjach zasobów grupy dostępności:

Grupa dostępności — dwie repliki synchroniczne

Konfiguracja	Główna awaria	Awaria jednej repliki pomocniczej
REQUIRED_COPIES_TO_COMMIT = 0	Użytkownik musi wydać ręcznie FAILOVER. Może to spowodować utratę danych. Nowy element podstawowy to R/W	Podstawowa to R/W, działająca w warunkach narażenia na utratę danych.
REQUIRED_COPIES_TO_COMMIT = 1 1	Automatyczne problemy z klastrem FAILOVER Brak utraty danych. Nowy serwer podstawowy odrzuca wszystkie połączenia, dopóki poprzedni serwer podstawowy nie odzyska sprawności i nie dołączy do grupy dostępności jako serwer pomocniczy.	Podstawowy odrzuca wszystkie połączenia, dopóki zapasowy nie odzyska sprawności.

¹ domyślne zachowanie agenta zasobów dla SQL Server w programie Pacemaker.

Grupa dostępności — trzy repliki synchroniczne

Konfiguracja	Główna awaria	Awaria jednej repliki pomocniczej
REQUIRED_COPIES_TO_COMMIT = 0	Użytkownik musi ręcznie wydać polecenie FAILOVER. Może to spowodować utratę danych. Nowy element bazowy to R/W	Główna funkcja to Odczyt/Zapis
REQUIRED_COPIES_TO_COMMIT = 1 1	Klaster automatycznie wystawia FAILOVER. Brak utraty danych. Nowy element podstawowy to RW	Podstawowa funkcja to odczyt/zapis

¹ agent zasobów SQL Server dla domyślnego zachowania Pacemaker.

Powiązana zawartość

• grupy dostępności programu SQL Server w systemie Linux