Udostępnij za pośrednictwem

Grupa dostępności Always On i przełączanie awaryjne w systemie Linux

  • Artykuł

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 = EXTERNALjedyną 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.

  1. 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.

  2. 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 pcsmove lub polecenie crmmigrate 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:

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.

  1. 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ń.

  2. 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';

  3. 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;

  4. 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.

  5. 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=EXTERNALsemantyka 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ż ONLINEprogram 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ść

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