Udostępnij za pośrednictwem


Obsługa klienta SqlClient w celu zapewnienia wysokiej dostępności i odzyskiwania po awarii

W tym artykule omówiono obsługę klienta SqlClient (dodano w programie .NET Framework 4.5) w celu zapewnienia wysokiej dostępności i odzyskiwania po awarii z funkcjami Always On: Zawsze włączone grupy dostępności (AGs) i wystąpienia klastra trybu failover zawsze włączone (FCI) z programem SQL Server 2012 lub nowszym.

Teraz można określić odbiornik grupy dostępności lub nazwę wystąpienia klastra trybu failover we właściwości połączenia. Jeśli aplikacja SqlClient jest połączona z bazą danych, która przechodzi w tryb failover, oryginalne połączenie zostanie przerwane i aplikacja musi otworzyć nowe połączenie, aby kontynuować pracę po przejściu w tryb failover.

Jeśli nie łączysz się z grupą dostępności lub wystąpieniem klastra trybu failover, a wiele adresów IP jest skojarzonych z nazwą hosta, program SqlClient będzie iterować sekwencyjnie przez wszystkie adresy IP skojarzone z wpisem DNS. Może to być czasochłonne, jeśli pierwszy adres IP zwrócony przez serwer DNS nie jest powiązany z żadną kartą interfejsu sieciowego. Podczas łączenia wystąpienia klastra trybu failover lub odbiornika grupy dostępności program SqlClient próbuje nawiązać połączenia ze wszystkimi adresami IP równolegle. Jeśli próba połączenia zakończy się pomyślnie, sterownik odrzuci wszelkie oczekujące próby nawiązania połączenia.

Uwaga

Zwiększenie limitu czasu połączenia i zaimplementowanie logiki ponawiania połączenia zwiększy prawdopodobieństwo, że aplikacja połączy się z grupą dostępności. Ponadto, ponieważ połączenie może zakończyć się niepowodzeniem z powodu przejścia w tryb failover, należy zaimplementować logikę ponawiania próby połączenia, ponowić próbę nawiązania połączenia zakończonego niepowodzeniem do momentu ponownego nawiązania połączenia.

Następujące właściwości połączenia zostały dodane do programu SqlClient w programie .NET Framework 4.5:

  • ApplicationIntent
  • MultiSubnetFailover

Możesz programowo zmodyfikować te słowa kluczowe parametry połączenia za pomocą następujących elementów:

Uwaga

Ustawienie MultiSubnetFailover na true wartość nie jest wymagane w programie .NET Framework w wersji 4.6.1 lub nowszej. Jest to wymagane w programach .NET Core i .NET 5+.

Nawiązywanie połączenia za pomocą funkcji MultiSubnetFailover

Zawsze określaj MultiSubnetFailover=True podczas nawiązywania połączenia z wystąpieniem klastra trybu failover lub odbiornikiem grupy dostępności. MultiSubnetFailover umożliwia szybsze przechodzenie w tryb failover dla wszystkich grup dostępności i wystąpień klastra trybu failover w programie SQL Server 2012 lub nowszym oraz znacznie skraca czas pracy w trybie failover dla topologii zawsze włączonej pojedynczej i wielu podsieci. Podczas trybu failover z wieloma podsieciami klient próbuje równolegle nawiązać połączenia. Podczas pracy w trybie failover podsieci klient agresywnie ponawia próbę połączenia TCP.

Właściwość MultiSubnetFailover połączenia wskazuje, że aplikacja używa grupy dostępności lub wystąpienia klastra trybu failover, a program SqlClient spróbuje nawiązać połączenie z bazą danych w podstawowym wystąpieniu programu SQL Server, próbując nawiązać połączenie ze wszystkimi adresami IP. Gdy MultiSubnetFailover=True jest określony dla połączenia, klient ponawia próbę połączenia TCP szybciej niż domyślne interwały transmit TCP systemu operacyjnego. Umożliwia to szybsze ponowne nawiązywanie połączenia po przejściu w tryb failover grupy dostępności lub wystąpienia klastra trybu failover i ma zastosowanie zarówno do grup dostępności pojedynczej, jak i wielu podsieci oraz wystąpień klastra trybu failover.

Aby uzyskać więcej informacji na temat słów kluczowych parametry połączenia w programie SqlClient, zobacz ConnectionString.

Określenie podczas nawiązywania MultiSubnetFailover=True połączenia z czymś innym niż grupa dostępności lub wystąpienie klastra trybu failover może spowodować negatywny wpływ na wydajność i nie jest obsługiwane.

Skorzystaj z poniższych wskazówek, aby nawiązać połączenie z serwerem przy użyciu jednej z funkcji Always On:

  • Użyj właściwości połączenia podczas nawiązywania MultiSubnetFailover połączenia z jedną podsiecią lub wieloma podsieciami; poprawi wydajność obu tych podsieci.

  • Aby nawiązać połączenie z grupą dostępności, określ odbiornik grupy dostępności jako serwer w parametry połączenia.

  • Nawiązywanie połączenia z wystąpieniem programu SQL Server skonfigurowanym z więcej niż 64 adresami IP spowoduje niepowodzenie połączenia.

  • Zachowanie aplikacji korzystającej z MultiSubnetFailover właściwości połączenia nie ma wpływu na typ uwierzytelniania: uwierzytelnianie programu SQL Server, uwierzytelnianie Kerberos lub uwierzytelnianie systemu Windows.

  • Zwiększ wartość , Connect Timeout aby uwzględnić czas pracy w trybie failover i zmniejszyć liczbę ponownych prób nawiązania połączenia z aplikacją.

  • Transakcje rozproszone nie są obsługiwane.

Jeśli routing tylko do odczytu nie działa, nawiązanie połączenia z lokalizacją repliki pomocniczej zakończy się niepowodzeniem w następujących sytuacjach:

  • Jeśli lokalizacja repliki pomocniczej nie jest skonfigurowana do akceptowania połączeń.

  • Jeśli aplikacja używa ApplicationIntent=ReadWrite (omówionej poniżej), a lokalizacja repliki pomocniczej jest skonfigurowana do uzyskiwania dostępu tylko do odczytu.

SqlDependency nie jest obsługiwany w replikach pomocniczych tylko do odczytu.

Połączenie zakończy się niepowodzeniem, jeśli replika podstawowa jest skonfigurowana do odrzucania obciążeń tylko do odczytu, a parametry połączenia zawiera ApplicationIntent=ReadOnlywartość .

Uaktualnianie do korzystania z klastrów z wieloma podsieciami z dublowania bazy danych

Błąd połączenia (ArgumentException) wystąpi, jeśli MultiSubnetFailover słowa kluczowe i Failover Partner połączenia znajdują się w parametry połączenia lub jeśli MultiSubnetFailover=True jest używany protokół inny niż TCP. Błąd (SqlException) wystąpi również, jeśli MultiSubnetFailover jest używany, a program SQL Server zwraca odpowiedź partnera trybu failover wskazującą, że jest częścią pary dublowania bazy danych.

Jeśli uaktualnisz aplikację SqlClient, która obecnie używa funkcji dublowania bazy danych do scenariusza z wieloma podsieciami, usuń Failover Partner właściwość połączenia i zastąp ją MultiSubnetFailover ustawioną wartością True i zastąp nazwę serwera w parametry połączenia odbiornikiem grupy dostępności. Jeśli parametry połączenia używa Failover Partner wartości i MultiSubnetFailover=True, sterownik wygeneruje błąd. Jeśli jednak parametry połączenia używa Failover Partner i MultiSubnetFailover=False (lub ApplicationIntent=ReadWrite), aplikacja będzie używać dublowania bazy danych.

Sterownik zwróci błąd, jeśli dublowanie bazy danych jest używane w podstawowej bazie danych w grupie dostępności i jeśli MultiSubnetFailover=True jest używane w parametry połączenia, która łączy się z podstawową bazą danych zamiast z odbiornikiem grupy dostępności.

Określanie intencji aplikacji

Gdy ApplicationIntent=ReadOnlyklient żąda obciążenia odczytu podczas nawiązywania połączenia z bazą danych z włączoną funkcją AlwaysOn. Serwer będzie wymuszać intencję w czasie połączenia i podczas instrukcji USE bazy danych, ale tylko do zawsze włączonej bazy danych.

Słowo ApplicationIntent kluczowe nie działa ze starszymi bazami danych tylko do odczytu.

Baza danych może zezwalać na obciążenia odczytu w docelowej bazie danych AlwaysOn lub nie zezwalać na nie. (Odbywa się to za pomocą ALLOW_CONNECTIONS klauzuli instrukcji PRIMARY_ROLE i SECONDARY_ROLEJęzyka Transact-SQL).

Słowo ApplicationIntent kluczowe służy do włączania routingu tylko do odczytu.

Routing tylko do odczytu

Routing tylko do odczytu to funkcja, która może zapewnić dostępność repliki tylko do odczytu bazy danych. Aby włączyć routing tylko do odczytu:

  • Należy nawiązać połączenie z odbiornikiem zawsze włączonej grupy dostępności.
  • Słowo ApplicationIntent kluczowe parametry połączenia musi być ustawione na ReadOnly.
  • Aby umożliwić routing tylko do odczytu, należy skonfigurować grupę dostępności przez administratora bazy danych.

Istnieje możliwość, że wiele połączeń korzystających z routingu tylko do odczytu nie będzie łączyć się z tą samą repliką tylko do odczytu. Zmiany synchronizacji bazy danych lub zmiany konfiguracji routingu serwera mogą spowodować połączenia klientów z różnymi replikami tylko do odczytu. Aby upewnić się, że wszystkie żądania tylko do odczytu łączą się z tą samą repliką tylko do odczytu, nie przekazuj odbiornika grupy dostępności do słowa kluczowego Data Source parametry połączenia. Zamiast tego określ nazwę wystąpienia tylko do odczytu.

Routing tylko do odczytu może trwać dłużej niż nawiązywanie połączenia z podstawowym, ponieważ routing tylko do odczytu najpierw łączy się z podstawowym, a następnie szuka najlepszej dostępnej pomocniczej możliwości odczytu. W związku z tym należy zwiększyć limit czasu logowania.

Zobacz też