Podpora SqlClient pro vysokou dostupnost a zotavení po havárii

Tento článek popisuje podporu SqlClient (přidanou v rozhraní .NET Framework 4.5) pro zajištění vysoké dostupnosti a zotavení po havárii pomocí funkcí AlwaysOn: Skupiny dostupnosti AlwaysOn (AG) a instance clusteru s podporou převzetí služeb při selhání AlwaysOn (FCI) s SQL Serverem 2012 nebo novějším.

Teď můžete zadat posluchač skupiny dostupnosti nebo název FCI v nastavení připojení. Pokud je aplikace SqlClient připojená k databázi, u které dojde k převzetí při selhání, dojde k přerušení původního připojení a aplikace musí otevřít nové připojení, aby pokračovala v práci po převzetí při selhání.

Pokud se nepřipojujete ke skupině dostupnosti nebo FCI a pokud je k názvu hostitele přiřazeno více IP adres, SqlClient bude postupně procházet všechny IP adresy uvedené v záznamu DNS. To může být časově náročné, pokud první IP adresa vrácená serverem DNS není vázána na žádnou síťovou kartu (NIC). Při připojování k FCI, nebo k naslouchacímu skupiny dostupnosti, se SqlClient pokusí navázat připojení ke všem IP adresám současně. Pokud pokus o připojení proběhne úspěšně, ovladač zahodí všechny nevyřízené pokusy o připojení.

Poznámka:

Zvýšení časového limitu připojení a implementace logiky opakování připojení zvýší pravděpodobnost, že se aplikace připojí ke skupině dostupnosti. Také vzhledem k tomu, že připojení může selhat kvůli přepnutí při selhání, měli byste implementovat logiku opakovaných pokusů o připojení a opakovaně se pokoušet o navázání neúspěšného připojení, dokud se znovu nepřipojí.

Do SqlClient v rozhraní .NET Framework 4.5 byly přidány následující vlastnosti připojení:

  • ApplicationIntent
  • MultiSubnetFailover

Pomocí programově můžete upravit tato připojovací řetězce klíčová slova:

Poznámka:

MultiSubnetFailover Nastavení true není nutné u rozhraní .NET Framework verze 4.6.1 a novějších. Vyžaduje se v .NET Core a .NET 5+.

Připojení pomocí MultiSubnetFailover

Vždy zadejte MultiSubnetFailover=True při připojování k FCI nebo posluchači Dostupnostní skupiny. MultiSubnetFailover umožňuje rychlejší převzetí služeb při selhání pro všechny skupiny AG a FCI v SQL Serveru 2012 nebo novějším a výrazně zkracuje dobu převzetí služeb při selhání pro topologie AlwaysOn s jednou a více podsítěmi. Během selhání služby s více podsítěmi se klient pokusí připojit paralelně. Během převzetí služeb při selhání podsítě klient intenzivně opakuje připojení TCP.

Vlastnost MultiSubnetFailover připojení označuje, že aplikace používá ag nebo FCI a sqlClient se pokusí připojit k databázi v primární instanci SQL Serveru tím, že se pokusí připojit ke všem IP adresám. Pokud MultiSubnetFailover=True je pro připojení zadáno, klient opakuje pokusy o připojení TCP rychleji než výchozí intervaly přenosu TCP operačního systému. To umožňuje rychlejší opětovné připojení po selhání, ať už se jedná o skupinu dostupnosti (AG) nebo instanci s ažurací (FCI). Platí to pro skupiny AG i FCI s jednou nebo více podsítěmi.

Další informace o klíčových slovech řetězce připojení v SqlClient naleznete v tématu ConnectionString.

Při připojování k něčemu jinému než ke skupině dostupnosti nebo FCI může zadání MultiSubnetFailover=True vést k negativnímu dopadu na výkon a není podporováno.

Pomocí následujících pokynů se připojte k serveru pomocí některé z funkcí AlwaysOn:

  • MultiSubnetFailover Vlastnost připojení použijte při připojování k jedné podsíti nebo více podsítě. Tím se zlepší výkon obou podsítí.

  • Pokud se chcete připojit ke skupině dostupnosti, zadejte naslouchací procesor skupiny dostupnosti jako server v připojovacím řetězci.

  • Připojení k instanci SQL Serveru nakonfigurované s více než 64 IP adresami způsobí selhání připojení.

  • Chování aplikace, která používá MultiSubnetFailover vlastnost připojení, není ovlivněno na základě typu ověřování: ověřování SYSTÉMU SQL Server, ověřování kerberos nebo ověřování systému Windows.

  • Zvyšte hodnotu Connect Timeout k přizpůsobení času pro převzetí služeb při selhání a snižte počet pokusů o opětovné připojení k aplikaci.

  • Distribuované transakce nejsou podporovány.

Pokud není směrování jen pro čtení účinné, připojení k sekundárnímu umístění repliky selže v následujících situacích:

  • Pokud sekundární umístění repliky není nakonfigurované tak, aby přijímalo připojení.

  • Pokud aplikace používá ApplicationIntent=ReadWrite (popsáno níže) a sekundární umístění repliky je nakonfigurované pro přístup jen pro čtení.

SqlDependency není podporován v sekundárních replikách jen pro čtení.

Připojení selže, pokud je primární replika nakonfigurovaná tak, aby odmítala úlohy jen pro čtení a připojovací řetězec obsahuje ApplicationIntent=ReadOnly.

Aktualizace na použití klastrů s více podsítěmi ze zrcadlení databáze

K chybě připojení (ArgumentException) dojde, pokud jsou klíčová slova MultiSubnetFailover a Failover Partner přítomna v připojovacím řetězci, nebo pokud se použije MultiSubnetFailover=True a protokol jiný než TCP. Chyba (SqlException) nastane také, když se použije MultiSubnetFailover a SQL Server vrátí odpověď partnera pro převzetí služeb při selhání, což znamená, že je součástí páru pro zrcadlení databáze.

Pokud upgradujete aplikaci SqlClient, která aktuálně používá zrcadlení databáze na scénář s více podsítěmi, měli byste odebrat vlastnost připojení Failover Partner a nahradit ji vlastností MultiSubnetFailover nastavenou na True a také nahradit název serveru v připojovacím řetězci naslouchacím procesem skupiny dostupnosti. Pokud připojovací řetězec použije Failover Partner a MultiSubnetFailover=Trueovladač vygeneruje chybu. Pokud ale připojovací řetězec použije Failover Partner a MultiSubnetFailover=False (neboApplicationIntent=ReadWrite), aplikace bude používat zrcadlení databáze.

Ovladač vrátí chybu, pokud se zrcadlení databáze používá v primární databázi v AG a pokud se MultiSubnetFailover=True používá v připojovacím řetězci, který se připojuje k primární databázi místo k posluchači skupiny dostupnosti.

Určení záměru aplikace

Když ApplicationIntent=ReadOnlyklient požádá o úlohu čtení při připojování k databázi s podporou AlwaysOn. Server bude vynucovat záměr v době připojení a během příkazu databáze USE, ale pouze pro databázi s podporou AlwaysOn.

Klíčové ApplicationIntent slovo nefunguje se staršími databázemi jen pro čtení.

Databáze může povolit nebo zakázat čtení úloh v cílové databázi AlwaysOn. (To se provádí pomocí ALLOW_CONNECTIONS klauzule PRIMARY_ROLE a SECONDARY_ROLE příkazů Transact-SQL.)

Klíčové ApplicationIntent slovo se používá k povolení směrování jen pro čtení.

Směrování v režimu jen pro čtení

Směrování jen pro čtení je funkce, která zajišťuje dostupnost repliky databáze jen pro čtení. Jak povolit směrování pouze pro čtení:

  • Musíte se připojit k posluchači dostupnostní skupiny Always On Availability Group.
  • Klíčové slovo pro připojovací řetězec ApplicationIntent musí být nastaveno na ReadOnly hodnotu.
  • Skupinu dostupnosti musí nakonfigurovat správce databáze, aby povolil směrování jen pro čtení.

Je možné, že různá připojení pomocí směrování jen pro čtení se nemusí všechna připojit ke stejné replice jen pro čtení. Změny synchronizace databáze nebo změny v konfiguraci směrování serveru můžou vést k klientským připojením k různým replikám jen pro čtení. Pokud chcete zajistit, aby se všechny požadavky jen pro čtení připojily ke stejné replice jen pro čtení, nepředávejte do klíčového slova připojovacího řetězce Data Source posluchače skupiny dostupnosti. Místo toho zadejte název instance jen pro čtení.

Směrování pro režim pouze pro čtení může trvat déle než připojení k primárnímu serveru, protože nejprve se připojí k primárnímu serveru a poté hledá nejlepší dostupný sekundární server pro čtení. Z tohoto důvodu byste měli zvýšit časový limit přihlášení.

Viz také

  • Last updated on