Wysoka dostępność i odzyskiwanie po awarii

pobierz sterownika ODBC

Sterownik Microsoft ODBC dla SQL Server obsługuje grupy dostępności Always On. Aby uzyskać więcej informacji na temat grup dostępności Always On, zobacz:

Można określić nasłuchiwacz grupy dostępności dla określonej grupy dostępności w parametrze połączenia. Jeśli aplikacja ODBC połączy się z bazą danych w grupie dostępności, która ulegnie przełączeniu awaryjnemu, pierwotne połączenie zostaje przerwane. Aplikacja musi otworzyć nowe połączenie, aby kontynuować pracę po przejściu w tryb failover.

Bez MultiSubnetFailover=Yes, starszy mechanizm zapasowy wielu adresów IP sterownika może działać wolno, gdy pierwszy ustalony adres IP jest nieosiągalny. Aby uzyskać więcej informacji na temat mechanizmu awaryjnego systemu Windows, zobacz Używanie przezroczystego rozpoznawania adresów IP sieci przy użyciu sterownika ODBC.

Gdy nawiązujesz połączenie z nasłuchiwaczem grupy dostępności przy użyciu MultiSubnetFailover=Yes, sterownik próbuje równolegle nawiązać połączenie ze wszystkimi rozpoznanymi adresami IP. Jeśli próba połączenia zakończy się pomyślnie, sterownik odrzuci wszelkie oczekujące próby nawiązania połączenia.

Note

Ponieważ połączenie może zakończyć się niepowodzeniem w wyniku przełączenia awaryjnego grupy dostępności, zaleca się zaimplementować logikę ponawiania prób. Ponów próbę nawiązania połączenia zakończonego niepowodzeniem, dopóki nie zostanie ponownie nawiązane połączenie. Zwiększenie limitu czasu połączenia i zaimplementowanie logiki ponawiania połączenia zwiększa prawdopodobieństwo nawiązania połączenia z grupą dostępności.

Nawiąż połączenie z MultiSubnetFailover

Ustaw MultiSubnetFailover=Yes moment, gdy celem jest Azure SQL Database, Azure SQL Managed Instance, baza danych SQL w Microsoft Fabric, nasłuchiwacz grup dostępności lub instancja klastra awaryjnego. MultiSubnetFailover umożliwia szybsze odzyskiwanie po przełączeniu awaryjnym, ponieważ sterownik próbuje równolegle nawiązać połączenia TCP ze wszystkimi ustalonymi adresami IP i wykorzystuje pierwsze połączenie, które zakończy się powodzeniem.

Ta właściwość połączenia znacząco zmniejsza również czas przełączania w trybie failover dla topologii Always On z jedną lub wieloma podsieciami. Podczas trybu failover z wieloma podsieciami klient próbuje równolegle nawiązać połączenia. Podczas failoveru podsieci, sterownik agresywnie ponawia próby nawiązania połączenia TCP.

Właściwość połączenia MultiSubnetFailover wskazuje, że aplikacja jest wdrażana w topologii, w której docelowa nazwa hosta może być rozpoznawana jako więcej niż jeden punkt końcowy. Sterownik pró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 łączysz się za pomocą MultiSubnetFailover=Yes, klient podejmuje próby połączenia TCP szybciej niż domyślne interwały retransmisji TCP systemu operacyjnego. MultiSubnetFailover=Yes umożliwia szybsze ponowne nawiązywanie połączenia po awarii dla grupy dostępności Always On lub wystąpienia klastra Always On. MultiSubnetFailover=Yes dotyczy zarówno grup dostępności z jedną podsiecią, jak i wieloma podsieciami oraz wystąpień klastra przełączania awaryjnego.

MultiSubnetFailover=Yes jest bezpieczny w przypadku celów z pojedynczym adresem IP. Gdy DNS wskazuje jeden adres, MultiSubnetFailover=Yes nie tworzy dodatkowych równoległych prób połączenia.

Recommendations

Gdy łączysz się z wysoko dostępnym lub wielopunktowym celem (Azure SQL Database, Azure SQL Managed Instance, baza SQL w Microsoft Fabric, słuchacz grupy dostępności lub instancja klastra awaryjnego):

  • Podaj wartość MultiSubnetFailover=Yes. Jest to zalecane ustawienie dla tych elementów docelowych i można je bezpiecznie pozostawić włączone, gdy element docelowy jest rozpoznawany jako pojedynczy adres IP, ponieważ sterownik wykonuje wtedy jedną próbę połączenia.

  • Określ odbiornik grupy dostępności grupy dostępności jako serwer w parametrach połączenia.

  • Nie możesz używać MultiSubnetFailover=Yes ponad protokołem innym niż TCP.

  • Nie można nawiązać połączenia z instancją SQL Server skonfigurowaną z ponad 64 adresami IP.

  • Nie można używać elementu MultiSubnetFailover=Yes z dublowaniem bazy danych. Sterownik zwraca błąd, gdy w parametrach połączenia określono Failover_Partner, a także gdy serwer zgłasza, że baza danych jest dublowana. Dublowanie baz danych zostało wycofane we wszystkich obsługiwanych wersjach programu SQL Server. Zamiast tego użyj grup dostępności Always On.

  • Używaj zarówno uwierzytelniania SQL Server, jak i uwierzytelniania MultiSubnetFailover=Yes Kerberos, bez wpływu na zachowanie aplikacji.

  • Zwiększ czas logowania, aby dostosować czas awarii i zmniejszyć liczbę prób ponownego połączenia aplikacji. Sterownik nie ma parametru ciągu połączenia dla tego ustawienia. Ustaw go przed połączeniem, wywołując SQLSetConnectAttr z atrybutem SQL_ATTR_LOGIN_TIMEOUT .

    W przypadku Azure SQL Database serverless z włączonym automatycznym wstrzymywaniem użyj wartości co najmniej 60 sekund. Automatycznie wstrzymana baza danych wznawia się przy pierwszej próbie połączenia, a ta próba może zakończyć się błędem 40613, podczas gdy baza się wznawia, więc aplikacja musi spróbować ponownie. Więcej informacji można znaleźć w artykule Automatyczne wstrzymywanie i automatyczne wznawianie w bezserwerowej warstwie obliczeniowej usługi Azure SQL Database.

  • Transakcje rozproszone nie są obsługiwane.

Jeśli routing tylko do odczytu nie działa, nawiązywanie połączenia z dodatkową lokalizacją repliki w grupie dostępności koń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 i lokalizacja repliki pomocniczej jest skonfigurowana do dostępu tylko do odczytu.

Połączenie nie powiedzie się, jeśli replika podstawowa jest skonfigurowana do odrzucania obciążeń odczytu, a parametry połączenia zawierają ApplicationIntent=ReadOnly.

Określ intencję aplikacji

Możesz określić słowo kluczowe ApplicationIntent w parametrach połączenia. Przypisywalne wartości to ReadWrite (domyślne) lub ReadOnly.

Po ustawieniu ApplicationIntent=ReadOnly klient żąda obciążenia odczytowego podczas nawiązywania połączenia. Serwer wymusza ten zamiar w momencie nawiązania połączenia oraz podczas instrukcji USE bazy danych.

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

Obiekty docelowe tylko do odczytu

Gdy połączenie wybierze ReadOnly, połączenie jest przypisywane do jednej z następujących specjalnych konfiguracji, które mogą istnieć dla bazy danych:

  • Zawsze włączony. Baza danych może zezwalać lub nie zezwalać na obciążenia odczytu w docelowej bazie danych grupy dostępności. Wybór ten jest określany za pomocą klauzuli ALLOW_CONNECTIONS instrukcji Transact-SQL PRIMARY_ROLE i SECONDARY_ROLE.

  • Geo-replication

  • Skalowanie poziome odczytu

Jeśli żaden z tych specjalnych celów nie jest dostępny, odczyt następuje ze standardowej bazy danych.

Słowo kluczowe ApplicationIntent umożliwia trasowanie w trybie tylko do odczytu.

Rutowanie tylko odczytu

Routing tylko do odczytu to funkcja, która może zapewnić dostępność repliki tylko do odczytu bazy danych. Aby umożliwić routing tylko do odczytu, obowiązują wszystkie następujące zasady:

  • Musisz połączyć się z detektorem grupy dostępności Always On.

  • Słowo kluczowe ciągu połączeniowego ApplicationIntent musi być ustawione na ReadOnly.

  • Administrator bazy danych musi skonfigurować grupę dostępności, aby umożliwić routowanie tylko do odczytu.

Wiele połączeń, z których każde korzysta z routingu tylko do odczytu, może nie wszystkie łą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.

Możesz zapewnić, że wszystkie żądania tylko do odczytu będą kierowane do tej samej repliki tylko do odczytu, nie przekazując detektora grupy dostępności do słowa kluczowego Server w parametrach połączenia. Zamiast tego określ nazwę wystąpienia tylko do odczytu.

Routing tylko do odczytu może zająć więcej czasu niż połączenie z głównym serwerem. Wynika to z faktu, że routing tylko do odczytu najpierw łączy się z serwerem podstawowym, a następnie wyszukuje najlepszy dostępny serwer pomocniczy dostępny do odczytu. Ze względu na te liczne etapy powinieneś wydłużyć limit czasu login do co najmniej 30 sekund.

Składnia ODBC

Dwa słowa kluczowe parametrów połączenia ODBC obsługują grupy dostępności Always On.

  • ApplicationIntent

  • MultiSubnetFailover

Aby uzyskać więcej informacji o parametrach połączenia ODBC, zobacz Using Connection String Keywords with SQL Server Native Client.

Równoważne atrybuty połączenia to:

  • SQL_COPT_SS_APPLICATION_INTENT

  • SQL_COPT_SS_MULTISUBNET_FAILOVER

Aby uzyskać więcej informacji na temat atrybutów połączenia ODBC, zobacz SQLSetConnectAttr.

Aplikacja ODBC korzystająca z zawsze włączonych grup dostępności może używać jednej z dwóch funkcji, aby nawiązać połączenie:

Function Description
Funkcja SQLConnect SQLConnect obsługuje zarówno ApplicationIntent, jak i MultiSubnetFailover za pomocą nazwy źródła danych (DSN) lub atrybutu połączenia.
funkcja SQLDriverConnect SQLDriverConnect obsługuje ApplicationIntent i MultiSubnetFailover za pośrednictwem nazwy DSN, słowa kluczowego parametrów połączenia lub atrybutu połączenia.

Treści powiązane

  • Last updated on