Rozwiązywanie problemów z automatycznym trybem failover w środowiskach zawsze włączonych programu SQL Server

Ten artykuł ułatwia rozwiązywanie problemów występujących podczas automatycznego przejścia w tryb failover w programie Microsoft SQL Server.

Oryginalna wersja produktu: SQL Server
Oryginalny numer KB: 2833707

Podsumowanie

Zawsze włączone grupy dostępności programu SQL Server można skonfigurować do automatycznego trybu failover. Jeśli na wystąpieniu programu SQL Server, które hostuje replikę podstawową, wykryto problem z kondycją, rolę podstawową można przenieść do automatycznego partnera trybu failover (repliki pomocniczej). Jednak replika pomocnicza nie zawsze może zostać przeniesiona do roli podstawowej. W niektórych przypadkach można ją przenieść tylko do RESOLVING roli. W takiej sytuacji żadna replika nie będzie miała roli podstawowej, chyba że replika podstawowa powróci do stanu dobrej kondycji. Ponadto bazy danych dostępności będą niedostępne.

W tym artykule wymieniono niektóre typowe przyczyny niepowodzenia automatycznego trybu failover i omówiono kroki, które można wykonać, aby zdiagnozować przyczynę tych błędów.

Objawy, jeśli automatyczne przejście w tryb failover zostało pomyślnie wyzwolone

Po wyzwoleniu automatycznego trybu failover w wystąpieniu programu SQL Server, które hostuje replikę podstawową, replika pomocnicza przechodzi do roli, a następnie do RESOLVING roli podstawowej. Mimo że proces zakończył się pomyślnie, wpisy błędów są rejestrowane w raporcie dziennika programu SQL Server, który przypomina następujący tekst:

The state of the local availability replica in availability group '\<Group name>' has changed from 'RESOLVING_NORMAL' to 'PRIMARY_PENDING'  
The state of the local availability replica in availability group '\<Group name>' has changed from 'PRIMARY_PENDING' to 'PRIMARY_NORMAL'

Uwaga 16.

Replika pomocnicza pomyślnie przechodzi ze RESOLVING_NORMAL stanu do PRIMARY_NORMAL stanu.

Objawy, jeśli automatyczne przejście w tryb failover nie powiedzie się

Jeśli automatyczne zdarzenie trybu failover nie powiedzie się, replika pomocnicza nie zostanie pomyślnie przeniesiona do roli podstawowej. W związku z tym replika dostępności zgłosi, że ta replika RESOLVING jest w stanie. Ponadto bazy danych dostępności raportują, że są w NOT SYNCHRONIZING stanie, a aplikacje nie mogą uzyskać dostępu do tych baz danych.

Na przykład na poniższej ilustracji program SQL Server Management Studio zgłasza, że replika pomocnicza jest w RESOLVING stanie, ponieważ proces automatycznego trybu failover nie może przenieść repliki pomocniczej do roli podstawowej.

W poniższych sekcjach omówiono kilka możliwych powodów, dla których automatyczne przejście w tryb failover może się nie powieść i jak zdiagnozować każdą przyczynę.

Przypadek 1: wartość "Maksymalna liczba niepowodzeń w określonym okresie" jest wyczerpana

Grupa dostępności ma właściwości zasobów klastra systemu Windows, takie jak maksymalna liczba niepowodzeń we właściwości Określony okres . Ta właściwość służy do unikania nieokreślonego przenoszenia zasobu klastrowanego w przypadku wystąpienia awarii wielu węzłów.

Aby zbadać i zdiagnozować, czy jest to przyczyna nieudanego przejścia w tryb failover, przejrzyj dziennik klastra systemu Windows (Cluster.log), a następnie sprawdź właściwość .

Krok 1. Przeglądanie danych w dzienniku klastra systemu Windows (Cluster.log)

1. Użyj programu Windows PowerShell, aby wygenerować dziennik klastra systemu Windows w węźle klastra hostujący replikę podstawową. W tym celu uruchom następujące polecenie cmdlet w oknie programu PowerShell z podwyższonym poziomem uprawnień w wystąpieniu programu SQL Server, które hostuje replikę podstawową:

   Get-ClusterLog -Node <SQL Server node name> -TimeSpan 15
   

   

   [! UWAGI]

   • Parametr -TimeSpan 15 w tym kroku zakłada, że problem, który jest diagnozowany, wystąpił w ciągu ostatnich 15 minut.
   • Domyślnie plik dziennika jest tworzony w folderze %WINDIR%\cluster\reports.

2. Otwórz plik Cluster.log w Notatniku, aby przejrzeć dziennik klastra systemu Windows.

3. W Notatniku wybierz pozycję Edytuj>znajdź, a następnie wyszukaj ciąg "failoverCount" na końcu pliku. W wynikach powinien zostać wyświetlony komunikat podobny do następującego komunikatu:

   Nie można przejąć grupy <Nazwa> zasobu, failoverCount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2

   

Krok 2. Sprawdzanie maksymalnej liczby niepowodzeń we właściwości Określony okres

1. Uruchom Menedżera klastra trybu failover.

2. W okienku nawigacji wybierz pozycję Role.

3. W okienku Role kliknij prawym przyciskiem myszy zasób klastrowany, a następnie wybierz pozycję Właściwości.

4. Wybierz kartę Tryb failover i wybierz wartość Maksymalna liczba niepowodzeń w określonym okresie .

   

   Uwaga 16.

   Domyślne zachowanie określa, że jeśli zasób klastrowany ulegnie awarii trzy razy w ciągu sześciu godzin, powinien pozostać w stanie niepowodzenia. W przypadku grupy dostępności oznacza to, że replika pozostaje w RESOLVING stanie .

Podsumowanie

Po przeanalizowaniu dziennika okaże się, że wartość parametru failoverCount 3 jest większa niż obliczona wartość argumentuFailoverThreshold 2. W związku z tym klaster systemu Windows nie może ukończyć operacji przejścia w tryb failover zasobu grupy dostępności do partnera trybu failover.

Rozwiązanie

Aby rozwiązać ten problem, zwiększ wartość Maksymalna liczba niepowodzeń w określonym okresie .

Uwaga 16.

Zwiększenie tej wartości może nie rozwiązać problemu. Może wystąpić bardziej krytyczny problem, który powoduje, że grupa dostępności nie powiedzie się wiele razy w krótkim okresie. Domyślnie ten okres wynosi 15 minut. Zwiększenie tej wartości może po prostu spowodować, że grupa dostępności nie powiedzie się więcej razy i pozostanie w stanie niepowodzenia. Zalecamy użycie agresywnego rozwiązywania problemów, aby określić, dlaczego automatyczne przechodzenie w tryb failover nadal występuje.

Przypadek 2: Niewystarczające uprawnienia urzędu NT\KONTA SYSTEM

Biblioteka DLL zasobu aparatu bazy danych programu SQL Server łączy się z wystąpieniem programu SQL Server hostujące replikę podstawową przy użyciu odBC w celu monitorowania kondycji. Poświadczenia logowania używane na potrzeby tego połączenia to lokalne konto logowania programu SQL Server NT AUTHORITY\SYSTEM . Domyślnie to lokalne konto logowania ma następujące uprawnienia:

• Zmienianie dowolnej grupy dostępności
• Łączenie z bazą danych SQL
• Wyświetlanie stanu serwera

NT AUTHORITY\SYSTEM Jeśli konto logowania nie ma żadnych z tych uprawnień dla partnera automatycznego trybu failover (repliki pomocniczej), program SQL Server nie może uruchomić wykrywania kondycji po wystąpieniu automatycznego przejścia w tryb failover. W związku z tym replika pomocnicza nie może przejść do roli podstawowej. Aby zbadać i zdiagnozować, czy jest to przyczyna, przejrzyj dziennik klastra systemu Windows. W tym celu wykonaj następujące kroki:

1. Użyj programu Windows PowerShell, aby wygenerować dziennik klastra systemu Windows w węźle klastra. W tym celu uruchom następujące polecenie cmdlet w oknie programu PowerShell z podwyższonym poziomem uprawnień w wystąpieniu programu SQL Server, które hostuje replikę pomocniczą, która nie przeszła do roli podstawowej:

   Get-ClusterLog -Node <SQL Server node name> -TimeSpan 15
   

   

2. Otwórz plik Cluster.log w Notatniku, aby przejrzeć dziennik klastra systemu Windows.

3. Znajdź wpis o błędzie podobny do następującego tekstu:

   Nie można uruchomić polecenia diagnostyki. Użytkownik nie ma uprawnienia do wykonania tej czynności.

   

Podsumowanie

Plik Cluster.log zgłasza, że występuje problem z uprawnieniami, gdy program SQL Server uruchamia polecenie diagnostyczne. W tym przykładzie awaria została spowodowana usunięciem uprawnień do wyświetlania stanu serwera z NT AUTHORITY\SYSTEM konta logowania w wystąpieniu programu SQL Server, które hostuje replikę pomocniczą pary automatycznego trybu failover.

Rozwiązanie

Aby rozwiązać ten problem, przyznaj wystarczające uprawnienia do konta logowania na NT AUTHORITY\SYSTEM potrzeby wykrywania kondycji biblioteki DLL zasobu aparatu bazy danych programu SQL Server.

Przypadek 3: Bazy danych dostępności nie są w stanie SYNCHRONIZOWANE

Aby automatycznie przejść w tryb failover, wszystkie bazy danych dostępności zdefiniowane w grupie dostępności muszą być w SYNCHRONIZED stanie między repliką podstawową a repliką pomocniczą. W przypadku automatycznego przejścia w tryb failover ten warunek synchronizacji musi zostać spełniony, aby upewnić się, że nie ma utraty danych. W związku z tym, jeśli jedna baza danych dostępności w grupie dostępności znajduje się w synchronizacji lub NOT SYNCHRONIZED stanie, automatyczne przejście w tryb failover nie spowoduje pomyślnego przeniesienia repliki pomocniczej do roli podstawowej.

Aby uzyskać więcej informacji na temat warunków wymaganych do automatycznego przejścia w tryb failover, zobacz Warunki wymagane dla automatycznego trybu failover i repliki zatwierdzania synchronicznego obsługują dwie sekcje ustawień trybu failover i trybu failover (zawsze włączone grupy dostępności).

Aby zbadać i zdiagnozować, czy jest to przyczyna nieudanego przejścia w tryb failover, przejrzyj dziennik błędów programu SQL Server. Powinien zostać wyświetlony wpis o błędzie podobny do następującego tekstu:

Co najmniej jedna baza danych nie jest zsynchronizowana lub nie dołączyła do grupy dostępności.

Aby sprawdzić, czy bazy danych dostępności były w SYNCHRONIZED stanie, wykonaj następujące kroki:

1. Połącz się z repliką pomocniczą.

2. Uruchom następujący skrypt SQL, aby sprawdzić is_failover_ready wartość wszystkich baz danych dostępności w grupie dostępności, która nie przełączyła się w tryb failover.

   Uwaga 16.

   Wartość zero dla dowolnej bazy danych dostępności może zapobiec automatycznemu przejściu w tryb failover. Ta wartość wskazuje, że baza danych dostępności nie SYNCHRONIZEDbyła .

   SELECT database_name, is_failover_ready FROM sys.dm_hadr_database_replica_cluster_states WHERE replica_id IN (SELECT replica_id FROM sys.dm_hadr_availability_replica_states)
   

   

Podsumowanie

Pomyślne automatyczne przejście w tryb failover grupy dostępności wymaga, aby wszystkie bazy danych dostępności znajdowały się w SYNCHRONIZED stanie . Aby uzyskać więcej informacji na temat trybów dostępności, zobacz Tryby dostępności w zawsze włączonych grupach dostępności.

Przypadek 4: Dla protokołów klienckich w repliki pomocniczej (podstawowej) wybrano konfigurację "Wymuszaj szyfrowanie protokołu", chociaż replika nie jest skonfigurowana do szyfrowania

Podczas pracy w trybie failover, gdy serwer podstawowy wykryje problem z kondycją, biblioteka DLL klastra w partnerze trybu failover (replika pomocnicza) próbuje nawiązać połączenie z repliką lokalną w celu zainicjowania monitorowania kondycji. Jest to część przejścia do roli podstawowej. Jeśli replika pomocnicza nie jest skonfigurowana do szyfrowania, ale ustawienie Wymuszanie szyfrowania protokołu jest przypadkowo ustawione w konfiguracji klienta, połączenie zakończy się niepowodzeniem, a przejście w tryb failover nie będzie możliwe.

Aby sprawdzić tę konfigurację:

1. Uruchom program SQL Server Configuration Manager.
2. W okienku po lewej stronie kliknij prawym przyciskiem myszy konfigurację klienta SQL Native Client 11.0, a następnie wybierz pozycję Właściwości.
3. W oknie dialogowym zaznacz ustawienie Wymuszanie szyfrowania protokołu. Jeśli jest ustawiona wartość Tak, zmień wartość na Nie.
4. Przetestuj ponownie tryb failover.

Podsumowanie

Monitorowanie kondycji zawsze włączone programu SQL Server używa lokalnego połączenia ODBC do monitorowania kondycji programu SQL Server. Wymuszanie szyfrowania protokołu powinno być włączone w sekcji Konfiguracja klienta programu SQL Server Configuration Manager tylko wtedy, gdy sam program SQL Server został skonfigurowany do wymuszania szyfrowania w programie SQL Server Configuration Manager w sekcji Konfiguracja sieci programu SQL Server. Aby uzyskać więcej informacji, zobacz Włączanie szyfrowanych połączeń z aparatem bazy danych.

Przypadek 5. Problemy z wydajnością w pomocniczej repliki lub węźle powodują niepowodzenie sprawdzania kondycji always on

Przed przełączeniem w tryb failover z repliki podstawowej do repliki pomocniczej biblioteka DLL zasobu aparatu bazy danych programu SQL Server łączy się z repliką pomocniczą w celu ustalenia kondycji repliki. Jeśli to połączenie nie powiedzie się z powodu problemów z wydajnością repliki pomocniczej, automatyczne przejście w tryb failover nie nastąpi.

Aby zbadać i zdiagnozować, czy jest to przyczyna, wykonaj następujące kroki:

1. Przejrzyj dziennik klastra w repliki pomocniczej, aby sprawdzić komunikat o błędzie "Nie można ukończyć procesu logowania z powodu opóźnienia podczas otwierania połączenia z serwerem".

   0000110c.00002bcc::2020/08/06-01:17:54.943 INFO  [RCM] move of group AOCProd01AG from CO2ICMV3SQL09(1) to CO2ICMV3SQL10(2) of type MoveType::Manual is about to succeed, failoverCount=3, lastFailoverTime=2020/08/05-02:08:54.524 targeted=true 
   00002a54.0000610c::2020/08/06-01:18:44.929 ERR   [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] ODBC Error: [08001] [Microsoft][SQL Server Native Client 11.0]Unable to complete login process due to delay in opening server connection (0) 
   00002a54.0000610c::2020/08/06-01:18:44.929 INFO  [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] Could not connect to SQL Server (rc -1) 
   00002a54.0000610c::2020/08/06-01:18:44.929 INFO  [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] SQLDisconnect returns following information 
   00002a54.0000610c::2020/08/06-01:18:44.929 ERR   [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] ODBC Error: [08003] [Microsoft][ODBC Driver Manager] Connection not open (0) 
   00002a54.0000610c::2020/08/06-01:18:44.931 ERR   [RES] SQL Server Availability Group <AOCProd01AG>: [hadrag] Failed to connect to SQL Server 
   00002a54.0000610c::2020/08/06-01:18:44.931 ERR   [RHS] Online for resource AOCProd01AG failed. 
   

   Taka sytuacja może wystąpić, jeśli przejście w tryb failover zostanie wykonane do pomocniczej repliki programu SQL Server, która ma zajęte istniejące obciążenie. Może to opóźnić odpowiedź programu SQL Server na próbę żądania połączenia kondycji usługi HADR i zapobiec pomyślnej próbie przejścia w tryb failover.

2. Aby określić, czy istnieje presja na harmonogramy systemu, użyj programu SQL Server Management Studio, aby uruchomić następujący skrypt w replice pomocniczej:

   USE MASTER 
   GO  
   WHILE 1=1 
   BEGIN 
   PRINT convert(varchar(20), getdate(),120) 
   DECLARE @max INT; 
   SELECT @max = max_workers_count 
   FROM sys.dm_os_sys_info; 
   SELECT GETDATE() AS 'CurrentDate',  
          @max AS 'TotalThreads',  
          SUM(active_Workers_count) AS 'CurrentThreads',  
          @max - SUM(active_Workers_count) AS 'AvailableThreads',  
          SUM(runnable_tasks_count) AS 'WorkersWaitingForCpu',  
          SUM(work_queue_count) AS 'RequestWaitingForThreads' 
          --SUM(current_workers_count) AS 'AssociatedWorkers' 
   FROM sys.dm_os_Schedulers 
   WHERE STATUS = 'VISIBLE ONLINE'; 
   wait for delay '0:0:15' 
   END
   

   Poniżej przedstawiono przykładowe dane wyjściowe poprzedniego zapytania:

   Bieżąca wartość daty	TotalThreads	CurrentThreads	AvailableThreads	WorkersWaitingForCpu	RequestWaitingForThreads
   2020-10-06 01:27:01.337	1216	361	855	33	0
   2020-10-06 01:27:08.340	1216	1412	-196	22	76
   2020-10-06 01:27:15.340	1216	1304	-88	2	161
   2020-10-06 01:27:22.340	1216	1242	-26	21	185
   2020-10-06 01:27:29.343	1216	1346	-130	19	476
   2020-10-06 01:27:36.350	1216	1350	-134	9	630
   2020-10-06 01:27:43.353	1216	1346	-130	13	539
   2020-10-06 01:27:50.360	1216	1378	-162	5	328
   2020-10-06 01:27:57.360	1216	197	1019	0	0

   Wysokie wartości zgłaszane i WorkersWaitingForCpu RequestWaitingForThreads wskazują, że rywalizacja o planowanie występuje i że program SQL Server nie może obsłużyć bieżącego obciążenia w odpowiednim czasie.

Rozwiązanie

Jeśli wystąpi ten problem, należy ponownie zrównoważyć obciążenie w replice pomocniczej lub rozważyć zwiększenie mocy obliczeniowej (dodawanie procesorów) na komputerach z uruchomionymi tymi obciążeniami.

Rozwiązywanie problemów z innymi zdarzeniami trybu failover w trybie failover

Aby monitorować kondycję nowej repliki podstawowej podczas pracy w trybie failover, należy lokalnie połączyć monitorowanie kondycji AlwaysOn z wystąpieniem programu SQL Server przechodzącym do roli podstawowej.

Oprócz bardziej typowych przyczyn omówionych w tym artykule istnieje wiele innych powodów, dla których ta próba połączenia może zakończyć się niepowodzeniem. Aby dokładniej zbadać próbę przejścia w tryb failover w tryb failover, przejrzyj dziennik klastra w partnerze trybu failover (replika, do której nie można przejść w tryb failover):

1. Użyj programu Windows PowerShell, aby wygenerować dziennik klastra systemu Windows w węźle klastra. W tym celu uruchom następujące polecenie cmdlet w oknie programu PowerShell z podwyższonym poziomem uprawnień w wystąpieniu programu SQL Server, które hostuje replikę pomocniczą, która nie przeszła do roli podstawowej. Dziennik klastra zostanie wygenerowany przez ostatnie 60 minut działania.

   Get-ClusterLog -Node <SQLServerNodeName> -TimeSpan 60
   

2. Aby przejrzeć dziennik klastra systemu Windows, otwórz plik Cluster.log w Notatniku.

3. Wyszukaj ciąg "Połącz z programem SQL Server", który występuje podczas nieudanego zdarzenia trybu failover.

4. Przejrzyj kolejne komunikaty logowania przy użyciu identyfikatora wątku (zobacz poniższy zrzut ekranu), aby skorelować zdarzenia powiązane ze zdarzeniem logowania. W poniższym przykładzie przedstawiono wyszukiwanie "Połącz z programem SQL Server". Pokazuje również użycie identyfikatora wątku (po lewej stronie) do zlokalizowania innej diagnostyki, która opisuje, dlaczego próba połączenia nie powiodła się.

   

W poniższych przykładach pokazano błędy połączeń z nową repliką podstawową.

Przykładowy zestaw 1

[hadrag] ODBC Error: [08001] [Microsoft][SQL Server Native Client 11.0]SQL Server Network
Interfaces: No client protocols are enabled and no protocol was specified in the connection
string [xFFFFFFFF]. (268435455)

Rozwiązanie

Uruchom menedżera konfiguracji programu SQL Server, a następnie sprawdź, czy pamięć współdzielona lub protokół TCP/IP jest włączona w obszarze Protokoły klienta dla konfiguracji klienta natywnego SQL.

Przykładowy zestaw 2

[hadrag] ODBC Error: [08001] [Microsoft][SQL Server Native Client 11.0]SQL Server Network
Interfaces: Server doesn't support requested protocol [xFFFFFFFF]. (268435455)

Rozwiązanie

Uruchom menedżera konfiguracji programu SQL Server, a następnie sprawdź, czy pamięć współdzielona lub protokół TCP/IP jest włączona w obszarze Protokoły klienta dla konfiguracji klienta natywnego SQL.

Przykładowy zestaw 3

000010b8.00001764::2020/12/02-16:52:49.808 ERR [RES] SQL Server Availability Group : [hadrag]
ODBC Error: [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]Cannot alter the availability
group 'ag', because it does not exist or you do not have permission. (15151)
000010b8.00000fd0::2020/12/02-17:01:14.821 ERR [RES] SQL Server Availability Group: [hadrag]
ODBC Error: [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]The user does not have permission to perform this action. (297)
000010b8.00001838::2020/12/02-17:10:04.427 ERR [RES] SQL Server Availability Group : [hadrag]
ODBC Error: [42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user
'SQLREPRO\NODE2$'. Reason: The account is disabled. (18470)

Rozwiązanie

Przejrzyj przypadek 2: Niewystarczające uprawnienia urzędu NT\KONTA SYSTEM.