Grupa dostępności Always On i przełączanie awaryjne w systemie Linux
Dotyczy:programu SQL Server — Linux
W kontekście grupy dostępności, podstawowa rola i pomocnicza rola replik dostępności są zwykle wymienne w procesie znanym jako tzw. przełączenie awaryjne. Istnieją trzy formy przełącznika awaryjnego: automatyczne przełączenie (bez utraty danych), planowane ręczne przełączenie (bez utraty danych) i wymuszone ręczne przełączenie (z możliwą utratą danych), zwykle nazywane wymuszonym przełączeniem. Automatyczne i planowane ręczne przełączenia awaryjne zachowują wszystkie dane. Grupa dostępności przełączy się w tryb failover na poziomie repliki dostępności. Oznacza to, że grupa dostępności przechodzi na jedną z jej replik podrzędnych (obecny cel przełączenia).
Aby uzyskać podstawowe informacje na temat failover, zobacz Failover i tryby Failover (Always On grupy dostępności).
Ręczne przechodzenie w tryb failover
Użyj narzędzi do zarządzania klastrem, aby przełączyć grupę dostępności (AG) zarządzaną przez zewnętrznego menedżera klastra. Jeśli na przykład rozwiązanie używa narzędzia Pacemaker do zarządzania klastrem systemu Linux, użyj pcs
do ręcznego przejścia w tryb failover w systemie Red Hat Enterprise Linux (RHEL) lub Ubuntu. W systemie SUSE Linux Enterprise Server (SLES) użyj crm
.
Ważny
W normalnych operacjach nie przełączaj na tryb awaryjny przy użyciu Transact-SQL ani narzędzi do zarządzania SQL Server, takich jak SSMS lub PowerShell. W przypadku CLUSTER_TYPE = EXTERNAL
jedyną akceptowalną wartością FAILOVER_MODE
jest EXTERNAL
. Dzięki tym ustawieniom wszystkie akcje ręcznego lub automatycznego trybu failover są wykonywane przez zewnętrznego menedżera klastra. Aby uzyskać instrukcje wymuszenia przejścia do trybu failover z potencjalną utratą danych, zobacz Wymuszanie trybu failover.
Ręczne kroki przechodzenia w tryb failover
Aby przejść w tryb failover, replika pomocnicza, która stanie się repliką podstawową, musi być synchroniczna. Jeśli replika pomocnicza jest asynchroniczna, zmień tryb dostępności.
Ręczne przełączanie na tryb failover w dwóch etapach.
Najpierw ręcznie przełączenie w tryb failover przez przeniesienie zasobu grupy dostępności z węzła klastra, który jest właścicielem zasobów do nowego węzła.
Klaster kończy się niepowodzeniem zasobu grupy dostępności i dodaje ograniczenie lokalizacji. To ograniczenie konfiguruje zasób, aby działał na nowym węźle. Aby w przyszłości przeprowadzić udany failover, usuń to ograniczenie.
Po drugie, usuń ograniczenie lokalizacji.
Krok 1. Ręczne przełączenie w tryb awaryjny przez przeniesienie zasobu grupy dostępności
Aby ręcznie przełączyć w tryb failover zasób grupy dostępności o nazwie ag_cluster
do węzła klastra o nazwie nodeName2, uruchom odpowiednie polecenie dla dystrybucji:
przykład RHEL/Ubuntu
sudo pcs resource move ag_cluster-master nodeName2 --master --lifetime=30S
Przykład SLES
crm resource migrate ag_cluster nodeName2 --lifetime=30S
Jeśli używasz opcji --lifetime
, ograniczenie lokalizacji utworzone w celu przeniesienia zasobu jest tymczasowe i jest ważne przez 30 sekund w poprzednim przykładzie.
Ograniczenie tymczasowe nie jest czyszczone automatycznie i może pojawić się na liście ograniczeń, ale jako wygasłe ograniczenie. Wygasłe ograniczenia nie wpływają na zachowanie klastru Pacemaker podczas przełączenia awaryjnego. Jeśli nie używasz opcji --lifetime
podczas przenoszenia zasobu, usuń ograniczenie lokalizacji, które jest automatycznie dodawane, co zostało zanotowany w poniższej sekcji.
Krok 2. Usuwanie ograniczenia lokalizacji
Podczas ręcznego przełączania awaryjnego polecenie pcs
move
lub polecenie crm
migrate
dodaje ograniczenie lokalizacji dla umieszczenia zasobu w nowym węźle docelowym. Aby wyświetlić nowe ograniczenie, uruchom następujące polecenie po ręcznym przeniesieniu zasobu:
przykład RHEL/Ubuntu
sudo pcs constraint list --full
Przykład SLES
crm config show
Jest to przykład ograniczenia, które jest tworzone z powodu ręcznego przejścia w tryb failover.
Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)
Notatka
Nazwa zasobu AG w klastrach pacemaker na systemach Red Hat Enterprise Linux 8.x i Ubuntu 18.04 może przypominać ag_cluster-clone, ponieważ nomenklatura dotycząca zasobów ewoluuje w kierunku użycia terminu promotable clone.
przykład RHEL/Ubuntu
W poniższym poleceniu
cli-prefer-ag_cluster-master
jest identyfikatorem ograniczenia, które należy usunąć.sudo pcs constraint list --full
zwraca ten identyfikator.sudo pcs resource clear ag_cluster-master
Lub
sudo pcs constraint remove cli-prefer-ag_cluster-master
Alternatywnie można wykonać zarówno przenoszenie, jak i czyszczenie ograniczeń generowanych automatycznie w jednym wierszu w następujący sposób. W poniższym przykładzie użyto terminologii klon zgodnie z wersją Red Hat Enterprise Linux 8.x.
sudo pcs resource move ag_cluster-clone --master nodeName2 && sleep 30 && sudo pcs resource clear ag_cluster-clone
Przykład SLES
W poniższym poleceniu
cli-prefer-ms-ag_cluster
jest identyfikatorem ograniczenia.crm config show
zwraca ten identyfikator.crm configure delete cli-prefer-ms-ag_cluster commit
Notatka
Automatyczne przełączanie awaryjne nie powoduje dodania ograniczenia lokalizacji, więc nie jest konieczne czyszczenie.
Aby uzyskać więcej informacji:
- Red Hat — zarządzanie zasobami klastra
- Pacemaker — ręczne przenoszenie zasobów
- Przewodnik administracyjny SLES — zarządzanie zasobami klastra
Wymuszanie trybu awaryjnego
Wymuszone przejście w tryb failover jest przeznaczone wyłącznie do odzyskiwania po awarii. W takim przypadku nie można przejść w tryb failover za pomocą narzędzi do zarządzania klastrem, ponieważ podstawowe centrum danych nie działa. Jeśli wymusisz przejście w tryb failover do niezsynchronizowanej repliki pomocniczej, możliwa jest utrata danych. Wymuś przełączenie na tryb failover tylko wtedy, gdy musisz natychmiast przywrócić usługę do grupy dostępności i jesteś gotów ryzykować utratę danych.
Jeśli nie możesz użyć narzędzi do zarządzania klastrem do interakcji z klastrem (na przykład jeśli klaster nie odpowiada z powodu zdarzenia awarii w podstawowym centrum danych), może być konieczne wymusić przejście w tryb failover w celu obejścia zewnętrznego menedżera klastra. Ta procedura nie jest zalecana w przypadku regularnych operacji, ponieważ wiąże się z ryzykiem utraty danych. Użyj go, gdy narzędzia do zarządzania klastrem nie mogą wykonać procesu przełączenia awaryjnego. Funkcjonalnie ta procedura jest podobna do wykonywania wymuszonego ręcznego przełączenia awaryjnego w AG w systemie Windows.
Ten proces wymuszania trybu failover jest specyficzny dla programu SQL Server w systemie Linux.
Sprawdź, czy klaster nie zarządza już zasobem AG.
Ustaw zasób na tryb niezarządzany w węźle klastra docelowego. To polecenie sygnalizuje agentowi zasobów zatrzymanie monitorowania zasobów i zarządzania nimi. Na przykład:
sudo pcs resource unmanage <resourceName>
Jeśli próba ustawienia trybu zasobu na tryb niezarządzany zakończy się niepowodzeniem, usuń zasób. Na przykład:
sudo pcs resource delete <resourceName>
Notatka
Usunięcie zasobu powoduje również usunięcie wszystkich skojarzonych ograniczeń.
W wystąpieniu programu SQL Server, które hostuje replikę pomocniczą, ustaw zmienną kontekstową sesji
external_cluster
.EXEC sp_set_session_context @key = N'external_cluster', @value = N'yes';
Przełącz grupę dostępności w tryb failover za pomocą języka Transact-SQL. W poniższym przykładzie zastąp
<MyAg>
nazwą grupy dostępności. Połącz się z wystąpieniem programu SQL Server hostujące docelową replikę pomocniczą i uruchom następujące polecenie:ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;
Po wymuszonym przełączeniu awaryjnym doprowadź grupę dostępności do zdrowego stanu przed ponownym uruchomieniem monitorowania i zarządzania zasobami klastra lub ponownym utworzeniem zasobu grupy dostępności. Zapoznaj się z Podstawowymi zadaniami po wymuszonym awaryjnym przełączeniu.
Uruchom ponownie monitorowanie zasobów klastra i zarządzanie nimi:
Aby ponownie uruchomić monitorowanie zasobów klastra i zarządzanie nimi, uruchom następujące polecenie:
sudo pcs resource manage <resourceName> sudo pcs resource cleanup <resourceName>
Jeśli zasób klastra został usunięty, utwórz go ponownie. Aby ponownie utworzyć zasób klastra, postępuj zgodnie z instrukcjami w Utworzyć zasób grupy dostępności.
Ważny
Nie używaj powyższych kroków na potrzeby próbnego odzyskiwania po awarii, ponieważ ryzykują utratę danych. Zamiast tego zmień replikę asynchroniczną na synchroniczną, a instrukcje dotyczące normalnego ręcznego trybu failover.
Monitorowanie na poziomie bazy danych i wyzwalacz przełączenia awaryjnego
W przypadku CLUSTER_TYPE=EXTERNAL
semantyka przełączania awaryjnego różni się niż w WSFC. Gdy grupa dostępności znajduje się w wystąpieniu programu SQL Server w usłudze WSFC, przejście ze stanu ONLINE
dla bazy danych powoduje, że kondycja grupy dostępności zgłasza błąd. W odpowiedzi menedżer klastra inicjuje akcję przełączenia awaryjnego. W systemie Linux wystąpienie programu SQL Server nie jest w stanie się komunikować z klastrem. Monitorowanie kondycji bazy danych odbywa się poza. Jeśli użytkownik zdecydował się na monitorowanie przełączania awaryjnego na poziomie bazy danych i przełączanie awaryjne (ustawiając opcję DB_FAILOVER=ON
podczas tworzenia grupy dostępności), klaster sprawdza, czy stan bazy danych to ONLINE
za każdym razem, gdy uruchamia akcję monitorowania. Klaster przesyła zapytanie o stan w sys.databases
. W przypadku dowolnego stanu innego niż ONLINE
program automatycznie wyzwala tryb failover (jeśli są spełnione warunki automatycznego trybu failover). Rzeczywisty czas przejścia w tryb failover zależy od częstotliwości akcji monitorowania oraz stanu bazy danych aktualizowanej w sys.databases.
Automatyczne przełączanie awaryjne wymaga co najmniej jednej repliki synchronicznej.
Powiązana zawartość
- Konfigurowanie klastra Red Hat Enterprise Linux dla zasobów klastra Grupy Dostępności SQL Server
- Konfiguracja klastra SUSE Linux Enterprise Server dla zasobów klastra grupy dostępności SQL Server
- Konfigurowanie klastra Ubuntu dla zasobów klastra grupy dostępności SQL Server
Współtworzenie dokumentacji SQL
Czy wiesz, że możesz samodzielnie edytować zawartość SQL? Jeśli to zrobisz, nie tylko pomożesz ulepszyć naszą dokumentację, ale także zostaniesz uznany za współtwórcę strony.
Aby uzyskać więcej informacji, zobacz Jak współtworzyć dokumentację programu SQL Server