Odzyskiwanie po awarii w usłudze WSFC za pomocą wymuszonego kworum (SQL Server)

Dotyczy:SQL Server

Awaria kworum jest zwykle spowodowana katastrofą systemową, utrzymującą się awarią komunikacji lub błędną konfiguracją obejmującą kilka węzłów w klastrze WSFC. Aby przywrócić działanie po awarii kworum, wymagana jest ręczna interwencja.

Wymagania wstępne

Procedura wymuszenia kworum zakłada, że przed awarią kworum istniało sprawne kworum.

Warning

Użytkownik powinien być dobrze poinformowany o koncepcjach i interakcjach związanych z klastrowaniem awaryjnym Windows Server, modelami WSFC Quorum, SQL Server oraz specyficzną konfiguracją wdrożenia środowiska.

Więcej informacji można znaleźć w: Klastrowanie trybu failover systemu Windows Server (WSFC) z programem SQL Server, Tryby kworum WSFC i konfiguracja głosów (SQL Server)

Zabezpieczenia

Użytkownik musi być kontem domenowym będącym członkiem lokalnej grupy Administratorów na każdym węźle klastra WSFC.

Odzyskiwanie po awarii WSFC poprzez procedurę wymuszonego kworum

Pamiętaj, że awaria kworum spowoduje przełączenie wszystkich usług klastrowych, instancji programu SQL Server oraz grup dostępności Always On w klastrze WSFC w stan offline, ponieważ klaster w obecnej konfiguracji nie jest w stanie zapewnić odporności na awarie na poziomie węzłów. Brak kworum oznacza, że zdrowe węzły głosowania w klastrze WSFC nie spełniają już modelu kworum. Niektóre węzły mogły ulec całkowitej awarii, a niektóre mogły jedynie zatrzymać usługę WSFC i poza tym działać prawidłowo, z wyjątkiem utraty możliwości komunikacji z kworum.

Aby przywrócić klaster WSFC, musisz naprawić przyczynę awarii kworum w istniejącej konfiguracji, odzyskać dotknięte bazy danych w razie potrzeby oraz ewentualnie przekonfigurować pozostałe węzły w klastrze WSFC, aby odzwierciedlały zachowaną topologię klastra.

Możesz użyć procedury wymuszonego kworum na węźle klastra WSFC, aby ominąć zabezpieczenia, które spowodowały przejście klastra w tryb offline. To skutecznie informuje klaster o zawieszeniu kontroli głosowania kworum i pozwala przywrócić zasoby klastra WSFC oraz SQL Server do dowolnego węzła w klastrze.

Tego typu proces odbudowy po awarii powinien obejmować następujące kroki:

Aby odbudować się po niedoborze kworum:

  1. Określ skalę awarii. Zidentyfikuj, które grupy dostępności lub instancje SQL Server są nieresponsywne, które węzły klastra są online i dostępne do użytku po katastrofie, oraz przeanalizuj logi zdarzeń Windows i SQL Server. Tam, gdzie to możliwe, powinieneś przechowywać dane kryminalistyczne i logi systemowe na późniejszą analizę.

    Wskazówka

    Na responsywnej instancji SQL Server możesz uzyskać informacje o stanie zdrowia grup dostępności, które posiadają replikę dostępności na lokalnej instancji serwera, zapytując sys.dm_hadr_availability_group_states dynamiczny widok zarządzania (DMV).

  2. Uruchom klaster WSFC przy użyciu wymuszonego kworum w pojedynczym węźle. Zidentyfikuj węzeł z minimalną liczbą awarii komponentów, poza tym, że usługa klastra WSFC została zamknięta. Sprawdź, czy ten węzeł może komunikować się z większością pozostałych węzłów.

    W tym węźle ręcznie wymuś przełączenie klastra w tryb online za pomocą procedury wymuszenia kworum. Aby zminimalizować potencjalną utratę danych, wybierz węzeł, który jako ostatni obsługiwał replikę podstawową grupy dostępności.

    Więcej informacji można znaleźć tutaj: Wymuś uruchomienie klastra WSFC bez kworum

    Note

    Ustawienie wymuszonego kworum ma efekt blokowania kontroli kworum na poziomie całego klastra, dopóki logiczny klaster WSFC nie uzyska większości głosów i automatycznie przejdzie do zwykłego trybu kworum.

  3. Uruchom usługę WSFC normalnie na każdym skądinąd sprawnym węźle, po jednym na raz. Nie musisz określać opcji wymuszonego kworum przy uruchamianiu usługi klastrowej na pozostałych węzłach.

    Gdy usługa WSFC na każdym węźle wraca do sieci, negocjuje z innymi zdrowymi węzłami, aby zsynchronizować nowy stan konfiguracji klastra. Pamiętaj, aby wykonywać to po jednym węźle naraz, aby zapobiec potencjalnym warunkom wyścigu podczas ustalania ostatniego znanego stanu klastra.

    Warning

    Upewnij się, że każdy węzeł, który uruchamiasz, może komunikować się z innymi nowo uruchomionymi węzłami. Rozważ wyłączenie usługi WSFC na pozostałych węzłach. W przeciwnym razie ryzykujesz utworzenie więcej niż jednego zestawu węzłów kworum; To scenariusz z rozszczepionym mózgiem. Jeśli Twoje ustalenia z kroku 1 były trafne, nie powinno się to zdarzyć.

  4. Wprowadź nowy tryb kworum i konfigurację głosowania węzłów. Jeśli wymuszenie kworum pomyślnie zrestartowało wszystkie węzły w klastrze, a przyczyna niepowodzenia kworum została naprawiona, zmiany w oryginalnym trybie kworum i konfiguracji głosowania węzłów są zbędne.

    W przeciwnym razie należy ocenić nowo odzyskany węzeł klastra oraz topologię replik dostępności, a następnie odpowiednio zmienić tryb kworum i przypisania głosów dla każdego węzła. Węzły, których nie odzyskano, powinny zostać przełączone w tryb offline lub mieć liczbę głosów ustawioną na zero.

    Wskazówka

    W tym momencie węzły i instancje SQL Server w klastrze mogą wydawać się przywrócone do normalnego działania. Jednak nadal może nie istnieć zdrowy kworum. Korzystając z Menedżera Failover Cluster, Always On Dashboard w SQL Server Management Studio lub odpowiednich DMV, sprawdź, czy kworum zostało przywrócone.

  5. Odzyskaj repliki baz danych grupy dostępności w razie potrzeby. Bazy danych nienależące do grup dostępności powinny odzyskać sprawność i automatycznie przejść ponownie do trybu online w ramach standardowego procesu uruchamiania programu SQL Server.

    Możesz zminimalizować potencjalną utratę danych i czas odzyskiwania w przypadku replik grupy dostępności, przywracając je do trybu online w następującej kolejności: replika podstawowa, synchroniczne repliki pomocnicze, asynchroniczne repliki pomocnicze.

Note

Po użyciu wymuszonego kworum konieczne jest wykonanie wymuszonego przełączenia awaryjnego z możliwością utraty danych, aby ponownie przełączyć grupę dostępności do trybu online. Aby uzyskać więcej informacji, zapoznaj się z artykułem Wykonaj wymuszone ręczne przełączenie awaryjne grupy dostępności (SQL Server).

  1. Napraw lub wymień uszkodzone komponenty i ponownie zweryfikuj klaster. Teraz, gdy udało się opanować skutki początkowej awarii i awarii kworum, należy naprawić lub wymienić węzły, które uległy awarii, i odpowiednio dostosować powiązane konfiguracje WSFC i Always On. Może to obejmować usunięcie replik grup dostępności, usunięcie węzłów z klastra lub wyczyszczenie i ponowną instalację oprogramowania na węźle.

    Musisz naprawić lub usunąć wszystkie wadliwe repliki dostępności. SQL Server nie obcina dziennika transakcji poniżej ostatniego znanego punktu najdalszego za repliką dostępności. Jeśli uszkodzona replika nie zostanie naprawiona lub usunięta z grupy dostępności, logi transakcyjne będą się powiększać i ryzykujesz brak miejsca w logach transakcji na pozostałych replikach.

    Note

    Jeśli uruchomisz kreator konfiguracji WSFC Validate a Configuration Wizard, gdy na klastrze WSFC istnieje nasłuchiwacz grupy dostępności, kreator generuje następujący błędny komunikat ostrzegawczy:

    "Właściwość RegisterAllProviderIP dla nazwy sieciowej "Name:<network_name>" jest ustawiona na 1 Dla bieżącej konfiguracji klastra ta wartość powinna być ustawiona na 0."

    Zignoruj tę wiadomość.

  2. W razie potrzeby powtórz krok 4. Celem jest przywrócenie odpowiedniego poziomu odporności na awarie i wysokiej dostępności dla sprawnej eksploatacji.

  3. Przeprowadź analizę RPO/RTO. Powinieneś analizować logi systemowe SQL Server, znaczniki czasowe bazy danych oraz logi zdarzeń Windows, aby ustalić przyczynę awarii oraz udokumentować rzeczywiste doświadczenia z punktami odzyskania i czasem odzyskiwania.

Powiązane zadania

Treści powiązane

  • Last updated on