Rozwiązywanie problemów z automatycznym trybem failover w środowiskach SQL Server Always On

Ten artykuł ułatwia rozwiązywanie problemów występujących podczas automatycznego trybu failover w usłudze Microsoft SQL Server.

Oryginalna wersja produktu: SQL Server
Oryginalny numer KB: 2833707

Podsumowanie

SQL Server zawsze włączone grupy dostępności można skonfigurować do automatycznego przełączania w tryb failover. Jeśli w wystąpieniu SQL Server hostującej replikę podstawową zostanie wykryty problem z kondycją, rolę podstawową można przenieść do partnera automatycznego trybu failover (repliki pomocniczej). Jednak repliki pomocniczej nie zawsze można przenieść do roli podstawowej. W niektórych przypadkach można go 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ć w celu zdiagnozowania przyczyny tych błędów.

Objawy, jeśli automatyczne przejście w tryb failover zostanie pomyślnie wyzwolone

Po wyzwoleniu automatycznego trybu failover w wystąpieniu SQL Server hostującej replikę podstawową replika pomocnicza przechodzi do RESOLVING roli, a następnie do roli podstawowej. Mimo że proces zakończył się pomyślnie, wpisy błędów są rejestrowane w raporcie dziennika 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

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

Objawy, jeśli automatyczne przejście w tryb failover zakończy się niepowodzeniem

Jeśli automatyczne zdarzenie trybu failover nie powiedzie się, replika pomocnicza nie przejdzie pomyślnie 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 zgłaszają, że są w NOT SYNCHRONIZING stanie, a aplikacje nie mogą uzyskać dostępu do tych baz danych.

Na przykład na poniższej ilustracji SQL Server Management Studio raporty, ż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 przyczyn niepowodzenia automatycznego trybu failover i sposobu diagnozowania każdej przyczyny.

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 nieograniczonego przenoszenia zasobu klastrowanego w przypadku wystąpienia wielu awarii 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 Windows PowerShell, aby wygenerować dziennik klastra systemu Windows w węźle klastra hostującym replikę podstawową. W tym celu uruchom następujące polecenie cmdlet w oknie programu PowerShell z podwyższonym poziomem uprawnień w wystąpieniu SQL Server hostującym 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>wyszukiwanie, a następnie wyszukaj ciąg "failoverCount" na końcu pliku. W wynikach powinien zostać wyświetlony komunikat podobny do następującego:

   Nie można przełączać w tryb failover nazwy zasobu grupy<, trybu failoverCount 3, trybu 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 wartości Określony okres .

   

   Uwaga

   Zachowanie domyślne określa, że jeśli zasób klastrowany zakończy się niepowodzeniem 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.

Wniosku

Po przeanalizowaniu dziennika okaże się, że wartość failoverCountwynosząca 3 jest większa niż wartość computedFailoverThresholdwynosząca 2. W związku z tym klaster systemu Windows nie może ukończyć operacji trybu failover zasobu grupy dostępności dla partnera trybu failover.

Rozwiązanie

Aby rozwiązać ten problem, zwiększ wartość Maksymalna liczba niepowodzeń w wartości Określony okres .

Uwaga

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 wielokrotnie kończy się niepowodzeniem 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 będzie więcej razy kończyć się niepowodzeniem i pozostanie w stanie niepowodzenia. Zalecamy użycie agresywnego rozwiązywania problemów, aby określić, dlaczego automatyczna praca w trybie failover nadal występuje.

Przypadek 2. Niewystarczające uprawnienia do konta NT Authority\SYSTEM

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

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

NT AUTHORITY\SYSTEM Jeśli konto logowania nie ma żadnego z tych uprawnień dla partnera automatycznego trybu failover (repliki pomocniczej), SQL Server nie może rozpocząć wykrywania kondycji w przypadku 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. Aby to zrobić, wykonaj następujące kroki.

1. Użyj 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 SQL Server hostującej 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 błędu podobny do następującego tekstu:

   Nie można uruchomić polecenia diagnostycznego. Użytkownik nie ma uprawnień do wykonania tej akcji.

   

Wniosku

Plik Cluster.log zgłasza, że problem z uprawnieniami występuje, gdy SQL Server uruchamia polecenie diagnostyczne. W tym przykładzie awaria została spowodowana usunięciem uprawnienia Wyświetl stan serwera z NT AUTHORITY\SYSTEM konta logowania w wystąpieniu SQL Server hostującym replikę pomocniczą pary automatycznego trybu failover.

Rozwiązanie

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

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

Aby automatycznie przełączać się w tryb failover, wszystkie bazy danych dostępności zdefiniowane w grupie dostępności muszą znajdować się w stanie między repliką podstawową SYNCHRONIZED 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 jest w stanie synchronizacji lub NOT SYNCHRONIZED stanu, automatyczne przejście w tryb failover nie spowoduje pomyślnego przeniesienia repliki pomocniczej do roli podstawowej.

Aby uzyskać więcej informacji na temat wymaganych warunków automatycznego trybu failover, zobacz Warunki wymagane dla automatycznego trybu failover, a repliki synchroniczne zatwierdzania 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 SQL Server. Powinien zostać znaleziony wpis błędu 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 są 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ść dla wszystkich baz danych dostępności w grupie dostępności, która nie przekroczęła trybu failover.

   Uwaga

   Wartość zero dla dowolnej bazy danych dostępności może uniemożliwić automatyczne przejście 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)
   

   

Wniosku

Pomyślne automatyczne przejście w tryb failover grupy dostępności wymaga, aby wszystkie bazy danych dostępności były 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 replice pomocniczej (docelowej podstawowej) wybrano konfigurację "Wymuś szyfrowanie protokołu", chociaż replika nie jest skonfigurowana do szyfrowania

Podczas pracy w trybie failover, gdy serwer podstawowy wykryje problem z kondycją, bibliotekę DLL klastra u partnera trybu failover (repliki pomocniczej) 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 Wymuszaj szyfrowanie protokołu zostało przypadkowo ustawione w konfiguracji klienta, połączenie zakończy się niepowodzeniem i nie będzie możliwe przejście w tryb failover.

Aby sprawdzić tę konfigurację:

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

Wniosku

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

Przypadek 5. Problemy z wydajnością repliki pomocniczej lub węzła powodują niepowodzenie zawsze włączonych kontroli kondycji

Przed przejściem w tryb failover z repliki podstawowej do repliki pomocniczej SQL Server biblioteki DLL zasobu aparatu bazy danych nawiązuje połączenie z repliką pomocniczą w celu ustalenia kondycji repliki. Jeśli to połączenie zakończy się niepowodzeniem 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 repliki pomocniczej, aby sprawdzić komunikat o błędzie "Nie można ukończyć procesu logowania z powodu opóźnienia w otwarciu połączenia serwera".

   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ć w przypadku przejścia w tryb failover do repliki pomocniczej SQL Server, która ma zajęte istniejące obciążenie. Może to opóźnić odpowiedź SQL Server na próbę połączenia kondycji usługi HADR i zapobiec pomyślnej próbie przejścia w tryb failover.

2. Aby ustalić, czy istnieje presja na harmonogramy systemowe, użyj 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:

   CurrentDate	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 dla WorkersWaitingForCpu i RequestWaitingForThreads wskazują, że występuje rywalizacja o planowanie i że SQL Server nie może obsługiwać bieżącego obciążenia w odpowiednim czasie.

Rozwiązanie

Jeśli wystąpi ten problem, ponownie zbalansuj obciążenie repliki pomocniczej lub rozważ zwiększenie mocy obliczeniowej (dodaj procesory) na komputerach z tymi obciążeniami.

Rozwiązywanie problemów z innymi zdarzeniami trybu failover zakończonymi niepowodzeniem

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

Oprócz bardziej typowych przyczyn, które zostały omówione 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 trybie failover, przejrzyj dziennik klastra u partnera trybu failover (repliki, do którego nie można przełączyć się w tryb failover):

1. Użyj 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 SQL Server hostującej replikę pomocniczą, która nie przeszła do roli podstawowej. Dziennik klastra zostanie wygenerowany w ciągu ostatnich 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 SQL Server", który przypada 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 frazy "Połącz z SQL Server". Pokazuje on również użycie identyfikatora wątku (po lewej stronie) do zlokalizowania innych diagnostyki opisujących przyczynę niepowodzenia próby nawiązania połączenia.

   

W poniższych przykładach przedstawiono 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 SQL Server Configuration Manager, a następnie sprawdź, czy włączono pamięć udostępnioną lub protokół TCP/IP 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 SQL Server Configuration Manager, a następnie sprawdź, czy włączono pamięć udostępnioną lub protokół TCP/IP 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 sprawę 2: Niewystarczające uprawnienia do konta NT Authority\SYSTEM.