SQL Server Always ON Availability Group to rozwiązanie przeznaczone do osiągnięcia wysokiej dostępności i odzyskiwania po awarii dla baz danych SQL Server. Możemy skonfigurować tę funkcjonalność między instalacjami SQL Server opartymi na Windows, instalacjami SQL Server opartymi na Linuksie, a nawet między instalacjami SQL Server opartymi na Linuksie i Windows.
Grupy dostępności są ściśle zintegrowane z technologiami klastrowymi w formie automatycznego przełączania awaryjnego i ochrony danych poprzez replikację danych do odpowiednich replik pomocniczych. Jednak nie zawsze jest konieczne posiadanie menedżera zasobów klastra do konfigurowania grup dostępności.
Aby skonfigurować grupy dostępności SQL Server, potrzebujemy WSFC – Klaster przełączania awaryjnego Windows Server technologia dla Windows oparte na SQL Server instalacje i PACEMAKER dla Linuksa oparte na SQL Server.
PACEMAKER to menedżer zasobów klastra typu open source, którego możemy użyć do zarządzania zasobami i zapewnienia dostępności systemu w przypadku wystąpienia jakiejkolwiek awarii w systemach Linux.
WSFC to produkt firmy Microsoft opracowany w celu obsługi wymagań klastrów opartych na systemie Windows.
Kiedy spojrzysz na skonfigurowane grupy dostępności w SQL Server dla obu typów systemów operacyjnych, wygląda to podobnie w SQL Server Management Studio.
Jednak w tym artykule wyjaśniono grupy dostępności między serwerem SQL opartym na Ubuntu Linux instalacje przy użyciu PACEMAKER technologii klastrowej, więc rozważę tylko tę konfigurację.
Konfiguracja typu klastra
Jak wspomniałem powyżej, mamy trzy warianty konfiguracji grup dostępności dla SQL Server, w zależności od systemu operacyjnego:
- między instalacjami SQL Server opartymi na systemie Windows;
- pomiędzy instalacjami SQL Server opartymi na Linuksie;
- między mieszanymi typami instalacji SQL Server opartych na systemie Windows i Linux.
Firma Microsoft wprowadziła Cluster_type ustawienie konfiguracji, aby zidentyfikować i skonfigurować odpowiednią technologię klastra dla grup dostępności. Jest to element konfiguracji, który określa, jakiego typu technologii klastra używamy dla grup dostępności, niezależnie od tego, na jakim systemie operacyjnym bazuje instancja SQL Server.
Możesz pobrać i zweryfikować istniejącą konfigurację typu klastra za pomocą widoku dynamicznego zarządzania SQL Server (DMV) sys.availability_groups . Istnieją dwie kolumny o nazwie cluster_type i cluster_type_desc . Możemy przeczytać te kolumny, aby zdefiniować konfigurację typu klastra w konfiguracji grupy dostępności.
To ustawienie konfiguracji ma 3 wartości, aby spełnić wymagania technologii klastra dla każdego wariantu:
WSFC W przypadku instalacji programu SQL Server opartych na systemie Windows należy użyć opcji WSFC (klaster pracy awaryjnej serwera systemu Windows). Nie jest obsługiwane w przypadku instalacji SQL Server opartych na systemie Linux.
ZEWNĘTRZNE . Jeśli konfigurujesz grupy dostępności między instalacjami SQL Server opartymi na systemie Linux, musisz użyć menedżera klastra PACEMAKER i wybrać opcję ZEWNĘTRZNA klaster wpisz . Tryb przełączania awaryjnego musi być również ZEWNĘTRZNY (w WSFC będzie to tryb automatyczny).
BRAK . Jeśli nie chcesz używać żadnej technologii klastrowania dla swoich grup dostępności, wybierz BRAK . Ta opcja ma zastosowanie, jeśli chcesz skonfigurować grupy dostępności między wystąpieniami SQL Server z systemem Linux i Windows. Nawet jeśli w systemie skonfigurowano klastrowanie, po ustawieniu wartości typu klastra na BRAK, grupy dostępności nie będą korzystać z technologii klastrowej. Tryb przełączania awaryjnego dla typu klastra NONE to zawsze Ręczny .
Nowe ustawienie:wymagane do zatwierdzenia zsynchronizowane wtórniki
Począwszy od SQL Server 2017 firma Microsoft wprowadziła nowe ustawienie o nazwie required_synchronized_secondaries_to_commit . Włącza opcję automatycznego przełączania awaryjnego, jeśli typ klastra został skonfigurowany jako ZEWNĘTRZNY dla konfiguracji klastra PACEMAKER.
Wartość tego ustawienia jest ustawiana domyślnie podczas konfigurowania agenta zasobów SQL Server mssql-server-ha i utwórz konfigurację klastra.
Możesz również ręcznie zmodyfikować wartość zgodnie ze swoimi wymaganiami, uruchamiając poniższe polecenie:
--Run below commands to change value for setting required_synchronized_secondaries_to_commit
--AGResourceName is the name of the resource configured for the Availability group
sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<Value>
Uwaga:powyższe ustawienie możemy zmienić tylko za pomocą Pacemaker w systemie Linux. Nie można go zmodyfikować za pomocą instrukcji T-SQL w przypadku wdrożeń opartych na systemie Linux. Jednak w przypadku wdrożeń opartych na systemie Windows możemy zmienić to ustawienie za pomocą instrukcji T-SQL.
Poniżej znajdują się możliwe wartości parametru required_synchronized_secondaries_to_commit
0 – Oznacza to, że repliki wtórne nie muszą być synchronizowane z odpowiednią repliką główną. W związku z tym nie obsługuje automatycznego przełączania awaryjnego. Przełączanie awaryjne należy zainicjować ręcznie, jeśli replika podstawowa ulegnie awarii. Ważne:istnieje ryzyko utraty danych po wybraniu tej wartości do konfiguracji.
1 – Oznacza to, że co najmniej jedna replika pomocnicza musi być w stanie zsynchronizowanym, aby uzyskać automatyczne przełączanie awaryjne.
2 – Oznacza to, że obie repliki wtórne muszą być zsynchronizowane z repliką podstawową. Obsługiwane jest automatyczne przełączanie awaryjne.
Repliki do udziału w grupie dostępności
Liczba replik, które mogą należeć do grupy dostępności, zależy od zainstalowanej wersji SQL Server.
- Serwer SQL Standard edycja obsługuje tylko replikę dwuwęzłową dla grupy dostępności wraz z dodatkową repliką tylko do konfiguracji.
- Serwer SQL Enterprise edycja obsługuje do dziewięciu repliki – jedna główna i osiem drugorzędnych.
Ponieważ SQL Server Standard Edition obsługuje tylko dwie repliki (jedną podstawową i jedną dodatkową), firma Microsoft wprowadziła nową koncepcję o nazwie replika tylko do konfiguracji w SQL Server 2017 CU1, aby uzyskać automatyczne przełączanie awaryjne dla serwerów SQL działających w systemach Linux.
Istnieją dwie możliwe opcje projektowania:
- Trzy repliki synchroniczne. Tę konfigurację można wdrożyć tylko w wersji SQL Server Enterprise. Będą 3 kopie Twoich baz danych dostępności. Ta architektura pozwala na wszystkie 3 funkcje na skalę odczytu, wysoką dostępność i ochronę danych.
- Dwie repliki synchroniczne i replika tylko do konfiguracji. Możesz skonfigurować ten projekt również za pomocą edycji SQL Server Standard, uruchamiając dwie synchroniczne repliki w edycji SQL Server Standard i 3 repliki w edycji SQL Server Express, która działa jako replika tylko do konfiguracji. Jest to ekonomiczny projekt, który obsługuje wysoką dostępność z automatycznym przełączaniem awaryjnym i ochroną bazy danych.
Replika dwuwęzłowa
konfiguracje replik dwuwęzłowych for Availability Groups to bardzo popularna opcja wdrażania zapewniająca wysoką dostępność baz danych SQL Server. Osiągamy automatyczne przełączanie awaryjne za pomocą technologii Windows Server Failover Cluster i monitora udostępniania plików we wdrożeniach SQL Server opartych na systemie Windows.
Udział plików jest zwykle używany w dodatkowym węźle w WSFC w celu zapewnienia konfiguracji kworum dla konfiguracji replik z dwoma węzłami. WSFC synchronizuje wszystkie metadane konfiguracji do obu replik i na trzecim węźle lub monitorze udziału plików, aby zapewnić płynne przełączanie awaryjne. Cały arbitraż dotyczący przełączania awaryjnego dla grupy dostępności SQL Server opartej na systemie Windows odbywa się w warstwie WSFC.
Jeśli chcemy uzyskać automatyczne przełączanie awaryjne dla wdrożeń grup dostępności SQL Server opartych na systemie Linux, powyższa konfiguracja nie zadziała. Dzieje się tak, ponieważ WSFC może być używany tylko w instalacjach SQL Server opartych na systemie Windows.
Aby rozwiązać to ograniczenie i umożliwić automatyczne przełączanie awaryjne w przypadku wdrożeń z dwiema replikami opartymi na systemie Linux, firma Microsoft wprowadziła nową koncepcję.
Replika tylko do konfiguracji
Replika tylko do konfiguracji to opcja, w której instalujemy dodatkową instancję SQL Server na trzecim węźle. Ten węzeł będzie działał jako serwer-świadek dla konfiguracji repliki z dwoma węzłami w celu obsługi automatycznego przełączania awaryjnego. Możemy utworzyć jedną replikę tylko do konfiguracji na grupę dostępności .
W przypadku wystąpień SQL Server opartych na systemie Linux, w których używamy typu klastra jako EXTERNAL dla PACEMAKER, arbitraż trybu failover nie działa w warstwie klastra, tak jak WSFC. Cały arbitraż dotyczący przełączania awaryjnego odbywa się w warstwie SQL Server, ponieważ wszystkie metadane konfiguracji grupy dostępności są przechowywane w głównych bazach danych każdej repliki.
Firma Microsoft wprowadziła koncepcję repliki tylko do konfiguracji w celu obsługi kworum dla grup dostępności programu SQL Server opartych na systemie Linux. Ta koncepcja nie obsługuje żadnych baz danych użytkowników do udziału w grupie dostępności. Przechowuje wszystkie informacje o konfiguracji grupy dostępności w głównej bazie danych, aby zapewnić płynny przebieg arbitrażu przełączania awaryjnego.
Dla repliki tylko do konfiguracji można użyć dowolnej wersji programu SQL Server. Nawet wersja SQL Server Express pozwoli zaoszczędzić na kosztach licencji na trzecią replikę. Pamiętaj, że replika tylko do konfiguracji nie będzie obsługiwać żadnej bazy danych w grupie dostępności. W ten sposób będziesz mieć tylko dwie kopie baz danych w grupie dostępności.
Domyślnie required_synchronized_secondaries_to_commit jest ustawiony na 0 kiedy używamy repliki tylko do konfiguracji. W razie potrzeby możemy ręcznie zmienić tę wartość na 1.
Spójrz na diagram projektu dwuwęzłowej repliki synchronicznej i repliki tylko do konfiguracji, aby uzyskać automatyczne przełączanie awaryjne i ochronę danych.
Widzimy, że istnieją 3 maszyny wirtualne o nazwach AOAGVM1, AOAGVM2 i AOAGVM3. Wszystkie działają w systemie Ubuntu Linux, a SQL Server jest skonfigurowany na wszystkich trzech systemach Linux. Bazy danych dostępności są hostowane na AOAGVM1 i AOAGVM2.
AOAGVM1 działa jako replika główna, podczas gdy AOAGVM2 jest repliką wtórną. AOAGVM3 służy jako replika tylko do konfiguracji, która jest wersją SQL Server Express. W tej trzeciej replice nie są hostowane żadne bazy danych użytkowników.
Klaster Pacemaker został skonfigurowany między wszystkimi trzema węzłami w celu obsługi technologii klastrowej dla konfiguracji grup dostępności opartych na systemie Linux.
Aby skonfigurować lub wdrożyć powyższy projekt, musimy wykonać następujące kroki:
- Zainstaluj SQL Server na trzech systemach Ubuntu (wersja SQL Server Express będzie pasować do replik tylko do konfiguracji).
- Konfiguruj grupy dostępności między trzema węzłami.
- Skonfiguruj klaster PACEMAKER między trzema węzłami.
- Dodaj lub zintegruj grupę dostępności jako zasób w grupie klastra.
Zapoznaj się z powiązanym artykułem, aby ukończyć krok 1 (instalacja instancji SQL Server na trzech węzłach).
Czekajcie na mój następny artykuł, w którym wyjaśnię krok po kroku proces implementacji powyższego projektu. Naszym celem będzie osiągnięcie automatycznego przełączania awaryjnego i ochrony danych przy użyciu 2-węzłowej repliki synchronicznej i repliki tylko do konfiguracji.
Chętnie poznamy Twoje przemyślenia i praktyczne wskazówki w tej sprawie. Podziel się nimi w sekcji Komentarze.
