Megosztás a következőn keresztül:

SqlClient-támogatás magas rendelkezésre álláshoz és vészhelyreállításhoz

  • Cikk

Ez a cikk az SqlClient (.NET-keretrendszer 4.5-ben hozzáadott) támogatását ismerteti a magas rendelkezésre álláshoz és vészhelyreállításhoz az Always On funkciókkal: Always On rendelkezésre állási csoportokkal (AG-k) és Always On feladatátvevő fürtpéldányokkal (FCI-k) az SQL Server 2012 vagy újabb verziójával.

Most már megadhat egy rendelkezésre állási csoport figyelőt vagy egy FCI nevét a kapcsolati tulajdonságban. Ha egy SqlClient-alkalmazás olyan adatbázishoz csatlakozik, amely meghiúsul, az eredeti kapcsolat megszakadt, és az alkalmazásnak új kapcsolatot kell nyitnia a feladatátvétel utáni működés folytatásához.

Ha nem csatlakozik AG-hez vagy FCI-hez, és ha több IP-cím van társítva egy gazdagépnévvel, az SqlClient a DNS-bejegyzéshez társított összes IP-címen egymás után halad. Ez időigényes lehet, ha a DNS-kiszolgáló által visszaadott első IP-cím nincs hálózati adapterhez (NIC) kötve. FcI vagy egy rendelkezésre állási csoport figyelőjéhez való csatlakozáskor az SqlClient megpróbál kapcsolatot létesíteni az összes IP-címmel párhuzamosan. Ha egy kapcsolati kísérlet sikeres, az illesztőprogram elveti a függőben lévő csatlakozási kísérleteket.

Feljegyzés

A kapcsolat időtúllépésének növelése és a kapcsolat újrapróbálkozási logikájának megvalósítása növeli annak valószínűségét, hogy egy alkalmazás csatlakozni fog egy rendelkezésre állási csoporthoz. Mivel egy kapcsolat feladatátvétel miatt meghiúsulhat, a kapcsolat újrapróbálkozási logikáját kell implementálnia, és újrapróbálkoznia egy sikertelen kapcsolatot, amíg újra nem csatlakozik.

A következő kapcsolati tulajdonságok lettek hozzáadva az SqlClienthez a .NET-keretrendszer 4.5-ben:

  • ApplicationIntent
  • MultiSubnetFailover

Az alábbi kapcsolati sztring kulcsszavakat programozott módon módosíthatja a következőkkel:

Feljegyzés

true A beállítás MultiSubnetFailover nem szükséges .NET-keretrendszer 4.6.1-s és újabb verzióihoz. A .NET Core-ban és a .NET 5+-ban szükséges.

Csatlakozás a MultiSubnetFailoverrel

Mindig adja meg MultiSubnetFailover=True , hogy mikor csatlakozik az FCI-hez vagy egy AG figyelőjéhez. MultiSubnetFailover az SQL Server 2012 vagy újabb verzióiban gyorsabb feladatátvételt tesz lehetővé az összes AG és FCI számára, és jelentősen csökkenti az egy- és több alhálózatú Always On topológiák feladatátvételi idejét. Több alhálózatos feladatátvétel során az ügyfél párhuzamosan próbál kapcsolatokat létesíteni. Az alhálózati feladatátvétel során az ügyfél agresszíven újrapróbálkozza a TCP-kapcsolatot.

A MultiSubnetFailover kapcsolati tulajdonság azt jelzi, hogy az alkalmazás AG-t vagy FCI-t használ, és az SqlClient megpróbál csatlakozni az elsődleges SQL Server-példány adatbázisához az összes IP-címhez való kapcsolódással. Amikor MultiSubnetFailover=True meg van adva egy kapcsolat, az ügyfél gyorsabban próbálkozik újra a TCP-kapcsolattal, mint az operációs rendszer alapértelmezett TCP-újraküldési időközei. Ez lehetővé teszi a gyorsabb újracsatlakozást egy AG vagy FCI feladatátvétele után, és az egy- és több-alhálózati AG-kre és FCI-kre egyaránt alkalmazható.

További információ az SqlClient kapcsolati sztring kulcsszavakról: ConnectionString.

MultiSubnetFailover=True Ha nem AG-hez vagy FCI-hez csatlakozik, az negatív hatással lehet a teljesítményre, és nem támogatott.

A következő irányelvek segítségével csatlakozhat egy kiszolgálóhoz az Always On egyik funkciójának használatával:

  • MultiSubnetFailover A kapcsolati tulajdonságot egyetlen alhálózathoz vagy több alhálózathoz való csatlakozáskor használja; mindkettő esetében javítja a teljesítményt.

  • Ha csatlakozni szeretne egy AG-hez, adja meg a rendelkezésre állási csoport figyelőjének kiszolgálóként a kapcsolati sztring.

  • Ha egy 64-nél több IP-címmel konfigurált SQL Server-példányhoz csatlakozik, az csatlakozási hibát fog okozni.

  • A kapcsolati tulajdonságot használó MultiSubnetFailover alkalmazások viselkedésére nem vonatkozik a hitelesítés típusa: SQL Server-hitelesítés, Kerberos-hitelesítés vagy Windows-hitelesítés.

  • Növelje a feladatátvételi idő figyelembevételének Connect Timeout értékét, és csökkentse az alkalmazáskapcsolat újrapróbálkozási kísérleteit.

  • Az elosztott tranzakciók nem támogatottak.

Ha az írásvédett útválasztás nincs érvényben, a másodlagos replikához való csatlakozás a következő helyzetekben meghiúsul:

  • Ha a másodlagos replika helye nincs konfigurálva a kapcsolatok elfogadására.

  • Ha egy alkalmazás használ ApplicationIntent=ReadWrite (az alábbiakban tárgyalt), és a másodlagos replika helye írásvédett hozzáférésre van konfigurálva.

SqlDependency írásvédett másodlagos replikák esetén nem támogatott.

A kapcsolat meghiúsul, ha egy elsődleges replika úgy van konfigurálva, hogy elutasítsa az írásvédett számítási feladatokat, és a kapcsolati sztring tartalmazzaApplicationIntent=ReadOnly.

Frissítés több alhálózati fürtök használatára adatbázis-tükrözésből

Kapcsolati hiba (ArgumentException) akkor fordul elő, ha a MultiSubnetFailover kapcsolat kulcsszavai Failover Partner megtalálhatók a kapcsolati sztring, vagy ha MultiSubnetFailover=True nem TCP protokollt használnak. A használat során hiba (SqlException) is bekövetkezik MultiSubnetFailover , és az SQL Server egy feladatátvevő partner válaszát adja vissza, amely azt jelzi, hogy az adatbázis-tükrözési pár része.

Ha olyan SqlClient-alkalmazást frissít, amely jelenleg adatbázis-tükrözést használ egy több alhálózatos forgatókönyvre, távolítsa el a Failover Partner kapcsolati tulajdonságot, és cserélje le MultiSubnetFailover a kiszolgáló nevét a kapcsolati sztring egy rendelkezésre állási csoport figyelőjének beállítására True és helyére. Ha egy kapcsolati sztring használFailover Partner, és MultiSubnetFailover=Trueaz illesztőprogram hibát fog generálni. Ha azonban egy kapcsolati sztring használ Failover Partner és MultiSubnetFailover=False (vagyApplicationIntent=ReadWrite), az alkalmazás adatbázis-tükrözést fog használni.

Az illesztőprogram hibát ad vissza, ha az adatbázis-tükrözést az AG elsődleges adatbázisában használják, és ha MultiSubnetFailover=True a rendelkezésre állási csoport figyelője helyett egy elsődleges adatbázishoz csatlakozó kapcsolati sztring használja.

Alkalmazás szándékának megadása

Amikor ApplicationIntent=ReadOnlyaz ügyfél olvasási számítási feladatot kér egy AlwaysOn-kompatibilis adatbázishoz való csatlakozáskor. A kiszolgáló a szándékot a kapcsolati időben és a USE adatbázis-utasítás során érvényesíti, de csak egy Always On-kompatibilis adatbázisra.

A ApplicationIntent kulcsszó nem működik régi, írásvédett adatbázisokkal.

Az adatbázisok engedélyezhetik vagy letilthatják az olvasási számítási feladatokat a célzott AlwaysOn-adatbázisban. (Ez az és SECONDARY_ROLEa ALLOW_CONNECTIONS PRIMARY_ROLE Transact-SQL utasítás záradékával történik.)

A ApplicationIntent kulcsszó az írásvédett útválasztás engedélyezésére szolgál.

Írásvédett útválasztás

Az írásvédett útválasztás olyan szolgáltatás, amely biztosítja az adatbázisok írásvédett replikáinak rendelkezésre állását. Írásvédett útválasztás engedélyezése:

  • Mindig rendelkezésre állási csoport rendelkezésre állási csoport figyelőhöz kell csatlakoznia.
  • A ApplicationIntent kapcsolati sztring kulcsszónak a következőre kell állítaniaReadOnly: .
  • A rendelkezésre állási csoportot az adatbázis-rendszergazdának kell konfigurálnia az írásvédett útválasztás engedélyezéséhez.

Lehetséges, hogy több, írásvédett útválasztást használó kapcsolat nem fog mind ugyanahhoz az írásvédett replikához csatlakozni. Az adatbázis-szinkronizálás vagy a kiszolgáló útválasztási konfigurációjának módosítása ügyfélkapcsolatokat eredményezhet a különböző írásvédett replikákkal. Annak biztosítása érdekében, hogy minden írásvédett kérés ugyanahhoz az írásvédett replikához csatlakozzon, ne adjon át egy rendelkezésreállási csoport figyelőt a Data Source kapcsolati sztring kulcsszónak. Ehelyett adja meg a csak olvasható példány nevét.

A csak olvasható útválasztás hosszabb időt vehet igénybe, mint az elsődlegeshez való csatlakozás, mivel az írásvédett útválasztás először az elsődlegeshez csatlakozik, majd megkeresi a legjobban elérhető olvasható másodlagost. Emiatt növelnie kell a bejelentkezési időtúllépést.

Lásd még