Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy do:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Azure Synapse Analytics
System Platform Analitycznych (PDW)
Baza danych SQL w Microsoft Fabric
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_TIMEOUTwł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:
- Jeśli lokalizacja repliki pomocniczej nie jest skonfigurowana do akceptowania połączeń.
- 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:
Zawsze włączony. Baza danych może zezwalać lub zakazywać obciążeń odczytu w docelowej grupie danych dostępności. Wybór ten jest kontrolowany przez użycie klauzuli
ALLOW_CONNECTIONSzdań iPRIMARY_ROLESECONDARY_ROLETransact-SQL.
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
ApplicationIntentkluczowe ciągu łączącego musi być ustawione na .ReadOnlyAdministrator 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.