Rozwiązywanie problemów z sporadycznymi limitami czasu połączenia między replikami grupy dostępności

Ten artykuł ułatwia diagnozowanie sporadycznych limitów czasu połączenia zgłaszanych między replikami grupy dostępności.

Objawy i skutki sporadycznych limitów czasu połączenia repliki grupy dostępności

Wykonywanie zapytań względem replik podstawowych i pomocniczych zwraca różne wyniki

Obciążenia tylko do odczytu, które wysyłają zapytania do replik pomocniczych, mogą wysyłać zapytania dotyczące nieaktualnych danych. Jeśli wystąpi sporadyczne przekroczenie limitu czasu połączenia repliki, zmiany danych w podstawowej bazie danych repliki nie zostaną jeszcze odzwierciedlone w pomocniczej bazie danych podczas wykonywania zapytań dotyczących tych samych danych. Aby uzyskać więcej informacji, zobacz sekcję Opóźnienie danych w repliki pomocniczej.

Grupa dostępności raportu diagnostycznego nie jest zsynchronizowana

Pulpit nawigacyjny Always On w programie SQL Server Management Studio może zgłaszać złą kondycję grupy dostępności, która ma repliki, które mają stan Nie synchronizuje . Można również zaobserwować, że repliki raportów pulpitu nawigacyjnego Zawsze włączone mają stan Nie synchronizowane .

Podczas przeglądania dzienników błędów programu SQL Server tych replik można obserwować komunikaty, takie jak następujące, które wskazują, że wystąpił limit czasu połączenia między replikami w grupie dostępności:

Dziennik błędów z repliki podstawowej

2023-02-15 07:10:55.500 spid43s Always On availability groups connection with secondary database terminated for primary database 'agdb' on the availability replica 'SQL19AGN2' with Replica ID: {<replicaid>}. This is an informational message only. No user action is required.

Dziennik błędów z repliki pomocniczej

2023-02-15 07:11:03.100 spid31s A connection time-out has occurred on a previously established connection to availability replica 'SQL19AGN1' with id [<replicaid>]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

2023-02-15 07:11:03.100 spid31s Always On Availability Groups connection with primary database terminated for secondary database 'agdb' on the availability replica 'SQL19AGN1' with Replica ID: {<replicaid>}. This is an informational message only. No user action is required.

Sporadyczne problemy z połączeniem mogą mieć wpływ na gotowość repliki pomocniczej do trybu failover

Jeśli skonfigurujesz grupę dostępności na potrzeby automatycznego trybu failover, a synchroniczny partner zatwierdzania trybu failover zostanie sporadycznie odłączony od podstawowego, automatyczne przejście w tryb failover może zakończyć się niepowodzeniem.

Możesz wykonać zapytanie, sys.dm_hadr_database_replia_cluster_states aby określić, czy baza danych grupy dostępności jest gotowa do pracy w trybie failover w tej chwili. Oto przykład wyników, jeśli punkt końcowy dublowania został zatrzymany w repliki pomocniczej:

SELECT drcs.database_name, drcs.is_failover_ready, ar.replica_server_name, ars.role_desc, ars.connected_state_desc,
ars.last_connect_error_description, ars.last_connect_error_number, ar.endpoint_url
FROM sys.dm_hadr_availability_replica_states ars JOIN sys.availability_replicas ar ON ars.replica_id=ar.replica_id
JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ar.replica_id=drcs.replica_id
WHERE ars.role_desc='SECONDARY'

Automatyczne przełączanie w tryb failover może nie spowodować przełączyć grupy dostępności w tryb online w roli głównej na komputerze partnera trybu failover, jeśli przejście w tryb failover zbiega się z limitem czasu połączenia repliki.

Co wskazują błędy przekroczenia limitu czasu połączenia?

Wartość domyślna to 10 sekund dla ustawienia repliki grupy dostępności. SESSION_TIMEOUT To ustawienie jest skonfigurowane dla każdej repliki. Określa, jak długo replika czeka na odebranie odpowiedzi z repliki partnera, zanim zgłosi przekroczenie limitu czasu połączenia. Jeśli replika nie otrzyma odpowiedzi z repliki partnera, zgłasza limit czasu połączenia w dzienniku błędów programu Microsoft SQL Server i dzienniku aplikacji systemu Windows. Replika, która zgłasza limit czasu natychmiast próbuje ponownie nawiązać połączenie, i będzie nadal próbować co pięć sekund.

Zazwyczaj limit czasu połączenia jest wykrywany i zgłaszany tylko przez jedną replikę. Jednak limit czasu połączenia może być zgłaszany przez obie repliki w tym samym czasie. Istnieją różne wersje tego komunikatu, w zależności od tego, czy nastąpiło przekroczenie limitu czasu połączenia przy użyciu wcześniej ustanowionego połączenia, czy nowego połączenia:

Message 35206 A connection timeout has occurred on a previously established connection to availability replica '<replicaname>' with id [<replicaid>]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

Message 35201 A connection timeout has occurred while attempting to establish a connection to availability replica '<replicaname>' with id [<replicaid>]. Either a networking or firewall issue exists, or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

Replika partnera może nie wykryć limitu czasu. Jeśli tak, może zgłosić komunikat 35201 lub 35206. Jeśli tak nie jest, zgłasza utratę połączenia z poszczególnymi bazami danych grup dostępności:

Message 35267 Always On Availability Groups connection with primary/secondary database terminated for primary/secondary database '<databasename>' on the availability replica '<replicaname>' with Replica ID: {<replicaid>}. This is an informational message only. No user action is required.

Oto przykład raportów programu SQL Server do dziennika błędów: Jeśli zatrzymasz punkt końcowy dublowania w repliki podstawowej, replika pomocnicza wykryje przekroczenie limitu czasu połączenia, a komunikaty 35206 i 35267 są zgłaszane w pomocniczym dzienniku błędów repliki:

2023-02-15 07:11:03.100 spid31s A connection timeout has occurred on a previously established connection to availability replica 'SQL19AGN1' with id [<replicaid>]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

2023-02-15 07:11:03.100 spid31s Always On Availability Groups connection with primary database terminated for secondary database 'agdb' on the availability replica 'SQL19AGN1' with Replica ID:[<replicaid>]. This is an informational message only. No user action is required.

W tym przykładzie replika podstawowa nie wykryła żadnego przekroczenia limitu czasu połączenia, ponieważ nadal mogła komunikować się z pomocniczą bazą danych i zgłosiła komunikat 35267 dla każdej bazy danych grupy dostępności (w tym przykładzie istnieje tylko jedna baza danych "agdb"):

2023-02-15 07:10:55.500 spid43s Always On Availability Groups connection with secondary database terminated for primary database 'agdb' on the availability replica 'SQL19AGN2' with Replica ID: {<replicaid>}. This is an informational message only. No user action is required.

Przyczyny przekroczenia limitu czasu połączenia repliki

Problem z aplikacją

Program SQL Server może być zajęty z dowolnego z kilku powodów i nie obsługuje dublowania połączenia punktu końcowego w okresie grupy SESSION_TIMEOUT dostępności. Powoduje to przekroczenie limitu czasu połączenia. Oto niektóre z następujących powodów:

• Program SQL Server korzysta z 100 procent wykorzystania procesora CPU. Oznacza to, że program SQL Server lub inna aplikacja napędza procesor CPU przez kilka sekund naraz.

• W programie SQL Server nie są zwracane zdarzenia harmonogramu. Wątki programu SQL Server są odpowiedzialne za uzyskanie harmonogramu (procesora CPU) do innych wątków w celu ukończenia pracy, jeśli wątek nie daje się w odpowiednim czasie.

• Program SQL Server doświadcza wyczerpania wątków roboczych, problemów z brakiem pamięci lub problemów z aplikacją, które mają wpływ na możliwość obsługi połączenia punktów końcowych dublowania.

Problem z siecią

Wymaga to zbierania dzienników śledzenia sieci w replikach podstawowych i pomocniczych po wyzwoleniu błędu. W tym celu można sprawdzić opóźnienie sieci i porzucone pakiety.

Jak zdiagnozować limity czasu połączenia repliki

W przypadku problemu z aplikacjami, które uniemożliwiają programowi SQL Server obsługę połączenia z repliką partnera, w tej sekcji opisano sposób analizowania dzienników programu SQL Server. Te porady mogą pomóc w zidentyfikowaniu głównej przyczyny przekroczenia limitu czasu połączenia repliki. Ta sekcja kończy się bardziej zaawansowanymi wskazówkami dotyczącymi zbierania śladów sieci po przekroczeniu limitu czasu połączenia, dzięki czemu można sprawdzić stan sieci.

Ocena chronometrażu i lokalizacji przekroczenia limitu czasu połączenia repliki

Przejrzyj historię, częstotliwość i trendy limitów czasu połączenia. Użycie komunikatów, które można znaleźć w dzienniku błędów programu SQL Server, jest doskonałym sposobem na wykonanie tej czynności. Gdzie są zgłaszane limity czasu połączenia? Czy są one stale zgłaszane w repliki podstawowej lub pomocniczej? Kiedy wystąpiły błędy? Czy wystąpiły w określonym tygodniu miesiąca, dniu tygodnia lub o porze dnia? Czy inne zaplanowane konserwacje lub przetwarzanie wsadowe odpowiadają okresom, w których zaobserwowano przekroczenia limitu czasu połączenia? Ta ocena może pomóc w określeniu zakresu i skorelowania limitów czasu połączenia w celu zidentyfikowania głównej przyczyny.

Przejrzyj sesję zdarzeń rozszerzonych AlwaysOn_health

Rozszerzona sesja AlwaysOn_health zdarzeń została rozszerzona w celu uwzględnienia ucs_connection_setup zdarzenia, które jest wyzwalane, gdy replika nawiązuje połączenie z repliką partnera. Może to być przydatne podczas rozwiązywania problemów z przekroczeniem limitu czasu połączenia.

Uwaga 16.

Zdarzenie ucs_connection_setup rozszerzone zostało dodane do najnowszych aktualizacji zbiorczych programu SQL Server. Aby obserwować to zdarzenie rozszerzone, należy uruchomić najnowsze aktualizacje zbiorcze.

Zapytania zawsze włączone widoki zarządzania rozproszonego (DMV)

Aby uzyskać więcej informacji na temat stanu połączonego repliki, możesz wykonywać zapytania dotyczące dynamicznych widoków DMV zawsze włączonych. To zapytanie zgłasza tylko stan połączenia i wszelkie błędy skojarzone z przekroczeniem limitu czasu połączenia w momencie wystąpienia problemów. Jeśli problemy z połączeniem są sporadycznie, zapytanie może nie przechwycić stanu rozłączonego łatwo.

SELECT ar.replica_server_name, ars.role_desc, ars.connected_state_desc,
ars.last_connect_error_description, ars.last_connect_error_number, ar.endpoint_url
FROM sys.dm_hadr_availability_replica_states ars JOIN sys.availability_replicas ar ON ars.replica_id=ar.replica_id

W poniższym przykładzie pokazano stan trwałego rozłączenia, ponieważ punkt końcowy dublowania w repliki podstawowej został zatrzymany. Wykonując zapytanie względem repliki podstawowej, zawsze włączony dynamiczny widok zarządzania może zgłaszać wszystkie repliki podstawowe i pomocnicze (punkt końcowy jest wyłączony w repliki podstawowej).

Wysyłając zapytanie do repliki pomocniczej, dynamiczne widoki zarządzania zawsze włączone zgłaszają tylko replikę pomocniczą.

Przejrzyj sesję zdarzeń rozszerzonych Always On

1. Połącz się z każdą repliką przy użyciu programu SQL Server Management Studio (SSMS) Eksplorator obiektów i otwórz AlwaysOn_health rozszerzone pliki zdarzeń.

2. W programie SSMS przejdź do pozycji Plik>otwórz, a następnie wybierz pozycję Scal pliki rozszerzonych zdarzeń.

3. Kliknij przycisk Dodaj.

4. W oknie dialogowym Otwieranie pliku przejdź do plików w katalogu \LOG programu SQL Server.

5. Naciśnij Control, a następnie wybierz pliki, których nazwa zaczyna się od "AlwaysOn_healthxxx.xel".

6. Wybierz pozycję Otwórz, a następnie wybierz przycisk OK.

   W programie SSMS powinien zostać wyświetlone nowe okno z kartami, które pokazuje zdarzenia AlwaysOn.

   Poniższy zrzut ekranu przedstawia AlwaysOn_health dane z repliki pomocniczej. Pierwsze opisane pole pokazuje utratę połączenia po zatrzymaniu punktu końcowego w repliki podstawowej. Drugie opisane pole przedstawia błąd połączenia, który występuje przy następnym próbie nawiązania połączenia z repliką podstawową.

   

Sprawdź, czy zdarzenia niepowołane powodują przekroczenie limitu czasu połączenia

Jedną z najczęstszych przyczyn, dla których replika dostępności nie może obsługiwać połączenia repliki partnera, jest harmonogram nieodpowiądujący. Aby uzyskać więcej informacji na temat harmonogramów, zobacz Rozwiązywanie problemów z planowaniem i uzyskiwaniem wydajności programu SQL Server.

Program SQL Server śledzi nieodpowidające zdarzenia harmonogramu, które są od 5 do 10 sekund. Zgłasza te zdarzenia w punkcie TrackingNonYieldingScheduler danych wyjściowych sp_server_diagnostics query_processing składnika.

Aby sprawdzić, czy nie są zwracane zdarzenia, które mogą powodować przekroczenie limitu czasu połączenia repliki, wykonaj następujące kroki:

1. Utwórz zadanie agenta SQL, które rejestruje sp_server_diagnostics co pięć sekund.

2. Zaplanuj to zadanie na serwerze, który nie zgłasza limitu czasu połączenia. Oznacza to, że jeśli replika serwera A zgłasza limit czasu połączenia repliki w dzienniku błędów, skonfiguruj zadanie agenta SQL w repliki partnera, serwer B. Alternatywnie, jeśli widzisz przekroczenia limitu czasu połączenia w obu replikach, utwórz zadanie na obu replikach.

3. Uruchom następujący plik wsadowy, aby utworzyć zadanie uruchamiane sp_server_diagnostics co pięć sekund, dołącza dane wyjściowe do pliku tekstowego, a następnie uruchamia zadanie. Polecenie w poniższym przykładzie sp_server_diagnostics 5 jest wykonywane co pięć sekund. Nie trzeba więc planować uruchamiania tego zadania co pięć sekund, po prostu uruchomić zadanie i będzie ono uruchamiane do momentu zatrzymania, co pięć sekund:

   USE [msdb]
   GO
   DECLARE @ReturnCode INT
   SELECT @ReturnCode = 0
   DECLARE @jobId BINARY(16)
   EXEC @ReturnCode = msdb.dbo.sp_add_job @job_name=N'Run sp_server_diagnostics',
   @owner_login_name=N'sa', @job_id = @jobId OUTPUT
   /****** Object: Step [Run SP_SERVER_DIAGNOSTICS] Script Date: 2/15/2023 4:20:41 PM ******/
   EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'Run SP_SERVER_DIAGNOSTICS',
   @subsystem=N'TSQL',
   @command=N'sp_server_diagnostics 5',
   @database_name=N'master',
   @output_file_name=N'D:\cases\2423\sp_server_diagnostics_output.out',
   @flags=2
   EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'
   EXEC sp_start_job 'Run sp_server_diagnostics'
   

   Uwaga 16.

   W tych poleceniach zmień na @output_file_name prawidłową ścieżkę i podaj nazwę pliku.

Analiza wyników

Po zgłoszeniu limitu czasu połączenia zanotuj znacznik czasu zdarzenia przekroczenia limitu czasu, który jest wyświetlany w dzienniku błędów programu SQL Server. W przypadku replik w poniższym przykładzie SQL19AGN1 zgłaszano limity czasu połączenia repliki. W związku z tym zadanie agenta SQL zostało utworzone w programie SQL19AGN2, w repliki partnera. Następnie w dzienniku SQL19AGN1 błędów zgłoszono limit czasu połączenia o godzinie 07:24:31.

Następnie dane wyjściowe zadania agenta SQL uruchamiane sp_server_diagnostics są sprawdzane w czasie raportowania, w szczególności przeglądając TrackingNonYieldingScheduler punkt danych w danych wyjściowych query_processing składnika. Dane wyjściowe zgłaszają, że harmonogram nieowartościowy został śledzony (jako wartość szesnastkowa niezerowa) na serwerze SQL19AGN2 (o godzinie 07:24:33) w czasie raportowania limitu czasu połączenia repliki w SQL19AGN1 (o godzinie 07:24:31).

Uwaga 16.

sp_server_diagnostics Następujące dane wyjściowe są łączone w celu wyświetlenia zarówno (sygnatury create_time czasowej) jak i query_processing TrackingNonYieldingScheduler wyników.

Badanie zdarzenia harmonogramu, które nie daje

Jeśli sprawdzono z wcześniejszych kroków diagnostyki, że zdarzenie niepochodzące z powodu przekroczenia limitu czasu połączenia repliki:

1. Zidentyfikuj obciążenia uruchomione w programie SQL Server w czasie uruchamiania zdarzeń, które nie dają.

2. Podobnie jak w przypadku przekroczenia limitu czasu połączenia repliki, poszukaj trendów w tych zdarzeniach w miesiącu, dniu lub tygodniu, które występują.

3. Zbierz śledzenie monitora wydajności w systemie, w którym wykryto zdarzenie niepochodzące.

4. Zbierz kluczowe liczniki wydajności zasobów systemowych, w tym Procesor::% Czas procesora, Pamięć::Dostępne bajty MBytes, Dysk logiczny::Średnia długość kolejki dysku i Dysk logiczny::Średni dysk s/transfer.

5. Jeśli jest to konieczne, otwórz zdarzenie pomocy technicznej programu SQL Server, aby uzyskać dalszą pomoc w znalezieniu głównej przyczyny tych nieodpowiadujących zdarzeń. Udostępnij zebrane dzienniki w celu dalszej analizy.

Zaawansowane zbieranie danych: zbieranie danych śledzenia sieci podczas przekroczenia limitu czasu połączenia

Jeśli poprzednia diagnostyka aplikacji programu SQL Server nie przyniosła głównej przyczyny, należy sprawdzić sieć. Pomyślna analiza sieci wymaga zebrania śledzenia sieci obejmującego czas przekroczenia limitu czasu połączenia.

Poniższa procedura uruchamia śledzenie sieci systemu Windows netsh na replikach, na których limity czasu połączenia są zgłaszane w dziennikach błędów programu SQL Server. Zaplanowane zadanie zdarzenia systemu Windows jest wyzwalane po zarejestrowaniu jednego z błędów połączenia z programem SQL Server w dzienniku aplikacji. Zaplanowane zadanie uruchamia polecenie, aby zatrzymać netsh śledzenie sieci, aby dane śledzenia sieci kluczy nie są zastępowane. W tych krokach przyjęto również ścieżkę *F:* dla dzienników wsadowych i śledzenia. Dostosuj tę ścieżkę do środowiska.

1. Uruchom ślad sieciowy, jak pokazano w poniższym fragmencie kodu, w dwóch replikach, na których występują przekroczenia limitu czasu połączenia:

   netsh trace start capture=yes persistent=yes overwrite=yes maxsize=500 tracefile=f:\trace.etl
   

2. Utwórz zaplanowane zadania systemu Windows, które zatrzymają netsh śledzenie zdarzeń 35206 lub 35267. Te zadania można utworzyć w wierszu polecenia administracyjnego:

   schtasks /Create /tn Event35206Task /tr F:\stoptrace.bat /SC ONEVENT /EC Application /MO *[System/EventID=35206] /f /RL HIGHEST
   
   schtasks /Create /tn Event35267Task /tr F:\stoptrace.bat /SC ONEVENT /EC Application /MO *[System/EventID=35267] /f /RL HIGHEST
   

3. Po wystąpieniu zdarzenia i zatrzymaniu i przechwyceniu ONEVENT śladów sieci można usunąć zadania:

   PS C:\Users\sqladmin> Schtasks /Delete /tn Event35206Task /F
   PS C:\Users\sqladmin> Schtasks /Delete /tn Event35267Task /F
   

Analiza śledzenia sieci wykracza poza zakres tego narzędzia do rozwiązywania problemów. Jeśli nie możesz zinterpretować śledzenia sieci, skontaktuj się z zespołem pomocy technicznej programu Microsoft SQL Server i podaj ślad wraz z innymi żądanymi plikami dziennika na potrzeby analizy głównej przyczyny.

Co jeszcze mogę zrobić, aby ograniczyć limity czasu połączenia?

Domyślna grupa dostępności, SESSION_TIMEOUT, jest skonfigurowana przez 10 sekund. Możesz ograniczyć limity czasu połączenia, dostosowując właściwość repliki SESSION_TIMEOUT grupy dostępności. To ustawienie jest na replikę. Dostosuj go dla repliki podstawowej i każdej repliki pomocniczej, której dotyczy problem. Oto przykład składni. Wartość domyślna SESSION_TIMEOUT to 10. W związku z tym można użyć wartości 15 jako następnej wartości.

ALTER AVAILABILITY GROUP ag
MODIFY REPLICA ON 'SQL19AGN1' WITH (SESSION_TIMEOUT = 15);