Verbind clients met een databasespiegelingssessie (SQL Server)

Van toepassing op:SQL Server

Om verbinding te maken met een databasespiegelingssessie kan een client gebruikmaken van SQL Server Native Client of .NET Framework Data Provider voor SQL Server. Wanneer deze data-toegangsproviders zijn geconfigureerd voor een SQL Server-database, ondersteunen beide volledig database-mirroring. Voor informatie over programmeeroverwegingen bij het gebruik van een gespiegelde database, zie Using Database Mirroring. Daarnaast moet de huidige hoofdserverinstantie beschikbaar zijn en moet de login van de client op de serverinstantie zijn aangemaakt. Voor meer informatie, zie Probleemoplossing voor verweesde gebruikers (SQL Server). Clientverbindingen met een databasespiegelingssessie betreffen niet de witness server-instantie, als die er is.

De initiële verbinding maken met een databasespiegelingssessie

Voor de initiële verbinding met een gespiegelde database moet een client een verbindingsreeks leveren die minimaal de naam van een serverinstantie bevat. Deze vereiste servernaam moet de huidige hoofdserverinstantie identificeren en staat bekend als de initiële partnernaam.

Optioneel kan de verbindingsreeks ook de naam van een andere serverinstantie leveren, die de huidige mirror serverinstantie zou moeten identificeren, voor gebruik als de initiële partner niet beschikbaar is tijdens de eerste verbindingspoging. De tweede naam staat bekend als de failover-partnernaam.

De verbindingsreeks moet ook een databasenaam leveren. Dit is noodzakelijk om failoverpogingen door de data-toegangsprovider mogelijk te maken.

Bij ontvangst van een verbindingsreeks slaat de data access provider de initiële partnernaam en de failover-partnernaam, indien opgeleverd, op in een cache in het vluchtige geheugen van de client (voor beheerde code is de cache beperkt tot het applicatiedomein). Eenmaal gecachet wordt de initiële partnernaam nooit bijgewerkt door de data-toegangsprovider. Wanneer de client de failover-partnernaam oplevert, slaat de data-toegangsprovider deze failover-partnernaam ook tijdelijk op voor het geval de provider niet met de initiële partnernaam kan verbinden.

Een databasespiegelingssessie beschermt niet tegen servertoegangsproblemen die specifiek zijn voor clients, zoals wanneer een clientcomputer problemen heeft met communiceren met het netwerk. Een verbindingspoging naar een gespiegelde database kan ook mislukken om verschillende redenen die niets met de data-toegangsprovider te maken hebben; Een verbindingspoging kan bijvoorbeeld mislukken omdat de hoofdserverinstantie inactief is, zoals gebeurt wanneer de database failovert, of door een netwerkfout.

Bij het proberen te verbinden begint de data-toegangsprovider met het gebruik van de oorspronkelijke partnernaam. Als de gespecificeerde serverinstantie beschikbaar is en de huidige hoofdserverinstantie is, slaagt de verbindingspoging doorgaans.

Als die poging mislukt, probeert de provider voor gegevenstoegang de naam van de failoverpartner, indien beschikbaar. Als een van de partnernamen de huidige hoofdserver correct identificeert, slaagt de data-toegangsprovider er normaal gesproken in de initiële verbinding te openen. Na voltooiing van deze verbinding downloadt de data-toegangsprovider de serverinstantienaam van de huidige spiegelserver. Deze naam wordt opgeslagen in de cache als de naam van de failoverpartner, waarbij de door de client geleverde failoverpartnernaam, indien aanwezig, wordt overschreven. Daarna werkt de .NET Framework Data Provider voor SQL Server de naam van de failover-partner niet bij. Daarentegen werkt de SQL Server Native Client de cache bij telkens wanneer een volgende verbinding of verbinding reset een andere partnernaam teruggeeft.

De volgende figuur illustreert een clientverbinding met de oorspronkelijke partner, Partner_A, voor een gespiegelde database genaamd Db_1. Deze figuur toont een geval waarin de initiële partnernaam die door de client wordt opgegeven correct de huidige hoofdserver, Partner_A, identificeert. De eerste verbindingspoging slaagt, en de data-toegangsprovider slaat de naam van de mirrorserver (momenteel Partner_B) op als de naam van de failoverpartner in de lokale cache. Ten slotte maakt de client verbinding met de hoofdkopie van de Db_1 database.

De eerste verbindingspoging kan bijvoorbeeld mislukken door een netwerkfout of een inactieve serverinstantie. Omdat de oorspronkelijke partner niet beschikbaar is, moet de client de naam van de failoverpartner in de verbindingsreeks hebben opgegeven, zodat de gegevensprovider kan proberen verbinding te maken met de failoverpartner.

In dat geval, als de naam van de failoverpartner niet beschikbaar is, gaat de oorspronkelijke verbindingspoging door totdat de netwerkverbinding uitvalt of er een foutmelding wordt weergegeven (net als bij een niet-gespiegelde database).

Wanneer de naam van de failoverpartner wordt opgegeven in de verbindingsreeks, hangt het gedrag van de data-toegangsprovider af van het netwerkprotocol en besturingssysteem van de client, als volgt:

• Voor TCP/IP worden de verbindingspogingen geregeld door een verbindingsherhalingsalgoritme dat specifiek is voor databasespiegeling. Het verbindingsherkansingsalgoritme bepaalt de maximale tijd (de herkansingstijd) die is toegewezen om een verbinding te openen bij een bepaalde verbindingspoging.

• Voor andere netwerkprotocollen

  Als er een fout optreedt of als de initiële partner niet beschikbaar is, wacht de eerste verbindingspoging totdat de time-outperiode voor de netwerkverbinding is verstreken of totdat de aanmeldingstime-outperiode bij de provider voor gegevenstoegang is verstreken. Meestal duurt deze wachttijd ongeveer 20 tot 30 seconden. Daarna, als de provider voor gegevenstoegang nog geen time-out heeft gehad, probeert de provider verbinding te maken met de failoverpartner. Als de time-out van de verbinding verloopt voordat de verbinding slaagt of de failoverpartner niet beschikbaar is, mislukt de verbindingspoging. Als failoverpartner beschikbaar is binnen de inlogtijd en nu de hoofdserver is, slaagt de verbindingspoging normaal.

Verbindingsstrings voor een gespiegelde database

De door de client geleverde verbindingsreeks bevat informatie die de data-toegangsprovider gebruikt om verbinding te maken met de database. Deze sectie bespreekt de trefwoorden die specifiek relevant zijn voor het verbinden met een gespiegelde database via een SQL Server Native Client ODBC Driver Connection.

Netwerkattribuut

De verbindingsreeks moet het Network-attribuut bevatten om het netwerkprotocol te specificeren. Dit zorgt ervoor dat het gespecificeerde netwerkprotocol blijft bestaan tussen verbindingen met verschillende partners. Het beste protocol om verbinding te maken met een gespiegelde database is TCP/IP. Om ervoor te zorgen dat de client TCP/IP aanvraagt voor elke verbinding met de partners, levert een verbindingsreeks het volgende attribuut:

Network=dbmssocn;   

Alternatief, om ervoor te zorgen dat de client voor elke verbinding met de partners benoemde pipes opvraagt, levert een verbindingsreeks het volgende attribuut:

Network=dbnmpntw;   

Serverattribuut

De verbindingsreeks moet een Server-attribuut bevatten dat de naam van de initiële partner levert, waarmee de huidige hoofdserverinstantie wordt geïdentificeerd.

De eenvoudigste manier om de serverinstantie te identificeren is door de naam , <server_name>[\<SQL_Server_instance_name>] op te geven. Voorbeeld:

Server=Partner_A;

or

Server=Partner_A\Instance_2;

Wanneer echter de systeemnaam wordt gebruikt, moet de client een DNS-zoekopdracht uitvoeren om het IP-adres van de server te verkrijgen en een SQL Server Browser-query doen om het poortnummer van de server waarop de partner zich bevindt te verkrijgen. Die opzoekingen en zoekopdrachten kunnen worden omzeild door het IP-adres en poortnummer van de partner in het serverattribuut op te geven, in plaats van de servernaam. Dit wordt aanbevolen om de kans op externe vertragingen tijdens het verbinden met die partner te minimaliseren.

Om het IP-adres en de poort te specificeren, neemt het Server-attribuut de volgende vorm aan: Server=<bijvoorbeeld ip_address>,<poort>:

Server=123.34.45.56,4724;   

Databaseattribuut

Daarnaast moet de verbindingsreeks het Database-attribuut specificeren om de naam van de gespiegelde database te geven. Als de database niet beschikbaar is wanneer de client probeert verbinding te maken, wordt er een uitzondering geactiveerd.

Om bijvoorbeeld expliciet verbinding te maken met de AdventureWorks-database op de hoofdserver Partner_A, gebruikt een client de volgende verbindingsreeks:

" Server=Partner_A; Database=AdventureWorks "

Failover-partnerattribuut

Naast de initiële partnernaam kan de client ook de failover-partnernaam specificeren, die de huidige mirror-serverinstantie zou moeten identificeren. De failoverpartner wordt gespecificeerd door een van de trefwoorden voor het failover-partnerattribuut. Het sleutelwoord voor dit attribuut hangt af van de API die je gebruikt. De volgende tabel geeft deze trefwoorden weer weer:

De eenvoudigste manier om de serverinstantie te identificeren is via de systeemnaam, <server_name>[\<SQL_Server_instance_name>].

Alternatief kunnen het IP-adres en poortnummer worden opgegeven in het Failover Partner-attribuut. Als de eerste verbindingspoging mislukt tijdens de eerste verbinding met de database, wordt de poging om verbinding te maken met de failoverpartner vrijgesteld van het vertrouwen op DNS en de SQL Server Browser. Zodra een verbinding tot stand is gebracht, wordt de naam van de failoverpartner overschreven met de naam van de failoverpartner, dus als er een failover plaatsvindt, hebben de omgeleide verbindingen DNS en SQL Server Browser nodig.

Voorbeeld van verbindingsstring

Om bijvoorbeeld expliciet via TCP/IP verbinding te maken met de AdventureWorks-database op Partner_A of Partner_B, kan een clientapplicatie die de ODBC-driver gebruikt de volgende verbindingsreeks leveren:

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

Als alternatief kan de client het IP-adres en poortnummer gebruiken om de initiële partner te identificeren, Partner_A; bijvoorbeeld, als het IP-adres 250.65.43.21 is en het poortnummer 4734, zou de verbindingsreeks zijn:

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

Verbindingsherkansingsalgoritme (voor TCP/IP-verbindingen)

Voor een TCP/IP-verbinding, wanneer beide partnernamen in de cache staan, volgt de data-toegangsprovider een verbindingsherkansingsalgoritme. Dit geldt zowel voor het maken van de eerste verbinding met de sessie als voor het opnieuw verbinden na het verliezen van een gevestigde verbinding. Zodra een verbinding is geopend, kost het voltooien van de pre-login- en loginstappen extra tijd.

Als een verbindingspoging mislukt of de herkansingstijd verloopt voordat het slaagt, probeert de data-toegangsprovider de andere partner. Als er op dat moment geen verbinding is geopend, probeert de provider afwisselend de initiale en failover-partnernamen, totdat er een verbinding wordt geopend of de inlogperiode afloopt. De standaard inlogtijd is 15 seconden. We raden aan dat de inlogtijd minstens 5 seconden bedraagt. Het specificeren van een kortere time-out periode kan voorkomen dat een van de verbindingspogingen slaagt.

De herkansingstijd is een percentage van de inlogperiode. De herkansingstijd voor een verbindingspoging is in elke opeenvolgende ronde langer. In de eerste ronde is de herkansingstijd voor elk van de twee pogingen 8 procent van de totale inlogperiode. In elke opeenvolgende ronde verhoogt het herpogingsalgoritme de maximale herkansingstijd met hetzelfde bedrag. Dus de herpogingstijden voor de eerste acht verbindingspogingen zijn als volgt:

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

De herpogingstijd wordt berekend met de volgende formule:

RetryTime=PreviousRetryTime+( 0.08 *LoginTimeout)

Waar PreviousRetryTime aanvankelijk 0 is.

Als je bijvoorbeeld de standaard inlogtime-out van 15 seconden gebruikt, is LoginTimeout= 15. In dit geval zijn de herkansingstijden die in de eerste drie rondes zijn toegewezen als volgt:

De volgende figuur illustreert deze herpogingstijden voor opeenvolgende verbindingspogingen, die elk uitlopen.

Voor de standaard inlogtime-out is de maximale tijd die wordt toegewezen aan de eerste drie rondes van verbindingspogingen 14,4 seconden. Als elke poging de toegewezen tijd zou gebruiken, zou er slechts 0,6 seconden tijd overblijven voordat de inlogperiode afloopt. In dat geval wordt de vierde ronde ingekort, zodat alleen een laatste snelle poging om verbinding te maken met de oorspronkelijke partnernaam mogelijk is. Een verbindingspoging kan echter mislukken binnen minder dan de toegewezen herkansingstijd, vooral in latere rondes. Bijvoorbeeld, het ontvangen van een netwerkfout kan ertoe leiden dat een poging wordt beëindigd voordat de herkansingstijd is verstreken. Als eerdere pogingen mislukken door een netwerkfout, is er extra tijd beschikbaar voor de vierde ronde en mogelijk extra rondes.

Een andere oorzaak van een mislukte poging is een inactieve serverinstantie, zoals het geval is wanneer een serverinstantie bezig is met de failover van zijn database. In dit geval wordt een herpogingsvertraging opgelegd om te voorkomen dat klanten de partners overbelasten met een snelle opeenvolging van verbindingspogingen.

Vertragingen bij het opnieuw proberen tijdens failover

Als een client probeert verbinding te maken met een partner die bezig is met failover, antwoordt de partner onmiddellijk dat deze inactief is. In dit geval is elke ronde van verbindingspogingen veel korter dan de toegestane herkansingstijd. Dit betekent dat er veel rondes van verbindingspogingen kunnen plaatsvinden voordat de inlogperiode afloopt. Om te voorkomen dat de partners worden overbelast met een snelle reeks verbindingspogingen tijdens een failover, voegt de data-toegangsprovider na elke herkansingscyclus een korte herkansingsvertraging toe. De lengte van een gegeven retry-delay wordt bepaald door het retry-delay-algoritme. Na de eerste ronde is de vertraging 100 milliseconden. Na elk van de volgende drie pogingen verdubbelt de wachttijd tot respectievelijk 200, 400 en 800. Voor alle volgende pogingen is de wachttijd 1 seconde, totdat de verbindingspoging slaagt of er een time-out optreedt.

De volgende figuur illustreert hoe de herkansingsvertraging de verbindingspogingen beïnvloedt tijdens een handmatige failover, waarbij de partners van rol wisselen. De inlogtijd is 15 seconden.

Herverbinding maken met een database-spiegelingssessie

Als een gevestigde verbinding met een databasemirroringsessie om welke reden dan ook faalt, bijvoorbeeld door een databasemirroring-failover, en de applicatie probeert opnieuw verbinding te maken met de oorspronkelijke server, kan de data-toegangsprovider proberen opnieuw verbinding te maken met de failover-partnernaam die in de cache van de client is opgeslagen. Het opnieuw verbinden is echter niet automatisch. De applicatie moet zich bewust worden van de fout. Vervolgens moet de applicatie de mislukte verbinding sluiten en een nieuwe verbinding openen met dezelfde verbindingsreeks-attributen. Op dit punt leidt de data-toegangsprovider de verbinding door naar de failoverpartner. Als de serverinstantie die met deze naam wordt geïdentificeerd momenteel de hoofdserver is, slaagt de verbindingspoging meestal. Als het onduidelijk is of een transactie is gecommitteerd of teruggerold, moet de applicatie de status van de transactie controleren, op dezelfde manier als bij het opnieuw verbinden met een zelfstandige serverinstantie.

Het opnieuw verbinden lijkt op een initiële verbinding waarvoor de verbindingsreeks een failover-partnernaam heeft geleverd. Als de eerste verbindingspoging mislukt, wisselen de verbindingspogingen af tussen de oorspronkelijke partnernaam en de failoverpartnernaam totdat de client verbinding maakt met de hoofdserver of de data-toegangsprovider uitvalt.

Als de verbindingen TCP/IP gebruiken, bepaalt het verbindingsherkansingsalgoritme de hoeveelheid tijd die aan de verbindingspogingen in elke ronde wordt toegewezen.

Impact van omleiding op een cliëntapplicatie

Na een failover leidt de data-toegangsprovider de verbinding om naar de huidige hoofdserverinstantie. De omleiding is echter transparant voor klanten. Voor een client lijkt een omgeleide verbinding een verbinding te zijn met de serverinstantie die is geïdentificeerd door de oorspronkelijke partnernaam. Wanneer de initiële partner momenteel de mirrorserver is, kan de client lijken verbonden met de mirrorserver en de mirrordatabase bijwerken. In werkelijkheid is de client echter doorgestuurd naar de failover-partner, die de huidige hoofddatabase is, en de cliënt werkt de nieuwe hoofddatabase bij.

Na het doorverwijzen naar de failoverpartner kan een client onverwachte resultaten ervaren bij het gebruik van een Transact-SQL USE-instructie om een andere database te gebruiken. Dit kan gebeuren als de huidige hoofdserverinstantie (de failoverpartner) een andere set databases heeft dan de oorspronkelijke hoofdserver (de initiële partner).

De impact van een verouderde failover-partnernaam

De databasebeheerder kan op elk moment de failoverpartner wijzigen. Daarom kan een door de klant opgegeven naam van een failoverpartner verouderd of achterhaald zijn. Stel bijvoorbeeld een failoverpartner genaamd Partner_B die wordt vervangen door een andere serverinstantie, Partner_C. Als een klant Partner_B als failover-partner oplevert, is die naam verouderd. Wanneer de door de klant geleverde failover-partnernaam verouderd is, komt het gedrag van de data-toegangsprovider overeen met het geval waarin een failover-partnernaam niet door de client wordt opgegeven.

Beschouw bijvoorbeeld een situatie waarin een client één verbindingsreeks gebruikt voor een reeks van vier verbindingspogingen. In de verbindingsreeks is de initiële partnernaam Partner_A, en de failover-partnernaam Partner_B:

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

De volgende tabel toont vier partnerconfiguraties en geeft voor elke aan of deze verbindingsreeks werkt om de client voor het eerst te verbinden.

Verwante onderwerpen

• Databasespiegeling (SQL Server)
• Mogelijke fouten tijdens databasespiegeling