Rozwiązywanie problemów z klastrem trybu failover

Dotyczy:SQL Server

Ten artykuł zawiera informacje o następujących problemach:

Podstawowe kroki rozwiązywania problemów

Pierwszym krokiem diagnostycznym jest uruchomienie nowego sprawdzania poprawności klastra. Aby uzyskać szczegółowe informacje na temat walidacji, zobacz Tworzenie klastra trybu failover: weryfikowanie konfiguracji. Można to wykonać bez żadnych przerw w działaniu usługi, ponieważ nie ma to wpływu na żadne zasoby klastra online.

Walidację można uruchomić w dowolnym momencie po zainstalowaniu funkcji Klaster Zapasowy, w tym przed wdrożeniem klastra, podczas tworzenia klastra i podczas działania klastra. W rzeczywistości dodatkowe testy są wykonywane podczas użycia klastra, aby sprawdzić, czy przestrzegane są najlepsze praktyki dla obciążeń o wysokiej dostępności. W tych dziesiątkach testów tylko kilka z nich wpływa na uruchomione obciążenia klastra, a wszystkie one są w kategorii przechowywania, więc pominięcie całej tej kategorii jest łatwym sposobem uniknięcia testów powodujących zakłócenia.

Klasterowanie przełączania awaryjnego jest wyposażone we wbudowaną ochronę, aby zapobiec przypadkowemu przestojowi podczas przeprowadzania testów pamięci masowej w trakcie walidacji. Jeśli klaster ma jakiekolwiek grupy online po zainicjowaniu walidacji, a testy magazynu pozostaną wybrane, system monituje użytkownika o potwierdzenie, czy chce uruchomić wszystkie testy (i spowodować przestój), czy pominąć testowanie dysków grup online, aby uniknąć przestoju. Jeśli cała kategoria przechowywania została wykluczona z testowania, ten komunikat nie jest wyświetlany. Umożliwia to walidację klastra bez przestojów.

Jak ponownie uruchomić klaster

  1. W przystawce Klaster awaryjny, w drzewie konsoli, upewnij się, że wybrano pozycję Zarządzanie klastrem awaryjnym, a następnie w obszarze Zarządzanie wybierz pozycję Zweryfikuj konfigurację.

  2. Postępuj zgodnie z instrukcjami w kreatorze, aby określić serwery i testy, a następnie uruchomić testy. Strona Podsumowanie zostanie wyświetlona po uruchomieniu testów.

  3. Na stronie Podsumowanie wybierz pozycję Wyświetl raport , aby wyświetlić wyniki testu.

    Aby wyświetlić wyniki testów po zamknięciu kreatora, sprawdź %SystemRoot%\Cluster\Reports\Validation Report date and time.html, w którym znajduje się folder %SystemRoot%, gdzie jest zainstalowany system operacyjny (na przykład C:\Windows).

  4. Aby wyświetlić artykuły pomocy ułatwiające interpretowanie wyników, wybierz pozycję Więcej na temat testów weryfikacji klastra.

Aby wyświetlić artykuły pomocy dotyczące weryfikacji klastra po zamknięciu kreatora, w przystawce Failover Cluster wybierz pozycję Pomoc, wybierz pozycję Tematy pomocy, wybierz kartę Zawartość, rozwiń zawartość pomocy klastra trybu failover i wybierz pozycję Weryfikowanie konfiguracji klastra trybu failover. Po zakończeniu pracy kreatora weryfikacji Raport Podsumowujący wyświetli wyniki. Wszystkie testy muszą przejść z zielonym haczykiem lub czasami z żółtym trójkątem (ostrzeżenie). W przypadku wyszukiwania obszarów problemów (czerwonych znaków X lub żółtych znaków zapytania) w części raportu, która podsumowuje wyniki testu, wybierz pojedynczy test, aby przejrzeć szczegóły. Przed rozwiązywaniem problemów z programem SQL Server należy rozwiązać wszelkie problemy oznaczone czerwonym X.

Instalowanie aktualizacji

Instalowanie aktualizacji jest ważną częścią unikania problemów z systemem. Przydatne linki:

Odzyskiwanie po awarii klastra przełączeniowego

Zazwyczaj niepowodzenie klastra failover jest wynikiem jednej z dwóch przyczyn.

  • Awaria sprzętowa w jednym węźle klastra z dwoma węzłami. Ta awaria sprzętowa może być spowodowana awarią na karcie SCSI lub w systemie operacyjnym.

    Aby odzyskać system po tej awarii, usuń uszkodzony węzeł z klastra przełączania awaryjnego, używając programu instalacyjnego SQL Server, rozwiąż problem ze sprzętem mając komputer offline, uruchom ponownie komputer, a następnie dodaj naprawiony węzeł z powrotem do wystąpienia klastera przełączania awaryjnego.

    Aby uzyskać więcej informacji, odwołaj się do Tworzenie nowej instancji klastra Always On (Konfiguracja) oraz Odzyskiwanie po awarii instancji klastra trybu failover.

  • Awaria systemu operacyjnego. W takim przypadku węzeł jest w trybie offline, ale nie jest nieodwracalnie uszkodzony.

    Aby odzyskać system po awarii, napraw węzeł i przetestuj tryb przełączania awaryjnego. Jeśli wystąpienie programu SQL Server nie przełączy się w tryb failover prawidłowo, należy użyć programu instalacyjnego programu SQL Server, aby usunąć program SQL Server z klastra trybu failover, wykonać niezbędne naprawy, przywrócić kopię zapasową komputera, a następnie dodać naprawiony węzeł z powrotem do wystąpienia klastra trybu failover.

    Odzyskiwanie po awarii systemu operacyjnego może zająć trochę czasu. Jeśli awarię systemu operacyjnego da się łatwo naprawić, należy unikać korzystania z tej techniki.

    Aby uzyskać więcej informacji, odwołaj się do Tworzenie nowej instancji klastra Always On (Konfiguracja) oraz Odzyskiwanie po awarii instancji klastra trybu failover.

Rozwiązywanie typowych problemów

Na poniższej liście opisano typowe problemy z użyciem i wyjaśniono, jak je rozwiązać.

Problem: Nieprawidłowe użycie składni wiersza polecenia do zainstalowania programu SQL Server

Problem 1: Trudno zdiagnozować problemy z instalacją podczas korzystania z /qn przełącznika z wiersza polecenia, ponieważ /qn przełącznik pomija wszystkie okna dialogowe Instalatora i komunikaty o błędach. /qn Jeśli przełącznik zostanie określony, wszystkie komunikaty instalatora, w tym komunikaty o błędach, są zapisywane w plikach dziennika instalacji. Aby uzyskać więcej informacji na temat plików dziennika, zobacz Wyświetlanie i odczytywanie plików dziennika instalatora programu SQL Server.

Rozdzielczość 1: użyj przełącznika /qb zamiast przełącznika /qn . Jeśli używasz przełącznika /qb , zostanie wyświetlony podstawowy interfejs użytkownika w każdym kroku, w tym komunikaty o błędach.

Problem: program SQL Server nie może nawiązać połączenia z siecią po przeprowadzeniu migracji do innego węzła

Problem 1: Konta usług programu SQL Server nie mogą skontaktować się z kontrolerem domeny.

Rozwiązanie 1: Sprawdź dzienniki zdarzeń pod kątem oznak problemów z siecią, takich jak błędy adaptera lub problemy z systemem DNS. Sprawdź, czy możesz wysłać polecenie ping do kontrolera domeny.

Problem 2: Hasła konta usługi programu SQL Server nie są identyczne we wszystkich węzłach klastra lub węzeł nie uruchamia ponownie usługi programu SQL Server, która została zmigrowana z węzła, który uległ awarii.

Rozwiązanie 2: Zmień hasła konta usługi programu SQL Server przy użyciu programu SQL Server Configuration Manager. Jeśli tego nie zrobisz, a zmienisz hasła konta usługi SQL Server w jednym węźle, musisz również zmienić hasła we wszystkich innych węzłach. Program SQL Server Configuration Manager wykonuje to automatycznie.

Problem: program SQL Server nie może uzyskać dostępu do dysków klastra

Problem 1: Oprogramowanie układowe lub sterowniki nie są aktualizowane we wszystkich węzłach.

Rozwiązanie 1: Sprawdź, czy wszystkie węzły używają poprawnych wersji oprogramowania układowego i tych samych wersji sterowników.

Problem 2: Węzeł nie może odzyskać dysków klastra, które zostały zmigrowane z węzła, który zakończył się niepowodzeniem na udostępnionym dysku klastra z inną literą dysku.

Rozwiązanie 2: Litery dysków klastrowych muszą być takie same na obu serwerach. Jeśli tak nie jest, zapoznaj się z oryginalną instalacją systemu operacyjnego i usługą klastra firmy Microsoft (MSCS).

Problem: Niepowodzenie usługi SQL Server powoduje przejście w tryb failover

Rezolucja: Aby zapobiec awarii określonych usług powodujących przełączenie grupy programu SQL Server w tryb failover, skonfiguruj te usługi przy użyciu administratora klastra w systemie Windows w następujący sposób:

  • Wyczyść pole wyboru Wpływ na grupę na karcie Zaawansowane w oknie dialogowym Właściwości pełnotekstowe . Jeśli jednak program SQL Server powoduje przejście w tryb failover, usługa wyszukiwania pełnotekstowego zostanie ponownie uruchomiona.

Problem: program SQL Server nie uruchamia się automatycznie

Rezolucja: Użyj administratora klastra w programie MSCS, aby automatycznie uruchomić klaster trybu failover. Należy ustawić usługę PROGRAMU SQL Server tak, aby uruchamiała się ręcznie; Administrator klastra powinien być skonfigurowany w programie MSCS, aby uruchomić usługę programu SQL Server. Aby uzyskać więcej informacji, zobacz Zarządzanie usługami.

Problem: Nazwa sieci jest w trybie offline i nie można nawiązać połączenia z programem SQL Server przy użyciu protokołu TCP/IP

Problem 1: DNS kończy się niepowodzeniem przy ustawieniu zasobów klastra na wymóg DNS.

Rozwiązanie 1: Rozwiązywanie problemów z systemem DNS.

Problem 2: W sieci znajduje się zduplikowana nazwa.

Rozwiązanie 2: Użyj polecenia nbtstat, aby znaleźć zduplikowaną nazwę, a następnie usunąć problem.

Problem 3: Program SQL Server nie łączy się przy użyciu nazwanych potoków.

Rozwiązanie 3: Aby nawiązać połączenie przy użyciu nazwanych potoków, użyj Menedżera konfiguracji SQL Server, aby utworzyć alias do połączenia się z odpowiednim komputerem. Jeśli na przykład masz klaster z dwoma węzłami (Node A i Node B) i wystąpienie klastra awaryjnego (Virtsql) z wystąpieniem domyślnym, możesz nawiązać połączenie z serwerem zawierającym zasób Nazwy sieciowej, który jest w trybie offline, wykonując następujące kroki:

  1. Określ, w którym węźle grupa zawierająca wystąpienie programu SQL Server jest uruchomiona przy użyciu administratora klastra. W tym przykładzie jest to węzeł A.

  2. Uruchom usługę SQL Server na tym komputerze przy użyciu polecenia net start. Aby uzyskać więcej informacji na temat korzystania z polecenia net start, zobacz Ręczne uruchamianie programu SQL Server.

  3. Uruchom program SQL Server Configuration Manager na węźle A. Wyświetl nazwę potoku, na którym nasłuchuje serwer. Powinna być podobna do \\.\$$\VIRTSQL\pipe\sql\query.

  4. Na komputerze klienckim uruchom menedżera konfiguracji programu SQL Server.

  5. Utwórz alias SQLTEST1 , aby nawiązać połączenie za pośrednictwem nazwanych potoków z tą nazwą potoku. W tym celu wprowadź wartość Node A jako nazwę serwera i zmodyfikuj nazwę potoku na \\.\pipe\$$\VIRTSQL\sql\query.

  6. Połącz się z tym wystąpieniem, używając aliasu SQLTEST1 jako nazwy serwera.

Problem: Instalacja programu SQL Server kończy się niepowodzeniem w klastrze z błędem 11001

Problem: Osierocony klucz rejestru w HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\Cluster.

Rezolucja: Upewnij się, że MSSQL.X gałąź rejestru nie jest obecnie używana, a następnie usuń klucz klastra.

Problem: Błąd instalacji klastra: "Instalator ma niewystarczające uprawnienia dostępu do tego katalogu: <dysk>\Microsoft SQL Server. Instalacja nie może być kontynuowana. Zaloguj się jako administrator lub skontaktuj się z administratorem systemu"

Problem: Ten błąd jest spowodowany przez dysk udostępniony SCSI, który nie jest prawidłowo partycjonowany.

Rezolucja: Utwórz ponownie pojedynczą partycję na dysku udostępnionym, wykonując następujące kroki:

  1. Usuń zasób dysku z klastra.
  2. Usuń wszystkie partycje na dysku.
  3. Sprawdź we właściwościach dysku, czy dysk jest dyskiem podstawowym.
  4. Utwórz jedną partycję na dysku udostępnionym, sformatuj dysk i przypisz literę dysku do dysku.
  5. Dodaj dysk do klastra przy użyciu administratora klastra (cluadmin).
  6. Uruchom instalatora programu SQL Server.

Problem: Aplikacje nie mogą zarejestrować zasobów programu SQL Server w transakcji rozproszonej

Problem: Ponieważ program Microsoft Distributed Transaction Coordinator (MS DTC) nie jest całkowicie skonfigurowany w systemie Windows, aplikacje mogą nie zarejestrować zasobów programu SQL Server w transakcji rozproszonej. Ten problem może wpływać na serwery powiązane, rozproszone zapytania oraz zdalne procedury składowane, które korzystają z transakcji rozproszonych. Aby uzyskać więcej informacji dotyczących konfigurowania usługi MS DTC, zobacz Przed zainstalowaniem klastra przełączania awaryjnego.

Rezolucja: Aby zapobiec takim problemom, należy w pełni włączyć usługi MS DTC na serwerach, na których jest zainstalowany program SQL Server, a usługa MS DTC jest skonfigurowana.

Aby w pełni włączyć usługę MS DTC, wykonaj następujące kroki:

  1. W Panelu sterowania otwórz narzędzia administracyjne, a następnie otwórz przystawkę Zarządzanie komputerem.

  2. W lewym okienku zarządzania komputerem rozwiń węzeł Usługi i aplikacje, a następnie wybierz pozycję Usługi.

  3. W okienku po prawej stronie w Zarządzanie komputerem kliknij prawym przyciskiem myszy pozycję Koordynator transakcji rozproszonej i wybierz polecenie Właściwości.

  4. W oknie Koordynator transakcji rozproszonych wybierz kartę Ogólne , a następnie wybierz pozycję Zatrzymaj , aby zatrzymać usługę.

  5. W oknie Koordynator transakcji rozproszonych wybierz kartę Logowanie i ustaw konto NT AUTHORITY\NetworkServicelogowania .

  6. Wybierz pozycjęZastosuj i OK, aby zamknąć okno Koordynator transakcji rozproszonych. Zamknij okno Zarządzanie komputerem . Zamknij okno Narzędzia administracyjne .

Problem: SQL Server Agent nie może połączyć się z instancją klastra awaryjnego wielopodsieci na niestandardowym porcie

Problem: SQL Server Agent nie może połączyć się z lokalnym Database Engine, gdy spełnione są wszystkie następujące warunki:

  1. SQL Server jest instalowany jako instancja klastra awaryjnego w wielu podsieciach.
  2. Instancja klastra awaryjnego jest domyślną.
  3. Database Engine nasłuchuje na stałym porcie TCP innym niż domyślny 1433.
  4. SQL Server Agent łączy się z lokalną instancją podczas uruchamiania.

Dla instancji klastra awaryjnego wielopodsieciowego początkowe połączenie z SQL Server Agent używa MultiSubnetFailover=Yes. To ustawienie powoduje, że klient korzysta z TCP. Połączenie nie wraca do pamięci współdzielonej ani nazwanych rur. Jeśli celem jest (local) i nie określono portu, następuje próba połączenia na porcie TCP 1433. Połączenie się nie udaje, jeśli Database Engine nie słucha na tym porcie.

Możesz zobaczyć połączenie podobne do poniższego w śladzie ODBC:

DRIVER=ODBC Driver 17 for SQL Server;SERVER=(local);APP=SQLAgent - Initial Boot Probe;DATABASE=master;MultiSubnetFailover=YES;

Rozdzielczenie: Stwórz alias TCP, który kieruje połączenie SQL Server Agent do nazwy sieci wirtualnej oraz skonfigurowanego portu TCP instancji klastra awaryjnego. Skonfiguruj alias na każdym węźle, który może hostować instancję klastra awaryjnego.

Krok 1: Potwierdź skonfigurowany port TCP

  1. Na aktywnym węźle otwórz SQL Server Configuration Manager.
  2. Rozwiń Konfigurację sieci SQL Server, a następnie wybierz Protokoły dla MSSQLSERVER.
  3. Otwórz TCP/IP, a następnie wybierz zakładkę Adresy IP .
  4. Jeśli Listen All jest ustawione na Tak, zwróć uwagę na wartość portu TCP w IPAll.
  5. Jeśli Listen All jest ustawione na Nie, zwróć uwagę na wartość portu TCP dla każdego włączonego adresu IP używanego przez instancję klastra awaryjnego.
  6. Potwierdź, czy dziennik błędów programu SQL Server pokazuje, że Aparat bazy danych nasłuchuje na oczekiwanym porcie.

Aby uzyskać więcej informacji, zobacz Skonfiguruj serwer SQL, aby nasłuchiwał na określonym porcie TCP.

Krok 2: Utworzenie aliasu TCP na każdym węźle klastra

Wykonaj następujące kroki na każdym węźle, który może hostować instancję klastra awaryjnego:

  1. Otwórz narzędzie do konfiguracji aliasów klienta SQL Server odpowiednie dla zainstalowanej wersji SQL Server.
  2. Stwórz nowy alias.
  3. W polu Nazwa aliasu wpisz unikalną nazwę lokalnego połączenia z programem SQL Server Agent. Używaj tej samej nazwy aliasu na każdym węźle.
  4. Wybierz TCP/IP jako protokół.
  5. W Serwerze wpisz nazwę sieci wirtualnej instancji klastra awaryjnego. Nie wpisuj fizycznej nazwy węzła.
  6. W porcie nr wpisz stały port TCP zidentyfikowany w kroku 1.
  7. Zachowaj pseudonim.

Szczegółowe instrukcje i wymagania dotyczące wersji można znaleźć w artykule Utwórz lub usuń alias serwera do użycia przez klienta.

Important

Alias serwera SQL Server to konfiguracja klienta. Stwórz identyczny alias na każdym węźle, który może być właścicielem instancji klastra awaryjnego. W przeciwnym razie SQL Server Agent może przestać działać po przeniesieniu instancji na węzeł, na którym alias nie jest skonfigurowany.

Krok 3: Skonfiguruj SQL Server Agent do używania aliasu

  1. W programie SQL Server Management Studio połącz się z instancją klastra pracy awaryjnej.
  2. W Eksplorator obiektów rozwiń instancję.
  3. Kliknij prawym przyciskiem myszy na SQL Server Agent, a następnie wybierz Właściwości.
  4. W sekcji Wybierz stronę wybierz Połączenie.
  5. W serwerze Alias local host wprowadź nazwę aliasu utworzoną w kroku 2.
  6. Kliknij przycisk OK.
  7. Uruchom ponownie agenta programu SQL Server.

Więcej informacji można znaleźć w artykule Ustaw alias SQL Server dla usługi SQL Server Agent.

Krok 4: Zweryfikowaj konfigurację

  1. Potwierdź, że SQL Server Agent uruchamia się pomyślnie.
  2. Przejrzyj log SQL Server Agent i potwierdź, że Agent połączył się z docelową lokalną instancją Database Engine.
  3. Uruchom proste zadanie SQL Server Agent, aby potwierdzić, że zadania mogą łączyć się z instancją.
  4. W momencie, gdy nie zakłóci to normalnych działań biznesowych, przenieś instancję klastra awaryjnego do innego możliwego węzła właściciela.
  5. Potwierdź, że SQL Server Agent się uruchamia i zadanie testowe na tym węźle się powiodło.
  6. Powtórz test dla każdego możliwego węzła właściciela.

Używanie rozszerzonych procedur składowanych i obiektów COM

W przypadku korzystania z rozszerzonych procedur składowanych w konfiguracji klastra z przełączaniem awaryjnym, wszystkie rozszerzone procedury składowane muszą być zainstalowane na dysku klastra zależnym od SQL Server. Dzięki temu, gdy węzeł przechodzi w tryb awaryjny, rozszerzone procedury składowane są nadal dostępne do użycia.

Jeśli rozszerzone procedury składowane używają składników COM, administrator musi zarejestrować składniki COM w każdym węźle klastra. Informacje dotyczące ładowania i wykonywania składników COM muszą znajdować się w rejestrze aktywnego węzła w celu utworzenia składników. W przeciwnym razie informacje pozostają w rejestrze komputera, na którym po raz pierwszy zarejestrowano składniki COM.

Treści powiązane

  • Last updated on