Vysoká dostupnost a obnova po havárii se SqlClient

Stáhnout ADO.NET

Připojte se ke stabilnímu servisnímu endpointu místo konkrétní repliky, když vaše aplikace musí přežít failover serveru. Microsoft. Data.SqlClient dokáže urychlit pokusy o připojení a požádat o směrování pouze pro čtení, ale nezpůsobí, že by transakce během letu přežila přerušené spojení.

Nasazení na SQL server Koncový bod, který se má použít
Skupina pro dostupnost Always On (AG). AG listener, síťové jméno, které směruje spojení na příslušnou repliku.
Instance clusteru s podporou převzetí služeb při selhání (FCI). Název virtuálního serveru instance clusterovaného SQL Server.
Zrcadlení starších databází. Principal a Failover Partner se zadanou zrcadlenou databází.

Pro serverovou architekturu viz skupiny dostupnosti Always On.

Připojení pomocí MultiSubnetFailover

Nastavte MultiSubnetFailover=true pro podporované koncové body protokolu Transmission Control Protocol (TCP) v řadě Microsoft SQL, včetně naslouchacích procesů AG, instancí clusteru s podporou převzetí služeb při selhání (FCI), Azure SQL Database, Azure SQL Managed Instance a databáze SQL v Microsoft Fabric. Použijte název hostitele a port, nikoli zjišťování pojmenovaných instancí.

Server=tcp:<listener>,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;

Nahraďte autentizační nastavení pro vaše prostředí. Certifikát musí ověřit jméno používané klientem; viz Šifrování a ověřování certifikátů.

Když systém doménových jmen (DNS) vrátí několik IP adres, pokusí se o paralelní spojení a použije MultiSubnetFailover=true první úspěšné připojení. Tato funkce snižuje zpoždění, když některé adresy nejsou dostupné nebo již databázi neobsluhují. Také urychluje opakované pokusy TCP. Pro koncový bod s jednou IP adresou se zkouší pouze jedna adresa.

Toto nastavení nezkracuje dobu failoveru serveru ani obnovy databáze. Povolte vhodnou Connect Timeout a omezenou politiku opakovaných pokusů na úrovni aplikace s ohledem na požadavky vaší služby na dostupnost.

Kompatibilita možností připojení

Option Výchozí Chování a omezení
MultiSubnetFailover false, pokud není povoleno přepsání celého procesu. Paralelní pokusy o TCP. Není podporováno pro zjišťování pojmenovaných instancí, protokoly jiné než TCP, zrcadlení databáze ani více než 64 IP adres serveru.
TransparentNetworkIPResolution truena .NET Frameworku, podléhající automatickému zpracování koncových bodů a autentizace. Nejprve zkusí první adresu, než se paralelně pokusí o alternativní adresy. Pouze .NET Framework; zastaralý. Moderní .NET toto klíčové slovo odmítá. MultiSubnetFailover=true má přednost.
Failover Partner Empty. Pouze zrcadlení starších databází. Vyžaduje Initial Catalog nebo Database. Neslučitelné s MultiSubnetFailover=true a .ApplicationIntent=ReadOnly
ApplicationIntent ReadWrite. Odesílá serveru požadavek na zatížení. Směrování pouze pro čtení vyžaduje konfiguraci serveru a nevztahuje se na libovolné databáze pouze pro čtení.

Výchozí hodnota pro MultiSubnetFailover je v připojovacím řetězci stále false. Celostní procesový přepínač AppContext jej může povolit pro všechna připojení. Preferujte explicitní konfiguraci připojení, pokud aplikace také používá nekompatibilní cíle, jako je LocalDB nebo zrcadlení databáze. Viz přepínače AppContext.

Transparentní síťové IP rozlišení (TNIR) je zastaralé od SqlClient 7.1. Nekopírujte klíčové slovo TNIR do moderních .NET spojovacích řetězců. V rozhraní .NET Framework může explicitní konfigurace TNIR potlačit automatické zpracování ze strany ovladače pro některé koncové body a režimy ověřování. Nepředpokládejte, že každé spojení bez MultiSubnetFailover vždy zkouší adresy čistě sekvenčně.

Po selhání se znovu připojte

Failover může přerušit existující spojení. Zlikvidujte nefunkční spojení a otevřete nové u servisního endpointu. Funkce obnovy a opětovného pokusu o spojení mají své limity; automaticky nepřehrávají přerušenou obchodní operaci.

  1. Rozlište přechodnou chybu v konektivitě od neplatného přihlašovacího údaje, odepřeného oprávnění nebo selhání certifikátu.
  2. Opakovat pokusy o navázání spojení s omezenými prodlevami a celkovým časovým limitem.
  3. Zopakujte neúspěšnou operaci pouze tehdy, když zjistíte, zda byla provedena, nebo pokud je operace navržena jako idempotentní.
  4. Znovu vytvořte stav transakce a relace patřící ztracené relaci.

Ztracená odpověď po commitu může klienta nechat v nejistotě, zda zápis uspěl. Opakování tohoto zápisu bez ochrany proti duplicitě může způsobit jeho dvojí provedení. Viz Konfigurovatelná logika opakovaných pokusů a SQL Server connection pooling.

Přechod z databázového zrcadlení na clustery s více podsítěmi

Zrcadlení databází je zastaralá funkce. Failover Partnerpatří do zrcadlení databází; není to sekundární adresa AG ani nastavení pro failover skupinu v Azure.

Při migraci zrcadlené databáze do AG:

  1. Nakonfigurujte a ověřte listener AG a databázi na serveru.
  2. Nahraďte staré jméno serveru za "listener".
  3. Odeberte Failover Partner.
  4. Nastavte MultiSubnetFailover=true a zadejte databázi AG.
  5. Před nasazením změny procvičte chování při failoveru a opětovném pokusu.

SqlClient odmítá Failover Partner v kombinaci s .MultiSubnetFailover=true Pouhé nastavení MultiSubnetFailover=false nekonfiguruje zrcadlení; platný zrcadlený pár a databáze jsou stále vyžadovány. Zrcadlený partner poskytovaný serverem je také nekompatibilní s přehozením více podsítí.

Specifikovat záměr aplikace

Nastavte ApplicationIntent=ReadOnly, chcete-li v databázi AG vyžádat zatížení čtením:

Server=tcp:<listener>,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;ApplicationIntent=ReadOnly;

Primární a sekundární politiky připojení AG určují, zda je požadovaná pracovní zátěž přijata. Primární zařízení nakonfigurované k odmítání pouze čtetelných zátěží může toto spojení odmítnout. Sekundární zařízení nakonfigurované pro přístup pouze pro čtení odmítá spojení pro čtení a zápis.

ApplicationIntent nemění databázi na pouze pro čtení, nenahrazuje oprávnění ani nesměruje běžné databáze pouze pro čtení. Udělte oprávnění pouze pro čtení, pokud aplikace nemusí být schopna zapisovat.

Směrování pouze pro čtení

Pro směrování pouze pro čtení v AG nastavte všechna následující nastavení:

  • Připojte se k listeneru AG.
  • Nastavte Database na databázi v AG.
  • Nastavte ApplicationIntent=ReadOnly.
  • Nakonfigurujte sekundární repliku pro čtení a její směrovací adresu URL jen pro čtení.
  • Nakonfigurujte seznam směrování jen pro čtení primární repliky.

Klient nejprve kontaktuje primární uzel prostřednictvím listeneru a poté se připojí k přesměrovanému cíli. Povolit přístup do sítě a platné názvy certifikátů pro obě fáze připojení. Směrování může prodloužit dobu připojení.

Jednotlivá otevření mohou přistupovat k různým replikám pro čtení v závislosti na změnách konfigurace směrování a dostupnosti. Pooled open může znovu použít existující spojení místo dalšího směrování. Přímé připojení k sekundárnímu zařízení vybírá tuto instanci, ale obchází směrování založené na posluchači a jeho failover chování.

SqlDependency není podporován u sekundárních replik jen pro čtení. Zvlášť si prověřte požadavky na verzi a nasazení SQL Server pro funkce jako distribuované transakce; MultiSubnetFailover samotné o sobě neprokazují jejich podporu.

Azure SQL a Microsoft Fabric

Pro Azure SQL použijte konfigurovaný koncový bod služby, včetně jeho failover-group listeneru, pokud je to možné. Nepoužívejte Failover Partner pro Azure SQL failover skupinu. Převzetí službou při selhání se liší od toho, když si SQL Server AG nakonfigurujete sami.

Pro SQL databázi v Microsoft Fabric:

  • Použijte databázový připojovací řetězec s ověřováním Microsoft Entra a MultiSubnetFailover=true.
  • Pro analytické úlohy se zátěží jen pro čtení používejte samostatný koncový bod SQL analytics. Nepředpokládejte ApplicationIntent=ReadOnly , že přesměrovává zapisovatelný databázový endpoint.
  • Nekonfigurujte pro databázovou službu Failover Partner ani směrování AG serveru SQL Server.
  • Vezměte v úvahu aktuální Default zásady připojení: povolte odchozí přenosy TCP na portu 1433 pro brány a na portech 11000 až 11999 pro regionální adresy Azure SQL.

Fabric zajišťuje automatickou redundanci zón. Aktivní geografická replikace, skupiny převzetí služeb při selhání a geografické obnovení nejsou v současnosti pro databázi SQL ve Fabric podporovány. služba MS DTC (Microsoft Distributed Transaction Coordinator), klientská knihovna elastic database a elastic query také nejsou podporovány. Viz Připojit se k SQL databázi ve Fabric a omezení SQL databáze Fabric.