Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Toto téma popisuje poskytovatele dat Microsoft SqlClient pro podporu SQL Serveru pro vysokou dostupnost, zotavení po havárii – skupiny dostupnosti AlwaysOn. Funkce Skupiny dostupnosti AlwaysOn byla přidána do SQL Serveru 2012. Další informace o skupinách dostupnosti AlwaysOn naleznete v tématu SQL Server Books Online.
Teď můžete zadat naslouchací proces skupiny dostupnosti (vysoká dostupnost, zotavení po havárii) nebo instanci clusteru s podporou převzetí služeb při selhání SQL Serveru 2012 ve vlastnosti připojení. Pokud je aplikace SqlClient připojená k databázi Always On, která selže při převzetí služeb, původní připojení se přeruší a aplikace musí otevřít nové připojení, aby mohla pokračovat v práci po převzetí služeb.
Pokud se nepřipojujete k posluchači skupiny dostupnosti nebo k instanci SQL Serveru 2012 pro převzetí služeb při selhání a pokud je k názvu hostitele přidruženo více IP adres, SqlClient bude postupně procházet všechny IP adresy přidružené k 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 naslouchacímu procesu skupiny dostupnosti nebo instanci clusteru s podporou převzetí služeb při selhání SQL Serveru 2012 se SqlClient pokusí navázat připojení ke všem IP adresám paralelně a pokud pokus o připojení proběhne úspěšně, ovladač zahodí všechny čekající 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řepnutí při selhání, měli byste implementovat logiku opětovného připojení a opakovat neúspěšné připojení, dokud se znovu nepřipojí.
Zprostředkovatel dat Microsoft SqlClient pro SQL Server podporuje následující vlastnosti připojení:
ApplicationIntentMultiSubnetFailover
Tato klíčová slova připojovacího řetězce můžete programově upravit takto:
Připojení pomocí MultiSubnetFailover
Vždy zadejte MultiSubnetFailover=True při připojování k naslouchajícímu procesu skupiny dostupnosti SQL Server 2012 nebo instanci clusteru pro převzetí služeb při selhání SQL Serveru 2012.
MultiSubnetFailover umožňuje rychlejší převzetí služeb při selhání pro všechny skupiny dostupnosti a instanci clusteru s podporou převzetí služeb při selhání v SQL Serveru 2012 a výrazně zkracuje dobu převzetí služeb při selhání u topologií AlwaysOn s jednou a více podsítěmi. Během převzetí služeb při selhání více podsítí se klient pokusí navázat paralelní připojení. Při selhání podsítě systém bude agresivně opakovat připojení TCP.
Vlastnost MultiSubnetFailover připojení označuje, že aplikace se nasazuje ve skupině dostupnosti nebo instanci clusteru s podporou převzetí služeb při selhání SQL Serveru 2012 a že se SqlClient 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 AlwaysOn nebo instance clusteru s podporou převzetí služeb při selhání AlwaysOn a platí pro skupiny dostupnosti s jednou i více podsítěmi a instance clusteru s podporou převzetí služeb při selhání.
Další informace o klíčových slovech připojovacího řetězce v SqlClient naleznete v tématu ConnectionString.
Určení MultiSubnetFailover=True při připojování k jinému než naslouchacímu procesu skupiny dostupnosti nebo instanci clusteru SQL Serveru 2012 Failover může mít negativní dopad na výkon a není podporováno.
Pomocí následujících pokynů se připojte k serveru ve skupině dostupnosti nebo instanci clusteru s podporou převzetí služeb při selhání SQL Serveru 2012:
MultiSubnetFailoverVlastnost 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í modul 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á
MultiSubnetFailovervlastnost 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 Timeouttak, aby se vyhovělo času pro převzetí služeb při selhání, a snižte počet pokusů 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 na sekundárních replikách v režimu pouze pro čtení.
Připojení selže, pokud je primární replika nakonfigurovaná tak, aby odmítla úlohy jen pro čtení a připojovací řetězec obsahuje ApplicationIntent=ReadOnly.
Upgrade ze zrcadlení databáze na použití clusterů s více podsítěmi
K chybě připojení (ArgumentException) dojde, pokud jsou v připojovacím řetězci přítomna klíčová slova MultiSubnetFailover a Failover Partner, nebo pokud MultiSubnetFailover=True se použije jiný protokol než TCP. Chyba (SqlException) nastane také, pokud je použit MultiSubnetFailover a SQL Server vrátí odpověď partnera pro převzetí služeb při selhání, který 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 byste odebrat vlastnost připojení Failover Partner a nahradit ji nastavením MultiSubnetFailover na True a název serveru v připojovacím řetězci nahradit posluchačem skupiny dostupnosti. Pokud připojovací řetězec používá Failover Partner a MultiSubnetFailover=Trueovladač vygeneruje chybu. Pokud ale připojovací řetězec použije Failover Partner a MultiSubnetFailover=False (nebo ApplicationIntent=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 rámci skupiny dostupnosti, 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í klauzule ALLOW_CONNECTIONS, která náleží k PRIMARY_ROLE a SECONDARY_ROLE příkazům Transact-SQL.)
Klíčové ApplicationIntent slovo se používá k povolení směrování jen pro čtení.
Směrování pouze 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 modulu skupiny dostupnosti Always On.
Klíčové slovo v připojovacím řetězci
ApplicationIntentmusí být nastaveno naReadOnly.Skupinu dostupnosti musí nakonfigurovat správce databáze, aby povolil směrování jen pro čtení.
Je možné, že více připojení, která používají směrování pouze pro čtení, se nepřipojí ke stejné replice 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í. Aby se všechny požadavky pro čtení připojily ke stejné replice určené jen pro čtení, neuvádějte naslouchací proces skupiny dostupnosti v klíčovém slově připojovacího řetězce Data Source. 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 se nejprve připojuje k primárnímu serveru a poté hledá nejlepší dostupnou čitelnou sekundární repliku. Z tohoto důvodu byste měli zvýšit časový limit přihlášení.