Připojte klienty k databázové zrcadlovací relaci (SQL Server)

platí pro:SQL Server

Pro připojení k databázové zrcadlovací relaci může klient použít buď SQL Server Native Client, nebo .NET Framework Zprostředkovatel dat for SQL Server. Při konfiguraci pro databázi SQL Server tito poskytovatelé přístupu k datům plně podporují zrcadlení databází. Informace o programovacích aspektech pro použití zrcadlené databáze naleznete v článku Používání zrcadlení databáze. Kromě toho musí být aktuální instance hlavního serveru dostupná a přihlašovací údaje klienta musí být vytvořeny přímo na serverové instanci. Pro více informací viz Řešení problémů s osiřelými uživateli (SQL Server). Klientská připojení k databázové zrcadlovací relaci nezahrnuje instanci svědeckého serveru, pokud existuje.

Navázání počátečního spojení s databázovou zrcadlovací relací

Pro počáteční spojení s zrcadlenou databází musí klient zadat připojovací řetězec, který minimálně poskytuje název serverové instance. Toto požadované jméno serveru by mělo identifikovat aktuální instanci hlavního serveru a je známo jako počáteční název partnera.

Volitelně může připojovací řetězec také poskytnout název jiné instance serveru, která by měla identifikovat aktuální instanci zrcadlového serveru, pro použití v případě, že počáteční partner není dostupný během prvního pokusu o připojení. Druhý název se označuje jako název failover partnera.

připojovací řetězec musí také uvést název databáze. To je nezbytné pro umožnění pokusů o failover ze strany poskytovatele přístupu k datům.

Po obdržení připojovací řetězec poskytovatel datového přístupu uloží počáteční jméno partnera a jméno failover partnera, pokud je zadáno, do cache v volatilní paměti klienta (u spravovaného kódu je cache omezena na aplikační doménu). Jakmile je uloženo do mezipaměti, původní jméno partnera není poskytovatelem přístupu k datům nikdy aktualizováno. Když klient poskytne název partnera pro převzetí služeb při selhání, poskytovatel přístupu k datům tento název partnera také dočasně uloží pro případ, že se poskytovatel nebude moci připojit pomocí názvu původního partnera.

Zrcadlení databáze nechrání před problémy s přístupem na server, které jsou specifické pro klienty, například když má klientský počítač problémy s komunikací se sítí. Pokus o připojení k zrcadlené databázi může také selhat z různých důvodů, které nesouvisejí s poskytovatelem přístupu k datům; například pokus o připojení může selhat, protože hlavní instance serveru je neaktivní, což nastává při přetížení databáze, nebo kvůli síťové chybě.

Při pokusu o připojení poskytovatel přístupu k datům začíná používáním počátečního jména partnera. Pokud je daná instance serveru dostupná a je aktuální hlavní instancí serveru, pokus o připojení obvykle uspěje.

Note

Pokud je zrcadlení pozastaveno, klient se obvykle připojí k hlavnímu serveru a stáhne jméno partnera. Databáze však není klientovi dostupná, dokud není zrcadlení obnoveno.

Pokud tento pokus nefunguje, poskytovatel přístupu k datům zkusí jméno partnera pro failover, pokud je k dispozici. Pokud jméno kteréhokoli z partnerů správně identifikuje aktuální hlavní server, poskytovatel přístupu k datům obvykle uspěje v otevření počátečního připojení. Po dokončení tohoto připojení poskytovatel přístupu k datům stáhne název instance serveru aktuálního zrcadlového serveru. Toto jméno je uloženo v cache jako jméno partnera pro failover, čímž se přepisuje jméno partnera pro failover dodané klientem, pokud existuje. Poté už .NET Framework Zprostředkovatel dat for SQL Server neaktualizuje název partnera při selhání. Naproti tomu SQL Server Native Client aktualizuje mezipaměť pokaždé, když následné připojení nebo reset připojení vrátí jiný název partnera.

Následující obrázek ilustruje klientské spojení s původním partnerem Partner_A pro zrcadlovou databázi nazvanou Db_1. Tento obrázek ukazuje případ, kdy počáteční název partnera zadaný klientem správně identifikuje aktuální hlavní server, Partner_A. Počáteční pokus o připojení je úspěšný a poskytovatel přístupu k datům uloží název zrcadlového serveru ( aktuálně Partner_B) jako jméno partnera pro failover v lokální cache. Nakonec se klient připojí k hlavní kopii databáze Db_1 .

Počáteční pokus o připojení může například selhat kvůli chybě v síti nebo neaktivní instanci serveru. Protože počáteční partner není k dispozici, musí klient v připojovacím řetězci zadat název partnera pro převzetí služeb při selhání, aby se poskytovatel přístupu k datům mohl pokusit se k tomuto partnerovi připojit.

V takovém případě, pokud není jméno partnera pro failover dostupné, původní pokus o připojení pokračuje, dokud nedojde k vypršení síťového připojení nebo není vrácena chyba (stejně jako u nezrcadlené databáze).

Když je v připojovací řetězec uvedeno jméno partnera pro failover, chování poskytovatele přístupu k datům závisí na síťovém protokolu a operačním systému klienta, a to následovně:

• U TCP/IP jsou pokusy o připojení regulovány algoritmem pro opětovné zkusení spojení, který je specifický pro zrcadlení databáze. Algoritmus pro opětovné zkusení spojení určuje maximální čas (dobu zkusení) přidělenou pro otevření spojení v daném pokusu o připojení.

• Pro jiné síťové protokoly

  Pokud dojde k chybě nebo pokud je počáteční partner nedostupný, počáteční pokus o připojení počká, dokud nevyprší časový limit síťového připojení nebo dokud nevyprší lhůta pro přihlášení u poskytovatele přístupu k datům. Obvykle je toto čekání kolem 20 až 30 sekund. Poté, pokud u poskytovatele přístupu k datům nevypršel časový limit, pokusí se připojit k partnerovi pro převzetí služeb při selhání. Pokud vyprší doba vypršení spojení dříve, než spojení uspěje, nebo pokud je failover partner nedostupný, pokus o připojení selže. Pokud je v době vypršení přihlášení dostupný failover partner a nyní je hlavním serverem, pokus o připojení obvykle uspěje.

Spojovací řetězce pro zrcadlenou databázi

připojovací řetězec dodaný klientem obsahuje informace, které poskytovatel přístupu k datům používá k připojení k databázi. Tato sekce se zabývá klíčovými slovy, která jsou konkrétně relevantní pro připojení k zrcadlené databázi pomocí SQL Server Native Client ODBC Driver Connection.

Síťový atribut

připojovací řetězec by měl obsahovat atribut Network pro určení síťového protokolu. To zajišťuje, že specifikovaný síťový protokol přetrvává mezi spojeními k různým partnerům. Nejlepší protokol pro připojení k zrcadlené databázi je TCP/IP. Aby bylo zajištěno, že klient požaduje TCP/IP pro každé spojení partnerům, připojovací řetězec poskytuje následující atribut:

Network=dbmssocn;   

Important

Doporučujeme udržovat TCP/IP na vrcholu seznamu protokolů klienta. Pokud však připojovací řetězec specifikuje síťový atribut, přepisuje to pořadí seznamu.

Případně lze pomocí připojovacího řetězce zadat následující atribut, aby klient pro každé připojení k partnerům vyžadoval pojmenované kanály:

Network=dbnmpntw;   

Important

Protože pojmenované kanály nepoužívají algoritmus opakování pokusů protokolu TCP/IP, může v mnoha případech při pokusu o připojení přes pojmenované kanály vypršet časový limit ještě před připojením k zrcadlené databázi.

Atribut serveru

připojovací řetězec musí obsahovat atribut serveru, který poskytuje počáteční jméno partnera, jež by mělo identifikovat aktuální hlavní instanci serveru.

Nejjednodušší způsob, jak instanci serveru identifikovat, je zadat její název , <server_name>[\<SQL_Server_instance_name>]. Příklady:

Server=Partner_A;

nebo

Server=Partner_A\Instance_2;

Když je však použito jméno systému, klient musí provést DNS vyhledávání, aby získal IP adresu serveru, a dotaz v prohlížeči SQL Server, aby získal číslo portu serveru, na kterém partner sídlí. Tyto dotazy a vyhledávání lze obejít tím, že v atributu serveru zadáte IP adresu a číslo portu partnera, místo aby se specifikoval název serveru. To se doporučuje, aby se minimalizovala možnost vnějších zpoždění při spojení s daným partnerem.

Note

Dotaz v prohlížeči SQL Server je nutný, pokud připojovací řetězec specifikuje pojmenované jméno instance, nikoli port.

Pro určení IP adresy a portu má atribut Server následující tvar, Server=<například ip_address>,<port>:

Server=123.34.45.56,4724;   

Note

IP adresa může být IP verze 4 (IPv4) nebo IP verze 6 (IPv6).

Atribut databáze

Navíc musí připojovací řetězec zadat atribut Database, který poskytne název zrcadlené databáze. Pokud je databáze nedostupná při pokusu klienta o připojení, je vytvořena výjimka.

Například pro explicitní připojení k databázi AdventureWorks na hlavním serverovém Partner_A klient používá následující připojovací řetězec:

" Server=Partner_A; Database=AdventureWorks "

Note

Tento řetězec vynechává autentizační informace.

Important

Zabalení protokolového prefixu s atributem Server (Server=tcp:<servername>) je nekompatibilní s atributem Network a specifikace protokolu na obou místech pravděpodobně povede k chybě. Proto doporučujeme, aby připojovací řetězec specifikoval protokol pomocí atributu Network a v atributu Server ("Network=dbmssocn; Server=<server name>") pouze název serveru.

Atribut partnera pro failover

Kromě počátečního jména partnera může klient také zadat jméno partnera pro failover, které by mělo identifikovat aktuální instanci zrcadlového serveru. Partner při selhání je určen jedním z klíčových slov pro atribut partnera při selhání. Klíčové slovo pro tento atribut závisí na API, které používáte. Následující tabulka uvádí tato klíčová slova:

API	Klíčové slovo pro atribut partnera při failoveru
Zprostředkovatel OLE DB	FailoverPartner
Ovladač ODBC	Failover_Partner
ActiveX Data Objects (ADO)	Záložní partner

Nejjednodušší způsob, jak identifikovat instanci serveru, je podle jejího systémového názvu server_name>[<\<SQL_Server_instance_name>].

Alternativně lze IP adresu a číslo portu zadat v atributu Failover Partner . Pokud počáteční pokus o připojení selže během prvního připojení k databázi, pokus o připojení k partnerovi pro přecházení bude osvobozen od závislosti na DNS a SQL Server Browseru. Jakmile je spojení navázáno, jméno partnera pro přesměrování bude přepsáno jménem partnera pro přesměrování, takže pokud dojde k přesměrování, přesměrovaná spojení budou vyžadovat DNS a SQL Server Browser.

Note

Pokud je uveden pouze původní název partnera, vývojáři aplikací nemusí podnikat žádnou akci ani psát žádný kód kromě toho, jak se znovu připojit.

Note

Vývojáři spravovaných programů uvádějí jméno partnera pro failover v ConnectionString objektu SqlConnection . Pro informace o použití tohoto připojovací řetězec viz "Podpora zrcadlení databází v .NET Framework Zprostředkovatel dat for SQL Server" v dokumentaci ADO.NET, která je součástí SDK Microsoft .NET Framework.

Příklad spojovacího řetězce

Například pro explicitní připojení pomocí TCP/IP k databázi AdventureWorks na Partner_A nebo Partner_B může klientská aplikace používající ODBC ovladač poskytnout následující připojovací řetězec:

"Server=Partner_A; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"  

Alternativně mohl klient použít IP adresu a číslo portu k identifikaci počátečního partnera, Partner_A; například pokud je IP adresa 250.65.43.21 a číslo portu 4734, připojovací řetězec by byl:

"Server=250.65.43.21,4734; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"  

Algoritmus pro opakované pokusy o připojení (pro TCP/IP připojení)

Pro TCP/IP připojení, když jsou v cache obě jména partnerů, poskytovatel přístupu k datům dodržuje algoritmus pro opětovné pokusy o připojení. To platí jak pro navázání prvního spojení se sezením, tak pro opětovné připojení po ztrátě navázaného spojení. Po navázání připojení zabere dokončení kroků před přihlášením i samotného přihlášení další čas.

Note

Čas strávený navazováním spojení může přesahovat dobu opakovaného pokusu kvůli vnějším faktorům, jako jsou pomalé DNS vyhledávání, pomalé doménové řadiče/Kerberos Key Distribution Center (KDC), čas strávený kontaktováním SQL Server Browseru, přetížení sítě a podobně. Takové vnější faktory mohou klientovi zabránit připojení k zrcadlené databázi. Také vnější faktory mohou způsobit, že se připojení otevře déle, než je stanovený čas na opakované pokusy. Pro informace o obejití DNS a SQL Server Browseru při pokusu o připojení k počátečnímu partnerovi viz Making the Initial Connection to a Database Mirroring Session, dříve v tomto tématu.

Pokud pokus o připojení selže nebo čas na opakování uplyne dříve, než uspěje, poskytovatel přístupu k datům se pokusí o druhého partnera. Pokud v této fázi není spojení otevřeno, poskytovatel střídavě zkouší názvy primárního a záložního partnera, dokud se spojení neotevře nebo dokud nevyprší časový limit pro přihlášení. Výchozí časový limit pro přihlášení je 15 sekund. Doporučujeme, aby doba přihlašování byla alespoň 5 sekund. Stanovení kratší doby na vypršení může zabránit úspěchu jakýchkoli pokusů o připojení.

Doba opakovaného pokusu je procento z doby přihlašování. Doba opakovaného pokusu o připojení je v každém dalším kole větší. V prvním kole je doba opakovaného pokusu pro každý z těchto dvou pokusů 8 procent z celkového přihlašovacího období. V každém dalším kole algoritmus opakovaného pokusu prodlužuje maximální dobu opakovaného pokusu o stejnou hodnotu. Doba opakování prvních osmi pokusů o spojení je tedy následující:

8%, 8%, 16%, 16%, 24%, 24%, 32%, 32%

Doba opakovaného pokusu se vypočítává podle následujícího vzorce:

RetryTime=PreviousRetryTime+( 0,08 *LoginTimeout)

Kde je PreviousRetryTime původně 0.

Například pokud se použije výchozí časový limit přihlášení 15 sekund, LoginTimeout= 15. V tomto případě jsou časy opakovaného pokusu v prvních třech kolech následující:

Kulatý	Výpočet RetryTime	Doba opakování na pokus
1	0 +(0,08 * 15)	1,2 sekundy
2	1.2 +(0.08 * 15)	2,4 sekundy
3	2.4 +(0.08 * 15)	3,6 sekundy
4	3.6 +(0.08 * 15)	4,8 sekundy

Následující obrázek znázorňuje tyto intervaly opakování pro po sobě jdoucí pokusy o připojení, z nichž každý skončí vypršením časového limitu.

Pro výchozí dobu přihlašování je maximální doba vyhrazená prvním třem kolům pokusů o připojení 14,4 sekundy. Pokud by každý pokus využil veškerý přidělený čas, zůstalo by jen 0,6 sekundy před vypršením přihlašovacího období. V takovém případě by bylo čtvrté kolo zkráceno, takže by byl možný pouze poslední rychlý pokus o spojení s původním jménem partnera. Nicméně pokus o spojení může selhat za kratší dobu, než je stanovená, zejména v pozdějších kolech. Například obdržení síťové chyby může způsobit ukončení pokusu dříve, než vyprší čas na opakování. Pokud by předchozí pokusy selhaly kvůli chybě sítě, byl by k dispozici další čas na čtvrté kolo a možná i další kola.

Další příčinou neúspěšného pokusu je neaktivní instance serveru, což nastává, když je instance serveru zapojena do selhání nad svou databází. V tomto případě je zavedena prodleva před opakováním pokusu, aby se zabránilo tomu, že klienti přetíží partnerské systémy rychle po sobě jdoucími pokusy o připojení.

Note

Jsou-li k dispozici oba názvy partnerů a časový limit přihlášení je nekonečný, klient se pokouší znovu připojovat k serverům neomezeně dlouho a střídavě používá původní název partnera a název partnera pro převzetí služeb při selhání.

Zpoždění při opětovném pokusu během failoveru

Pokud se klient pokusí připojit k partnerovi, který přechází přes failover, partner okamžitě odpoví, že je neaktivní. V tomto případě je každé kolo pokusů o připojení mnohem kratší než přidělený čas na opakování. To znamená, že před uplynutím přihlašovacího období může proběhnout mnoho kol pokusů o připojení. Aby se předešlo přetížení partnerů rychlou sérií pokusů o připojení během failoveru, poskytovatel přístupu k datům přidává krátké zpoždění pro opakované pokusy po každém cyklu opětovného pokusu. Délka daného zpoždění opakovaného pokusu je určena algoritmem zpoždění opakovaného pokusu. Po prvním kole je zpoždění 100 milisekund. Po každém ze tří kol se zpoždění opakovaného pokusu zdvojnásobí na 200, 400 a 800. U všech pozdějších kol je zpoždění opakovaného pokusu 1 sekunda, než pokus o připojení uspěje nebo vyprší čas.

Note

Pokud je instance serveru zastavena, požadavek na spojení okamžitě selže.

Následující obrázek ilustruje, jak zpoždění opakovaného pokusu ovlivňuje pokusy o připojení během manuálního failoveru, kdy partneři vymění své role. Doba pro přihlášení je 15 sekund.

Opětovné připojení k zrcadlení databáze

Pokud navázané spojení s databázovou zrcadlovací relací selže z jakéhokoliv důvodu, například kvůli failoveru zrcadlení databáze, a aplikace se pokusí znovu připojit k původnímu serveru, poskytovatel přístupu k datům se může pokusit znovu připojit pomocí jména partnera pro failover uloženého v cache klienta. Opětovné připojení však není automatické. Aplikace si musí chybu uvědomit. Poté musí aplikace ukončit neúspěšné spojení a otevřít nové spojení se stejnými atributy připojovací řetězec. V tomto okamžiku poskytovatel přístupu k datům přesměruje spojení na partnera pro failover. Pokud je instancí serveru identifikovaná tímto názvem aktuálně hlavní server, pokus o připojení obvykle uspěje. Pokud není jasné, zda byla transakce provedena nebo vrácena, aplikace musí zkontrolovat stav transakce stejným způsobem jako při opětovném připojení k samostatné serverové instanci.

Opětovné připojení probíhá podobně jako počáteční připojení, u kterého připojovací řetězec obsahoval název partnera pro převzetí služeb při selhání. Pokud první pokus o spojení selže, střídají se mezi původním jménem partnera a jménem partnera pro failover, dokud se klient nepřipojí k hlavnímu serveru nebo dokud nevyprší čas poskytovatele přístupu k datům.

Note

SQL Server Native Client ověřuje, že se připojuje k instanci primárního serveru, nikoli však to, zda je tato instance partnerem instance serveru uvedené v počátečním názvu partnera v připojovacím řetězci.

Pokud spojení používají TCP/IP, algoritmus pro opětovné zkusení připojení určuje čas vyhrazený pokusům o připojení v každém kole.

Important

Pokud je klient odpojen od databáze, poskytovatel přístupu k datům se nepokusí znovu připojit. Klient musí vydat nový požadavek na připojení. Pokud se aplikace po ztrátě spojení vypne, ztratí mezipaměti partnerů. Pokud bylo spojení ztraceno, protože hlavní server se stal nedostupným, jediný způsob, jak se aplikace může znovu připojit k zrcadlovému serveru, je zadat jméno failover partnera do svého připojovací řetězec.

Dopad přesměrování na klientskou aplikaci

Po failoveru poskytovatel přístupu k datům přesměruje spojení na aktuální instanci hlavního serveru. Nicméně přesměrování je pro klienty transparentní. Pro klienta se přesměrované spojení jeví jako spojení k serverové instanci identifikované počátečním jménem partnera. Když je původní partner aktuálně zrcadleným serverem, klient se může zdát, že je připojen k zrcadlovému serveru a aktualizuje zrcadlovou databázi. Ve skutečnosti však klient byl přesměrován na partnera pro failover, což je současná hlavní databáze, a klient aktualizuje novou hlavní databázi.

Po přesměrování na partnera pro failover může klient zaznamenat neočekávané výsledky při použití příkazu Transact-SQL USE pro použití jiné databáze. To se může stát, pokud má současná instance hlavního serveru (partner pro failover) jinou sadu databází než původní hlavní server (počáteční partner).

Dopad zastaralého jména partnera pro failover

Správce databáze může kdykoli změnit partnera pro failover. Proto může být název klientem zadaného partnera pro převzetí služeb při selhání zastaralý nebo neaktuální. Například uvažujme partnera pro failover jménem Partner_B, který je nahrazen jinou instancí serveru, Partner_C. Pokud klient zadá Partner_B jako jméno partnera pro failover, ten název je zastaralý. Když je jméno partnera pro failover dodané klientem zastaralé, chování poskytovatele přístupu k datům odpovídá situaci, kdy klient jméno partnera pro failover neposkytuje.

Například uvažujme situaci, kdy klient použije jeden připojovací řetězec pro sérii čtyř pokusů o připojení. V připojovacím řetězci je název počátečního partnera Partner_A a název partnera převzetí služeb při selhání je Partner_B:

"Server=Partner_A; Failover Partner=Partner_B; Database=AdventureWorks"  

Následující tabulka ukazuje čtyři konfigurace partnerů a uvádí, zda pro každou z nich tento připojovací řetězec funguje pro připojení klienta poprvé.

Note

Aplikace může sledovat změny konfigurace a podle toho upravovat svůj připojovací řetězec. To vyžaduje další kód, ale snižuje administrativní zátěž.

Configuration	Hlavní server	Zrcadlový server	Chování při pokusu o připojení při zadání Partner_A a Partner_B
Původní konfigurace zrcadlení.	Partner_A	Partner_B	Partner_A je uložen jako původní název partnera. Klient se s Partner_A úspěšně spojí. Klient stáhne název zrcadlového serveru Partner_B a uloží ho do mezipaměti, přičemž ignoruje jméno partnera pro failover zadané klientem.
Partner_A dojde k hardwarové selhání a dojde k failoveru (odpojení klientů).	Partner_B	none	Partner_A je stále uložen jako původní název partnera, ale klientem dodané jméno partnera pro failover, Partner_B, umožňuje klientovi připojit se k aktuálnímu hlavnímu serveru.
Správce databáze zastaví zrcadlení (odpojí klienty), nahradí Partner_A partnerem Partner_C a znovu spustí zrcadlení.	Partner_B	Partner_C	Klient se pokusí připojit k Partner_A a neuspěje; Poté klient zkusí Partner_B (současný hlavní server) a uspěje. Poskytovatel přístupu k datům stáhne název aktuálního zrcadlového serveru Partner_C a uloží jej do mezipaměti jako aktuální jméno partnera pro failover.
Služba se ručně přesměruje na Partner_C (odpojuje klienty).	Partner_C	Partner_B	Klient se nejprve pokusí připojit k Partner_A a poté k Partner_B. Obě jména selžou a nakonec požadavek na spojení vyprší a selže.

Související obsah

• Zrcadlení databáze (SQL Server)
• Možné chyby během zrcadlení databáze