Typen clientverbindingen met replica's binnen een AlwaysOn-beschikbaarheidsgroep

Van toepassing op:SQL Server

In een AlwaysOn-beschikbaarheidsgroep kunt u een of meer beschikbaarheidsreplica's configureren om alleen-lezenverbindingen toe te staan wanneer ze worden uitgevoerd onder de secundaire rol (dat wil gezegd, wanneer ze als secundaire replica worden uitgevoerd). U kunt ook elke beschikbaarheidsreplica configureren om read-only-verbindingen toe te staan of uit te sluiten wanneer het als primaire replica fungeert (dat wil zeggen, wanneer het fungeert als de primaire replica).

Als u clienttoegang tot primaire of secundaire databases van een bepaalde beschikbaarheidsgroep wilt vergemakkelijken, moet u een listener voor beschikbaarheidsgroepen definiëren. De listener van de beschikbaarheidsgroep stuurt standaard binnenkomende verbindingen naar de primaire replica. U kunt echter een beschikbaarheidsgroep configureren ter ondersteuning van alleen-lezenroutering, waardoor de listener van de beschikbaarheidsgroep de verbindingsaanvragen van leesintentietoepassingen kan omleiden naar een leesbare secundaire replica. Zie Read-Only Routering configureren voor een beschikbaarheidsgroep (SQL Server) voor meer informatie.

Tijdens een failover gaat een secundaire replica over naar de primaire rol en de voormalige primaire replica over naar de secundaire rol. Tijdens het failoverproces worden alle clientverbindingen met zowel de primaire replica als de secundaire replica beëindigd. Na de failover, wanneer een client opnieuw verbinding maakt met de listener van de beschikbaarheidsgroep, verbindt de listener de client opnieuw met de nieuwe primaire replica, behalve bij een verbindingsverzoek met leesintentie. Als alleen-lezenroutering is geconfigureerd op de client en op de serverexemplaren die de nieuwe primaire replica hosten en op ten minste één leesbare secundaire replica, worden verbindingen met leesintentie opnieuw gerouteerd naar een secundaire replica die ondersteuning biedt voor het type toegang dat de client nodig heeft. Om een goede clientervaring na een failover te garanderen, is het belangrijk om verbindingstoegang te configureren voor zowel de secundaire als de primaire rollen van elke beschikbaarheidsreplica.

Typen verbindingstoegang die wordt ondersteund door de secundaire rol

De secundaire rol ondersteunt als volgt drie alternatieven voor clientverbindingen:

Geen verbindingen
Er zijn geen gebruikersverbindingen toegestaan. Secundaire databases zijn niet beschikbaar voor leestoegang. Dit is het standaardgedrag in de secundaire rol.

Alleen leesintentieverbindingen
De secundaire database(s) zijn alleen beschikbaar voor verbindingen waarvoor de eigenschap Application Intent connection is ingesteld op ReadOnly (read-intent connections).

Zie SQL Server Native Client Support voor hoge beschikbaarheid, herstel na noodgevallen voor meer informatie over deze verbindingseigen eigenschap.

Een alleen-lezen-verbinding toestaan
De secundaire database(s) zijn allemaal beschikbaar voor leestoegangsverbindingen. Met deze optie kunnen clienten met een lagere versie een verbinding maken.

Zie Read-Only-toegang configureren op een beschikbaarheidsreplica (SQL Server) voor meer informatie.

Typen verbindingstoegang die worden ondersteund door de primaire rol

De primaire rol ondersteunt als volgt twee alternatieven voor clientverbindingen:

Alle verbindingen zijn toegestaan
Zowel lezen-schrijven- als alleen-lezenverbindingen zijn toegestaan voor primaire databases. Dit is het standaardgedrag voor de primaire rol.

Alleen lees-/schrijfverbindingen toestaan
Wanneer de verbindingseigenschap Toepassingsintentie is ingesteld op ReadWrite of niet is ingesteld, is de verbinding toegestaan. Verbindingen waarvoor het trefwoord verbindingsreeks voor de toepassingsintentie is ingesteld op ReadOnly , zijn niet toegestaan. Het uitsluitend toestaan van lees-/schrijfverbindingen kan helpen voorkomen dat uw klanten per ongeluk een workload met leesintentie aan de primaire replica koppelen.

Zie Trefwoorden voor verbindingsreeksen gebruiken met SQL Server Native Client voor meer informatie over deze verbindingseigen eigenschap.

Zie Read-Only-toegang configureren op een beschikbaarheidsreplica (SQL Server) voor meer informatie.

Hoe de verbindingstoegangsconfiguratie van invloed is op clientconnectiviteit

De verbindingstoegangsinstellingen van een replica bepalen of een verbindingspoging mislukt of slaagt. De volgende tabel geeft een overzicht van of een bepaalde verbindingspoging slaagt of mislukt voor elke instelling voor verbindingstoegang.

Zie Listeners voor beschikbaarheidsgroepen, clientconnectiviteit en toepassingsfailover (SQL Server) voor informatie over het configureren van een beschikbaarheidsgroep om clientverbindingen naar de replica's toe te accepteren.

Voorbeeld van Connection-Access configuratie

Afhankelijk van hoe verschillende beschikbaarheidsreplica's zijn geconfigureerd voor verbindingstoegang, kan de ondersteuning voor clientverbindingen veranderen nadat een failover van een beschikbaarheidsgroep is uitgevoerd. Denk bijvoorbeeld aan een beschikbaarheidsgroep waarvoor rapportage wordt uitgevoerd met asynchrone commit op externe secundaire replica's. Alle alleen-lezen applicaties voor de databases in deze beschikbaarheidsgroep stellen hun verbindingseigenschap toepassingsintentie in op ReadOnly, zodat alle alleen-lezenverbindingen leesintentieverbindingen zijn.

Deze voorbeeldbeschikbaarheidsgroep beschikt over twee synchrone doorvoerreplica's in het belangrijkste rekencentrum en twee asynchrone doorvoerreplica's op een satellietlocatie. Voor de primaire rol worden alle replica's geconfigureerd voor lees-schrijftoegang, waardoor leesintentieverbindingen met de primaire replica in alle situaties worden voorkomen. De secundaire rol van de synchrone commit maakt gebruik van de standaardverbindingstoegangconfiguratie (geen), waardoor alle clientverbindingen in de secundaire rol worden geblokkeerd. De asynchrone commitreplica's zijn daarentegen geconfigureerd om leesintentieverbindingen in de secundaire rol toe te staan. De volgende tabel bevat een overzicht van deze voorbeeldconfiguratie:

Normaal gesproken vinden in dit voorbeeldscenario failovers alleen plaats tussen de synchrone doorvoerreplica's en kunnen toepassingen met leesintentie direct na de failover opnieuw verbinding maken met een van de secundaire replica's met asynchrone doorvoer. Echter, wanneer er een ramp optreedt bij het hoofdcomputingscentrum, gaan beide synchronous-commit replica's verloren. De databasebeheerder op de satellietsite reageert door een geforceerde handmatige failover uit te voeren naar een secundaire replica met asynchroon commit. De secundaire databases op de resterende secundaire replica worden opgeschort door de geforceerde failover, waardoor ze niet beschikbaar zijn voor alleen-lezen workloads. De nieuwe primaire replica, die is geconfigureerd voor lees- en schrijfverbindingen, voorkomt dat de leesintentie-workload concurreert met de lees- en schrijfworkload. Dit betekent dat totdat de databasebeheerder de secundaire databases hervat op de resterende secundaire replica met asynchrone-commit, leesgeoriënteerde clients geen verbinding kunnen maken met een beschikbaarheidsreplica.

Gerelateerde taken

• Read-Only-toegang configureren op een beschikbaarheidsreplica in SQL Server

• Read-Only routing configureren voor een beschikbaarheidsgroep (SQL Server)

• Beschikbaarheidsgroepen (Transact-SQL) controleren

• Eigenschappen van beschikbaarheidsreplica (SQL Server) weergeven

• Het dialoogvenster Nieuwe beschikbaarheidsgroep gebruiken (SQL Server Management Studio)

Verwante inhoud

• Microsoft SQL Server AlwaysOn-oplossingengids voor hoge beschikbaarheid en herstel na noodgevallen

• SQL Server AlwaysOn-teamblog: de officiële SQL Server Always On-teamblog

Zie ook

overzicht van AlwaysOn-beschikbaarheidsgroepen (SQL Server)
Listeners voor Beschikbaarheidsgroepen, Clientconnectiviteit en Toepassingsfailover (SQL Server)
statistieken