Koppla klienter till en databasspegeleringssession (SQL Server)

Gäller för:SQL Server

För att ansluta till en databasspegelsession kan en klient använda antingen SQL Server Native Client eller .NET Framework Data Provider för SQL Server. När dessa dataåtkomstleverantörer är konfigurerade för en SQL Server-databas stöder båda fullt ut databasspegling. För information om programmeringsöverväganden vid användning av en speglad databas, se Användning av databasspegling. Dessutom måste den nuvarande huvudserverinstansen vara tillgänglig och klientens inloggning måste ha skapats på serverinstansen. För mer information, se Felsökning av föräldralösa användare (SQL Server). Klientanslutningar till en databasspeglingssession omfattar inte vittnesserverinstansen, om en sådan finns.

Att göra den initiala anslutningen till en databasspegeleringssession

För den initiala anslutningen till en speglad databas måste en klient tillhandahålla en reťazec pripojenia som minst anger namnet på en serverinstans. Detta nödvändiga servernamn ska identifiera den aktuella huvudserverinstansen och kallas det initiala partnernamnet.

Valfritt kan reťazec pripojenia även ange namnet på en annan serverinstans, som ska identifiera den aktuella mirror server-instansen, för användning om den initiala partnern inte är tillgänglig under det första anslutningsförsöket. Det andra namnet kallas failover-partnernamnet.

reťazec pripojenia måste också ange ett databasnamn. Detta är nödvändigt för att möjliggöra failover-försök av dataåtkomstleverantören.

När en reťazec pripojenia tas emot lagrar dataåtkomstleverantören det initiala partnernamnet och failover-partnernamnet, om det tillhandahålls, i en cache i klientens flyktiga minne (för hanterad kod är cachen begränsad till applikationsdomänen). När den är cachad uppdateras aldrig det ursprungliga partnernamnet av dataåtkomstleverantören. När klienten tillhandahåller failover-partnerns namn lagrar dataåtkomstleverantören också detta failover-partnernamn tillfälligt ifall leverantören inte kan ansluta med det ursprungliga partnernamnet.

En databasspegelningssession skyddar inte mot serveråtkomstproblem som är specifika för klienter, till exempel när en klientdator har problem med att kommunicera med nätverket. Ett anslutningsförsök till en speglad databas kan också misslyckas av olika skäl som inte har med dataåtkomstleverantören att göra; Till exempel kan ett anslutningsförsök misslyckas eftersom huvudserverinstansen är inaktiv, vilket sker när databasen failover, eller på grund av ett nätverksfel.

När man försöker ansluta börjar dataåtkomstleverantören med att använda det initiala partnernamnet. Om den angivna serverinstansen är tillgänglig och är den aktuella huvudsakliga serverinstansen, lyckas anslutningsförsöket vanligtvis.

Om det försöket inte fungerar, försöker dataåtkomstleverantören använda namnet på redundanspartnern, om det är tillgängligt. Om något av partnerns namn korrekt identifierar den nuvarande huvudservern lyckas dataåtkomstleverantören normalt öppna den initiala anslutningen. När denna anslutning är slutförd laddar dataåtkomstleverantören ner serverinstansnamnet på den aktuella spegelservern. Detta namn lagras i cachen som namnet på redundanspartnern och ersätter i förekommande fall det namn på redundanspartnern som klienten har angett. Därefter uppdaterar inte .NET Framework Data Provider för SQL Server failover-partnerns namn. I kontrast uppdaterar SQL Server Native Client cachen varje gång en efterföljande anslutning eller anslutningsåterställning returnerar ett annat partnernamn.

Följande figur illustrerar en klientanslutning till den initiala partnern, Partner_A, för en speglad databas vid namn Db_1. Denna figur visar ett fall där det initiala partnernamnet som klienten tillhandahåller korrekt identifierar den aktuella huvudservern, Partner_A. Det initiala anslutningsförsöket lyckas, och dataåtkomstleverantören lagrar namnet på spegelservern (för närvarande Partner_B) som failover-partnerns namn i den lokala cachen. Slutligen ansluter klienten till huvudkopian av Db_1 databasen.

Det initiala anslutningsförsöket kan misslyckas, till exempel på grund av ett nätverksfel eller en inaktiv serverinstans. Eftersom den initiala partnern inte är tillgänglig, måste klienten ha angett failover-partnerns namn i reťazec pripojenia för att dataåtkomstleverantören ska försöka ansluta till failover-partnern.

I det fallet, om namnet på redundanspartnern inte är tillgängligt, fortsätter det ursprungliga anslutningsförsöket tills tidsgränsen för nätverksanslutningen uppnås eller ett fel uppstår (precis som med en icke-speglad databas).

När failover-partnerns namn anges i reťazec pripojenia beror dataåtkomstleverantörens beteende på klientens nätverksprotokoll och operativsystem, enligt följande:

• För TCP/IP regleras anslutningsförsöken av en återuppkopplingsalgoritm som är specifik för databasspegling. Återförsöksalgoritmen för anslutningar bestämmer den maximala tiden (återförsökstiden) som tilldelas för att öppna en anslutning i ett givet anslutningsförsök.

• För andra nätverksprotokoll

  Om ett fel uppstår eller om den initiala partnern inte är tillgänglig, väntar det initiala anslutningsförsöket tills nätverksanslutningens tidsavslutningsperiod löper ut eller inloggningstiden löper ut för dataåtkomstleverantören. Vanligtvis är denna väntetid mellan 20 och 30 sekunder. Därefter, om dataåtkomstleverantören inte har gått ut på tidsgränsen, försöker den ansluta till failover-partnern. Om anslutningstidsperioden löper ut innan anslutningen lyckas eller om failover-partnern inte är tillgänglig, misslyckas anslutningsförsöket. Om failover-partnern är tillgänglig inom inloggningstidsperioden och nu är huvudservern, lyckas anslutningsförsöket normalt.

Anslutningssträngar för en speglad databas

Den reťazec pripojenia som tillhandahålls av klienten innehåller information som dataåtkomstleverantören använder för att ansluta till databasen. Detta avsnitt diskuterar de nyckelord som är särskilt relevanta för att ansluta till en speglad databas med hjälp av en SQL Server Native Client ODBC Driver Connection.

Nätverksattribut

reťazec pripojenia bör innehålla attributet Network för att specificera nätverksprotokollet. Detta säkerställer att det angivna nätverksprotokollet består mellan anslutningar till olika partners. Det bästa protokollet för att ansluta till en speglad databas är TCP/IP. För att säkerställa att klienten begär TCP/IP för varje anslutning till partnerna tillhandahåller en reťazec pripojenia följande attribut:

Network=dbmssocn;   

Alternativt, för att säkerställa att klienten begär namngivna pipes för varje anslutning till partnerna, tillhandahåller en reťazec pripojenia följande attribut:

Network=dbnmpntw;   

Serverattribut

reťazec pripojenia måste innehålla ett serverattribut som tillhandahåller det initiala partnernamnet, vilket ska identifiera den aktuella huvudserverinstansen.

Det enklaste sättet att identifiera serverinstansen är att ange dess namn , <server_name>[\<SQL_Server_instance_name>]. Ett exempel:

Server=Partner_A;

eller

Server=Partner_A\Instance_2;

När systemnamnet används måste klienten dock utföra en DNS-sökning för att få fram serverns IP-adress och en SQL Server Browser-sökning för att få portnumret på servern där partnern finns. Dessa uppslagningar och frågor kan kringgås genom att ange partnerns IP-adress och portnummer i serverattributet , istället för att ange servernamnet. Detta rekommenderas för att minimera risken för externa förseningar vid anslutning till den partnern.

För att specificera IP-adress och port tar Server-attributet följande form, <till exempel ip_address>,<port>:Server=

Server=123.34.45.56,4724;   

Databasattribut

Dessutom måste reťazec pripojenia specificera Database-attributet för att tillhandahålla namnet på den speglade databasen. Om databasen inte är tillgänglig när klienten försöker ansluta aktiveras ett undantag.

Till exempel, för att uttryckligen ansluta till AdventureWorks-databasen på huvudserverns Partner_A, använder en klient följande reťazec pripojenia:

" Server=Partner_A; Database=AdventureWorks "

Attribut för redundanspartner

Utöver det initiala partnernamnet kan klienten även ange failover-partnernamn, vilket bör identifiera den aktuella spegelserverinstansen. Failover-partnern specificeras med ett av nyckelorden för failover-partnerattributet. Nyckelordet för detta attribut beror på vilket API du använder. Följande tabell listar dessa nyckelord:

Det enklaste sättet att identifiera serverinstansen är genom dess systemnamn, <server_name>[\<SQL_Server_instance_name>].

Alternativt kan IP-adressen och portnumret anges i attributet Failover Partner . Om det initiala anslutningsförsöket misslyckas under den första anslutningen till databasen, kommer försöket att ansluta till failover-partnern att slippa förlita sig på DNS och SQL Server Browser. När en anslutning är etablerad kommer failover-partnerns namn att skrivas över med failover-partnerns namn, så om en failover sker kräver de omdirigerade anslutningarna DNS och SQL Server Browser.

Exempel på anslutningssträng

Till exempel, för att explicit ansluta med TCP/IP till AdventureWorks-databasen på antingen Partner_A eller Partner_B, kan en klientapplikation som använder ODBC-drivrutinen tillhandahålla följande reťazec pripojenia:

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

Alternativt kan klienten använda IP-adressen och portnumret för att identifiera den initiala partnern, Partner_A; till exempel, om IP-adressen är 250.65.43.21 och portnumret är 4734, skulle reťazec pripojenia vara:

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

Återförsöksalgoritm för anslutningar (för TCP/IP-anslutningar)

För en TCP/IP-anslutning, när båda partnernamnen finns i cachen, följer dataåtkomstleverantören en återkopplingsalgoritm. Detta gäller både för att göra den initiala anslutningen till sessionen och för att återansluta efter att ha förlorat en etablerad anslutning. När en anslutning har öppnats tar det extra tid att slutföra förinloggnings- och inloggningsstegen.

Om ett anslutningsförsök misslyckas eller om försökstiden går ut innan det lyckas, försöker dataåtkomstleverantören den andra partnern. Om en anslutning inte öppnas vid denna tidpunkt testar leverantören växelvis initial- och failover-partnernamnen, tills en anslutning öppnas eller inloggningsperioden går ut. Standardtiden för inloggningstid är 15 sekunder. Vi rekommenderar att inloggningstiden är minst 5 sekunder. Att ange en kortare timeout-period kan förhindra att några anslutningsförsök lyckas.

Omprövningstiden är en procentandel av inloggningsperioden. Omprövningstiden för ett anslutningsförsök är längre i varje efterföljande runda. I första omgången är omprövningstiden för varje av de två försöken 8 procent av den totala inloggningsperioden. I varje efterföljande runda ökar återförsöksalgoritmen den maximala omprövningstiden med samma mängd. Alltså är omförsökstiderna för de första åtta anslutningsförsöken följande:

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

Omprövningstiden beräknas med följande formel:

RetryTime=PreviousRetryTime+( 0.08 *LoginTimeout)

Där PreviousRetryTime initialt är 0.

Till exempel, om man använder standardtiden för inloggning på 15 sekunder, är LoginTimeout= 15. I detta fall är omtestningstiderna som tilldelats under de tre första rundorna följande:

Följande figur illustrerar dessa återförsökstider för successiva anslutningsförsök, där varje anslutning går ut i tid.

För standardtiden för inloggning är den maximala tiden för de tre första omgångarna av anslutningsförsök 14,4 sekunder. Om varje försök skulle använda all tilldelad tid skulle endast 0,6 sekunder återstå innan inloggningsperioden går ut. I så fall skulle den fjärde omgången förkortas, vilket endast tillåter ett sista snabbt försök att ansluta med det ursprungliga partnernamnet. Ett anslutningsförsök kan dock misslyckas på kortare tid än sin tilldelade tid för återförsök, särskilt i senare omgångar. Till exempel kan ett nätverksfel leda till att ett försök avslutas innan omprövningstiden går ut. Om tidigare försök misslyckas på grund av ett nätverksfel skulle ytterligare tid finnas tillgänglig för fjärde omgången och kanske ytterligare omgångar.

En annan orsak till ett misslyckat försök är en inaktiv serverinstans, vilket uppstår när en serverinstans är upptagen med att bryta över sin databas. I detta fall införs en fördröjning mellan återförsök för att förhindra att klienterna överbelastar partnerna genom tätt återkommande anslutningsförsök.

Fördröjningar vid omprövning under failover

Om en klient försöker koppla upp sig till en partner som håller på att misslyckas, svarar partnern omedelbart att den är inaktiv. I detta fall är varje omgång av anslutningsförsök mycket kortare än den tilldelade omgångstiden. Detta innebär att många anslutningsförsök kan ske innan inloggningsperioden löper ut. För att undvika att överbelasta partnerna med en snabb serie anslutningsförsök under en failover, lägger dataåtkomstleverantören till en kort fördröjning efter varje återförsökscykel. Längden på en given försöksfördröjning bestäms av återförsöksfördröjningsalgoritmen. Efter första rundan är fördröjningen 100 millisekunder. Efter var och en av de tre följande omgångarna fördubblas omprövningsfördröjningen till 200, 400 och 800. För alla senare omgångar är väntetiden för nya försök 1 sekund tills anslutningsförsöket lyckas eller tidsgränsen nås.

Följande figur illustrerar hur återförsöksfördröjningen påverkar anslutningsförsök under en manuell failover, där partnerna byter roller. Inloggningstiden är 15 sekunder.

Återanslutning till en databas-speglingssession

Om en etablerad anslutning till en databas-speglingssession misslyckas av någon anledning, till exempel på grund av en databasspeglingsfailover, och applikationen försöker återansluta till den ursprungliga servern, kan dataåtkomstleverantören försöka återansluta med failover-partnerns namn som lagrats i klientens cache. Att återansluta sker dock inte automatiskt. Applikationen måste bli medveten om felet. Därefter behöver applikationen stänga den misslyckade anslutningen och öppna en ny anslutning med samma attribut för reťazec pripojenia. Vid denna punkt omdirigerar dataåtkomstleverantören anslutningen till failover-partnern. Om serverinstansen som identifieras med detta namn för närvarande är huvudservern lyckas anslutningsförsöket vanligtvis. Om det är oklart om en transaktion har gjorts eller rullats tillbaka måste applikationen kontrollera transaktionens tillstånd, på samma sätt som vid återanslutning till en fristående serverinstans.

Återanslutning liknar en första anslutning där namnet på en redundanspartner angavs i anslutningssträngen. Om det första anslutningsförsöket misslyckas, växlar anslutningsförsöken fram och tillbaka mellan det ursprungliga partnernamnet och redundanspartnernamnet tills antingen klienten ansluter till huvudservern eller tidsgränsen för dataåtkomstleverantören överskrids.

Om anslutningarna använder TCP/IP bestämmer återkopplingsalgoritmen hur mycket tid som tilldelas anslutningsförsöken i varje runda.

Omdirigeringens påverkan på en klientapplikation

Efter en failover omdirigerar dataåtkomstleverantören anslutningen till den aktuella huvudserverinstansen. Dock är omdirigeringen transparent för kunderna. För en klient framstår en omdirigerad anslutning som en anslutning till serverinstansen som identifierats med det ursprungliga partnernamnet. När den initiala partnern för närvarande är spegelservern kan klienten se ut som att den är ansluten till spegelservern och uppdaterar spegeldatabasen. I själva verket har klienten dock omdirigerats till failover-partnern, som är den nuvarande huvuddatabasen, och klienten uppdaterar den nya huvudsakliga databasen.

Efter att ha omdirigerats till failover-partnern kan en klient uppleva oväntade resultat när de använder ett Transact-SQL USE-uttalande för att använda en annan databas. Detta kan hända om den nuvarande huvudserverinstansen (failover-partnern) har en annan uppsättning databaser än den ursprungliga huvudservern (den initiala partnern).

Effekten av ett gammalt failover-partnernamn

Databasadministratören kan byta failover-partner när som helst. Därför kan ett klientangivet failover-partnernamn vara föråldrat eller inaktuellt. Till exempel, beakta en failover-partner som heter Partner_B som ersätts av en annan serverinstans, Partner_C. Om en kund nu anger Partner_B som failover-partnerns namn är det namnet föråldrat. När det klienttillhandahållna failover-partnernamnet är föråldrat, motsvarar dataåtkomstleverantörens beteende att ett failover-partnernamn inte tillhandahålls av klienten.

Till exempel, betrakta en situation där en klient använder en reťazec pripojenia för en serie av fyra anslutningsförsök. I reťazec pripojenia är det initiala partnernamnet Partner_A, och failover-partnerns namn är Partner_B:

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

Följande tabell visar fyra partnerkonfigurationer och anger för varje om denna reťazec pripojenia fungerar för att ansluta klienten för första gången.

Relaterat innehåll

• Databasåterspegling (SQL Server)
• Möjliga fel vid databasspegling