Sterownik OLE DB dla obsługi programu SQL Server w celu zapewnienia wysokiej dostępności, odzyskiwania po awarii

Dotyczy do:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsSystem Platform Analitycznych (PDW)Baza danych SQL w Microsoft Fabric

pobierz sterownik OLE DB

W tym artykule omawiamy sterownik OLE DB dla wsparcia SQL Server dla grup dostępności Always On. Więcej informacji o grupach dostępności Always On można znaleźć w Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server),Creation and Configuration of Availability Groups (SQL Server),Failover Clustering and Always On Availability Groups (SQL Server) oraz Active Secondaries: Readable Secondary Replicas (Always On Availability Groups).

Możesz określić nasłuchiwacz grupy dostępności danej grupy dostępności w ciągu ciągu połączeń. Jeśli sterownik OLE DB dla aplikacji SQL Server jest połączony z bazą danych w grupie availability i przełącza się awaryjne, oryginalne połączenie zostaje przerwane i aplikacja musi otworzyć nowe połączenie, aby kontynuować pracę po awaryjnym przełączeniu.

Jeśli nie łączysz się z nasłuchiwaczem grupy dostępności, a wiele adresów IP jest powiązanych z nazwą hosta, sterownik OLE DB dla SQL Server będzie iterował kolejno przez wszystkie adresy IP powiązane 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ą sieciową (NIC). Podczas łączenia z nasłuchiwaczem grupy dostępności, sterownik OLE DB dla SQL Server próbuje nawiązać połączenia ze wszystkimi adresami IP równolegle i jeśli próba połączenia się powiedzie, sterownik odrzuca wszelkie oczekujące próby połączenia.

Uwaga / Notatka

Zwiększenie limitu połączenia i wdrożenie logiki powtórek połączenia zwiększy prawdopodobieństwo, że aplikacja połączy się z grupą dostępności. Ponadto, ponieważ połączenie może się zerwać z powodu awaryjnego przełączania grupy dostępności, powinieneś wdrożyć logikę ponownego połączenia, czyli ponowne próby nieudanego połączenia, aż się ponownie połączy.

Łączenie z MultiSubnetFailover

Zawsze określ MultiSubnetFailover=Tak, gdy celem jest Azure SQL Database, Azure SQL Managed Instance, baza danych SQL w Microsoft Fabric, słuchacz grupy Always On availability lub instancja klastra awaryjnego SQL Server.

Gdy nazwa serwera w twoim parametry połączenia rozwiązuje się na więcej niż jeden adres IP, MultiSubnetFailover=Yes mówi OLE DB Driver for SQL Server, aby otworzył połączenia na wszystkich tych adresach jednocześnie i użył pierwszego, który odpowie. Bez niego sterownik próbuje adresy pojedynczo. Adres, który nie odpowiada, zatrzymuje się, dopóki nie wygaśnie limit połączenia TCP systemu operacyjnego, co może wyczerpać czas połączenia zanim sterownik dotrze do adresu, który odbierze. Po awaryjnym przejściu adres, który sterownik próbuje jako pierwszy, może być tym, który nie obsługuje już bazy danych, więc połączenie, które mogłoby się powiodło z innym adresem, kończy się awarią z czasem.

MultiSubnetFailover=Yes zmienia szybkość klienta znajdującą replikę obsługującą bazę danych. Nie zmienia to czasu potrzebnego na przełączenie się serwera.

MultiSubnetFailover=Yes jest bezpieczne dla celów z jednym IP. Gdy DNS rozwiązuje się na jednym adresie, sterownik podejmuje jedną próbę połączenia, więc ustawienie nie kosztuje nic, gdy nie jest potrzebne.

Więcej informacji o słowach kluczowych w ciągu połączeń można znaleźć w artykule Using Connection String Keywords with OLE DB Driver for SQL Server.

Korzystaj z poniższych wskazówek, aby połączyć się z serwerem w grupie dostępności lub instancji klastra awaryjnego:

  • Ustaw właściwość połączenia MultiSubnetFailover na Tak.

  • Aby połączyć się z grupą dostępności, określ nasłuchiwacz grupy dostępności grupy dostępności jako serwer w ciągu połączeń.

  • Nie możesz używać MultiSubnetFailover przez inny protokół niż TCP.

  • Połączenie z instancją SQL Server skonfigurowaną z więcej niż 64 adresami IP powoduje awarię połączenia.

  • Nie możesz używać MultiSubnetFailover z mirroringiem bazy danych. Sterownik zwraca błąd, gdy serwer zgłasza, że baza danych jest lustrzana. Dublowanie baz danych zostało wycofane we wszystkich obsługiwanych wersjach programu SQL Server. Zamiast tego użyj grup dostępności Always On.

  • Rodzaj uwierzytelniania, czyli SQL Server Authentication, Kerberos Authentication czy Windows Authentication, nie wpływa na zachowanie aplikacji korzystającej z właściwości MultiSubnetFailover Connection.

  • Możesz zwiększyć wartość Connect Timeout , aby dostosować czas awarii i zmniejszyć próby ponownego połączenia aplikacji. Wartość domyślna to 15 sekund. To samo ustawienie nazywa się Timeout , gdy ustawiasz je przez IDBInitialize::Initialize, i mapuje się na tę DBPROP_INIT_TIMEOUT właściwość. Dla serwerless Azure SQL Database z włączoną automatyczną pauzą użyj czasu Connect Timeout 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 znajdziesz w sekcji Automatyczne wstrzymywanie i automatyczne wznawianie.

  • 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:

  1. Jeśli lokalizacja repliki pomocniczej nie jest skonfigurowana do akceptowania połączeń.
  2. Jeśli aplikacja używa ApplicationIntent=ReadWrite i lokalizacja drugiej repliki jest skonfigurowana do dostępu tylko do odczytu.

Połączenie nie ulega, jeśli replika podstawowa jest skonfigurowana tak, aby odrzucać obciążenia tylko do odczytu, a string zawiera ApplicationIntent=ReadOnly.

Aktualizacja z mirroringu bazy danych

Błąd połączenia występuje, jeśli parametry połączenia zawiera zarówno słowa kluczowe MultiSubnetFailover, jak i Failover_Partner. Błąd występuje także wtedy, gdy używasz MultiSubnetFailover, a SQL Server zwraca odpowiedź partnera failover, wskazującą, że jest częścią pary mirroring database.

Jeśli zaktualizujesz aplikację OLE DB Driver for SQL Server, która obecnie korzysta z mirroringu baz danych, do scenariusza multi-subnet, usuń właściwość połączenia Failover_Partner i zastąp ją MultiSubnetFailover ustawioną na Tak. Zastąp nazwę serwera w parametry połączenia na nasłuchiwacz grupy dostępności. Jeśli parametry połączenia używa Failover_Partner i MultiSubnetFailover=Tak, sterownik generuje błąd. Jednak jeśli parametry połączenia używa Failover_Partner i MultiSubnetFailover=No (lub ApplicationIntent=ReadWrite), aplikacja korzysta z mirroringu bazy danych.

Sterownik zwraca błąd, jeśli używasz mirroringu bazy danych na repliki głównej w grupie dostępności, a jeśli używasz MultiSubnetFailover=Yes w parametry połączenia, który łączy się z repliką główną zamiast ze słuchaczem grupy dostępności.

Programowo ustaw MultiSubnetFailover

Równoważne właściwości połączeń to:

  • SSPROP_INIT_MULTISUBNETFAILOVER
  • DBPROP_INIT_PROVIDERSTRING

Aplikacja OLE DB Driver for SQL Server może użyć jednej z następujących metod ustawienia opcji MultiSubnetFailover:

  • IDBInitialize::Initialize
    Wykorzystuje wcześniej skonfigurowany zestaw właściwości do inicjalizacji źródła danych i utworzenia obiektu źródła danych. Określ MultiSubnetFailover jako właściwość dostawcy lub jako część rozszerzonego ciągu właściwości.
  • IDataInitialize::GetDataSource
    Przyjmuje wejściowy parametry połączenia, który może zawierać słowo kluczowe MultiSubnetFailover.
  • IDBProperties::SetProperties
    Aby ustawić wartość właściwości MultiSubnetFailover, wywołaj IDBProperties::SetProperties , przekazując własność SSPROP_INIT_MULTISUBNETFAILOVER o wartości VARIANT_TRUE lub VARIANT_FALSE, albo własność DBPROP_INIT_PROVIDERSTRING z wartością zawierającą MultiSubnetFailover=Yes lub MultiSubnetFailover=No.

Example

DBPROP rgPropMultisubnet;

rgPropMultisubnet.dwPropertyID = SSPROP_INIT_MULTISUBNETFAILOVER;
rgPropMultisubnet.dwOptions = DBPROPOPTIONS_REQUIRED;
rgPropMultisubnet.dwStatus = DBPROPSTATUS_OK;
rgPropMultisubnet.colid = DB_NULLID;
V_VT(&(rgPropMultisubnet.vValue)) = VT_BOOL;
V_BOOL(&(rgPropMultisubnet.vValue)) = VARIANT_TRUE;

DBPROPSET PropSet;

PropSet.rgProperties = &rgPropMultisubnet;
PropSet.cProperties = 1;
PropSet.guidPropertySet = DBPROPSET_SQLSERVERDBINIT;
IDBProperties* pIDBProperties = NULL;
hr = pIDBInitialize->QueryInterface(IID_IDBProperties, (void **)&pIDBProperties);
pIDBProperties->SetProperties(1, &PropSet);

Określ intencję aplikacji

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

Gdy ustawiasz ApplicationIntent=ReadOnly, klient żąda obciążenia odczytu podczas łączenia. Serwer wymusza intencję podczas połączenia oraz podczas instrukcji bazy USE danych.

To ApplicationIntent słowo kluczowe nie działa w starszych bazach danych tylko do odczytu.

Cele ReadOnly

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

Jeśli żaden z tych specjalnych celów nie jest dostępny, odczytywana jest zwykła baza danych.

Słowo ApplicationIntent kluczowe umożliwia routing tylko do odczytu.

Routing tylko do odczytu

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

  • Musisz połączyć się z grupą Always On.

  • Słowo ApplicationIntent kluczowe ciągu łączącego 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 w synchronizacji bazy danych lub w konfiguracji routingu serwera mogą skutkować połączeniami klientów z różnymi replikami tylko do odczytu.

Możesz zapewnić, że wszystkie żądania tylko do odczytu łączą się z tą samą repliką tylko do odczytu, nie przekazując nasłuchiwacza grupy dostępności do Server słowa kluczowego ciągu połączeń. Zamiast tego określ nazwę instancji 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 głównym plikiem i następnie szuka najlepszego dostępnego czytelnego wtórnego. Ze względu na te liczne kroki powinieneś wydłużyć login czas przejścia do co najmniej 30 sekund.

Zamiar Aplikacji

Sterownik OLE DB Driver for SQL Server obsługuje słowo kluczowe ApplicationIntent parametry połączenia. Więcej informacji o słowach kluczowych w ciągu połączeń można znaleźć w artykule Using Connection String Keywords with OLE DB Driver for SQL Server.

Ustaw ApplicationIntent programatycznie

Równoważne właściwości połączeń to:

  • SSPROP_INIT_APPLICATIONINTENT
  • DBPROP_INIT_PROVIDERSTRING

Aplikacja OLE DB Driver for SQL Server może użyć jednej z następujących metod określenia intencji aplikacji:

  • IDBInitialize::Initialize
    Wykorzystuje wcześniej skonfigurowany zestaw właściwości do inicjalizacji źródła danych i utworzenia obiektu źródła danych. Określ intencję aplikacji jako właściwość dostawcy lub jako część rozszerzonego ciągu właściwości.
  • IDataInitialize::GetDataSource
    Przyjmuje wejściowy parametry połączenia, który może zawierać słowo kluczowe Application Intent.
  • IDBProperties::SetProperties
    Aby ustawić wartość właściwości ApplicationIntent , wywołaj IDBProperties::SetProperties , przekazując własność SSPROP_INIT_APPLICATIONINTENT z wartością ReadWrite lub ReadOnly, albo DBPROP_INIT_PROVIDERSTRING z wartością zawierającą ApplicationIntent=ReadOnly lub ApplicationIntent=ReadWrite.

Możesz określić intencję aplikacji w polu Właściwości intencji aplikacji w zakładce Wszystko w oknie dialogowym Data Link Properties .

Gdy ustanawiasz połączenia niejawne, połączenie to wykorzystuje ustawienie intencji aplikacji połączenia nadrzędnego. Podobnie, wiele sesji utworzonych z tego samego źródła dziedziczy ustawienia intencji aplikacji źródła.