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

  • Článek

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 naslouchací proces skupiny dostupnosti nebo název FCI ve vlastnosti připojení. Pokud je aplikace SqlClient připojená k databázi, která převezme služby při selhání, původní připojení se přeruší a aplikace musí otevřít nové připojení, aby pokračovala v práci po převzetí služeb při selhání.

Pokud se nepřipojujete ke skupině dostupnosti nebo FCI a pokud je k názvu hostitele přidruženo více IP adres, SqlClient bude iterovat postupně přes všechny IP adresy přidružené k položce 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í FCI nebo k naslouchacímu procesu skupiny dostupnosti se SqlClient pokusí navázat připojení ke všem IP adresám paralelně. 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. Vzhledem k tomu, že připojení může selhat kvůli převzetí služeb při selhání, měli byste implementovat logiku opakování připojení a opakovat neúspěšné 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í kódu programu můžete upravit tato připojovací řetězec klíčová slova:

Poznámka:

true Nastavení MultiSubnetFailover na nepožadování u rozhraní .NET Framework verze 4.6.1 a novější. 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 naslouchacímu procesu skupiny dostupnosti. 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 převzetí služeb při selhání s více podsítě se klient pokusí připojit paralelně. Během převzetí služeb při selhání podsítě klient agresivně 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 převzetí služeb při selhání skupiny dostupnosti nebo FCI a je použitelné pro skupiny AG s jednou i více podsítěmi a FCI.

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

Zadání MultiSubnetFailover=True při připojování k něčemu jinému než skupině dostupnosti nebo FCI může 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í proces skupiny dostupnosti jako server v připojovací řetězec.

  • 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 doby převzetí služeb při selhání a zkraťte pokusy o opakování 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.

Upgrade na použití clusterů s více podsítěmi z zrcadlení databáze

K chybě připojení (ArgumentException) dojde v případě, že MultiSubnetFailover se v připojovací řetězec nacházejí klíčová slova a Failover Partner klíčová slova připojení, nebo pokud MultiSubnetFailover=True se použije jiný protokol než TCP. Pokud se použije chyba (SqlException) 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 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 Failover Partner byste odebrat vlastnost připojení a nahradit ji nastaveným MultiSubnetFailover True názvem serveru v připojovací řetězec 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 ve skupině dostupnosti a pokud MultiSubnetFailover=True se používá v připojovací řetězec, která se připojuje k primární databázi místo k naslouchacímu procesu 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 příkazů Transact-SQL SECONDARY_ROLE.)

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

Směrování jen pro čtení

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

  • Musíte se připojit k naslouchacímu procesu skupiny dostupnosti AlwaysOn.
  • Klíčové ApplicationIntent slovo připojovací řetězec musí být nastaveno na ReadOnlyhodnotu .
  • Skupinu dostupnosti musí nakonfigurovat správce databáze, aby povolil směrování jen pro čtení.

Je možné, že se více připojení pomocí směrování jen pro čtení nebude připojovat 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 Data Source slova připojovací řetězec naslouchací proces skupiny dostupnosti. Místo toho zadejte název instance jen pro čtení.

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

Viz také