Konfigurieren des schreibgeschützten Routing für eine Always On-Verfügbarkeitsgruppe

Gilt für: SQL Server

In SQL Server können Sie eine Always On-Verfügbarkeitsgruppe mit Transact-SQL oder PowerShell für schreibgeschütztes Routing konfigurieren. Schreibgeschütztes Routing bezeichnet die Fähigkeit von SQL Server , schreibgeschützte Verbindungsanforderungen an ein verfügbares lesbares sekundäres AlwaysOn-Replikat weiterzuleiten (das heißt, an ein Replikat, das unter der sekundären Rolle für schreibgeschützte Arbeitsauslastungen konfiguriert ist). Um schreibgeschütztes Routing zu unterstützen, muss die Verfügbarkeitsgruppe einen Verfügbarkeitsgruppenlistenerbesitzen. Schreibgeschützte Clients müssen ihre Verbindungsanforderungen an diesen Listener senden, und in der Verbindungszeichenfolge des Clients muss die Anwendungsabsicht als „schreibgeschützt“ angegeben sein. Es muss sich also um Verbindungsanforderungen mit Leseabsicht handeln.

Schreibgeschütztes Routing ist in SQL Server 2016 (13.x) und höher verfügbar.

Hinweis

Informationen zum Konfigurieren eines lesbaren sekundären Replikats finden Sie unter Konfigurieren des schreibgeschützten Zugriffs auf ein Verfügbarkeitsreplikat (SQL Server).

Voraussetzungen

• Die Verfügbarkeitsgruppe muss über einen Verfügbarkeitsgruppenlistener verfügen. Weitere Informationen finden Sie unter Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server).

• Mindestens ein Verfügbarkeitsreplikat muss so konfiguriert werden, dass es in der sekundären Rolle schreibgeschützte Verbindungen akzeptiert (das heißt, ein lesbares sekundäres Replikatist). Weitere Informationen finden Sie unter Konfigurieren des schreibgeschützten Zugriffs auf ein Verfügbarkeitsreplikat (SQL Server).

• Sie müssen mit der Serverinstanz verbunden sein, auf der das aktuelle primäre Replikat gehostet wird.

• Wenn Sie eine SQL-Anmeldung verwenden, stellen Sie sicher, dass das Konto ordnungsgemäß konfiguriert ist. Weitere Informationen finden Sie unter Verwaltung von Anmeldungen und Aufträgen für die Datenbanken einer Verfügbarkeitsgruppe (SQL Server).

Welche Replikateigenschaften müssen Sie konfigurieren, um schreibgeschütztes Routing zu unterstützen?

• Für jedes lesbare sekundäre Replikat, das schreibgeschütztes Routing unterstützen soll, müssen Sie eine URL für schreibgeschütztes Routingangeben. Diese URL wird nur wirksam, wenn das lokale Replikat unter der sekundären Rolle ausgeführt wird. Die URL für schreibgeschütztes Routing muss nach Bedarf replikatweise angegeben werden. Jede URL für schreibgeschütztes Routing wird zum Weiterleiten von Verbindungsanforderungen für beabsichtigte Lesevorgänge an ein bestimmtes lesbares sekundäres Replikat verwendet. In der Regel wird jedem lesbaren sekundären Replikat eine URL für schreibgeschütztes Routing zugewiesen.

  Informationen zum Berechnen der schreibgeschützten Routing-URL für ein Verfügbarkeitsreplikat finden Sie unter Berechnen von read_only_routing_url für AlwaysOn

• Für jedes Verfügbarkeitsreplikat, das als primäres Replikat schreibgeschütztes Routing unterstützen soll, müssen Sie eine Liste für schreibgeschütztes Routingangeben. Eine Liste für schreibgeschütztes Routing wird nur wirksam, wenn das lokale Replikat unter der primären Rolle ausgeführt wird. Diese Liste muss nach Bedarf replikatweise angegeben werden. Normalerweise enthält jede Liste für schreibgeschütztes Routing jede URL für schreibgeschütztes Routing, wobei die URL des lokalen Replikats am Ende der Liste steht.

  Hinweis

  Verbindungsanforderungen für beabsichtigte Lesevorgänge werden an den ersten verfügbaren Eintrag auf der Liste für schreibgeschütztes Routing des aktuellen primären Replikats weitergeleitet. Lastenausgleich über schreibgeschützte Replikate hinweg wird allerdings unterstützt. Weitere Informationen finden Sie unter Konfigurieren von Lastenausgleich über schreibgeschützte Replikate hinweg.

Hinweis

Weitere Informationen zu Verfügbarkeitsgruppenlistenern und zum schreibgeschützten Routing finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server).

Berechtigungen

Aufgabe	Berechtigungen
So konfigurieren Sie Replikate beim Erstellen einer Verfügbarkeitsgruppe	Erfordert die Mitgliedschaft in der festen Serverrolle sysadmin und die CREATE AVAILABILITY GROUP-Serverberechtigung, ALTER ANY AVAILABILITY GROUP-Berechtigung oder CONTROL SERVER-Berechtigung.
So ändern Sie ein Verfügbarkeitsreplikat	Erfordert die ALTER AVAILABILITY GROUP-Berechtigung für die Verfügbarkeitsgruppe, die CONTROL AVAILABILITY GROUP-Berechtigung, die ALTER ANY AVAILABILITY GROUP-Berechtigung oder die CONTROL SERVER-Berechtigung.

Verwenden von Transact-SQL

Konfigurieren einer schreibgeschützten Routingliste

Verwenden Sie die folgenden Schritte, um schreibgeschütztes Routing mit Transact-SQL zu konfigurieren. Ein Codebeispiel finden Sie weiter unten in diesem Abschnitt unter Beispiel (Transact-SQL).

1. Stellen Sie eine Verbindung mit der Serverinstanz her, die das primäre Replikat hostet.

2. Wenn Sie ein Replikat für eine neue Verfügbarkeitsgruppe angeben, verwenden Sie die Transact-SQL-Anweisung CREATE AVAILABILITY GROUP. Verwenden Sie zum Hinzufügen oder Ändern eines Replikats für eine vorhandene Verfügbarkeitsgruppe die Transact-SQL-Anweisung ALTER AVAILABILITY GROUP.

   • Geben Sie zum Konfigurieren des schreibgeschützten Routings für die sekundäre Rolle in der ADD REPLICA- bzw. MODIFY REPLICA WITH-Klausel die SECONDARY_ROLE-Option wie folgt an:

     SECONDARY_ROLE ( READ_ONLY_ROUTING_URL ='TCP://system-address:port')

     Die URL für das schreibgeschützte Routing verfügt über die folgenden Parameter:

     system-address
     Ist eine Zeichenfolge, beispielsweise ein Systemname, ein vollqualifizierter Domänenname oder eine IP-Adresse, die das Zielcomputersystem eindeutig identifiziert.

     port
     Ist eine Portnummer, die von der Datenbank-Engine der SQL Server-Instanz verwendet wird.

     Beispiel: SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.contoso.com:1433')

     In einer MODIFY REPLICA-Klausel ist ALLOW_CONNECTIONS optional, wenn das Replikat bereits so konfiguriert worden ist, dass es schreibgeschützte Verbindungen zulässt.

     Weitere Informationen finden Sie unter Berechnen von read_only_routing_url für AlwaysOn.

   • Geben Sie zum Konfigurieren des schreibgeschützten Routings für die primäre Rolle in der ADD REPLICA- bzw. MODIFY REPLICA WITH-Klausel die PRIMARY_ROLE-Option wie folgt an:

     PRIMARY_ROLE ( READ_ONLY_ROUTING_LIST =('server' [ , ...n ] ))

     wobei server eine Serverinstanz identifiziert, die ein schreibgeschütztes sekundäres Replikat in der Verfügbarkeitsgruppe hostet.

     Beispiel: PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('Server1','Server2'))

     Hinweis

     Sie müssen die URL für das schreibgeschützte Routing festlegen, bevor Sie die schreibgeschützte Routingliste festlegen.

Konfigurieren von Lastenausgleich über schreibgeschützte Replikate hinweg

Ab SQL Server 2016 (13.x)können Sie den Lastenausgleich über eine Reihe von schreibgeschützten Replikaten hinweg konfigurieren. Zuvor wurde der Datenverkehr beim schreibgeschützten Routing an das erste verfügbare Replikat in der Routingliste geleitet. Um dieses Feature nutzen zu können, verwenden Sie eine Ebene geschachtelter Klammern um die READ_ONLY_ROUTING_LIST -Serverinstanzen der Befehle CREATE AVAILABILITY GROUP oder ALTER AVAILABILITY GROUP .

Die folgende Routingliste führt beispielsweise einen Lastenausgleich für Verbindungsanfragen mit Leseabsicht über zwei schreibgeschützte Replikate, Server1 und Server2, hinweg aus. Die geschachtelten Klammern, die diese Server umgeben, identifizieren den Satz mit Lastenausgleich. Wenn keines der Replikate in diesem Satz verfügbar ist, wird versucht, sequenziell eine Verbindung zu den anderen Replikaten ( Server3 und Server4) in der schreibgeschützten Routingliste herzustellen.

READ_ONLY_ROUTING_LIST = (('Server1','Server2'), 'Server3', 'Server4')  

Beachten Sie, dass jeder Eintrag in der Routingliste selbst ein Satz mit schreibgeschützten Lastenausgleichsreplikaten sein kann. Dies wird im folgenden Beispiel veranschaulicht:

READ_ONLY_ROUTING_LIST = (('Server1','Server2'), ('Server3', 'Server4', 'Server5'), 'Server6')  

Nur eine Ebene geschachtelter Klammern wird unterstützt.

Beispiel (Transact-SQL)

Im folgenden Beispiel werden zwei Verfügbarkeitsreplikate einer vorhandenen Verfügbarkeitsgruppe AG1 geändert, sodass schreibgeschütztes Routing unterstützt wird, wenn eines dieser Replikate die primäre Rolle besitzt. In diesem Beispiel werden die Instanznamen COMPUTER01 und COMPUTER02 zur Identifikation der Serverinstanzen angegeben, die das Verfügbarkeitsreplikat hosten.

ALTER AVAILABILITY GROUP [AG1]  
 MODIFY REPLICA ON  
N'COMPUTER01' WITH   
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));  
ALTER AVAILABILITY GROUP [AG1]  
 MODIFY REPLICA ON  
N'COMPUTER01' WITH   
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.contoso.com:1433'));  
  
ALTER AVAILABILITY GROUP [AG1]  
 MODIFY REPLICA ON  
N'COMPUTER02' WITH   
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));  
ALTER AVAILABILITY GROUP [AG1]  
 MODIFY REPLICA ON  
N'COMPUTER02' WITH   
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER02.contoso.com:1433'));  
  
ALTER AVAILABILITY GROUP [AG1]   
MODIFY REPLICA ON  
N'COMPUTER01' WITH   
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER02','COMPUTER01')));  
  
ALTER AVAILABILITY GROUP [AG1]   
MODIFY REPLICA ON  
N'COMPUTER02' WITH   
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02')));  
GO  
  

PowerShell

Konfigurieren einer schreibgeschützten Routingliste

Verwenden Sie die folgenden Schritte, um schreibgeschütztes Routing mit PowerShell zu konfigurieren. Ein Codebeispiel finden Sie weiter unten in diesem Abschnitt unter Beispiel (PowerShell).

1. Legen Sie mit (cd) die Serverinstanz als Standard fest, die das primäre Replikat hostet.

2. Verwenden Sie zum Hinzufügen eines Verfügbarkeitsreplikats zu einer Verfügbarkeitsgruppe das Cmdlet New-SqlAvailabilityReplica . Verwenden Sie zum Ändern eines vorhandenen Verfügbarkeitsreplikats das Cmdlet Set-SqlAvailabilityReplica . Die relevanten Parameter lauten wie folgt:

   • Um das schreibgeschützte Routing für die sekundäre Rolle zu konfigurieren, legen Sie den Parameter ReadonlyRoutingConnectionUrl"url" fest.

     wobei url für den vollqualifizierten Domänennamen (FQDN) und Port der Verbindung steht, die beim Routing zum Replikat für schreibgeschützte Verbindungen verwendet werden. Beispiel: -ReadonlyRoutingConnectionUrl "TCP://DBSERVER8.manufacturing.Adventure-Works.com:7024"

     Weitere Informationen finden Sie unter Berechnen von read_only_routing_url für AlwaysOn.

   • Um den Verbindungszugriff für die primäre Rolle zu konfigurieren, geben Sie ReadonlyRoutingList"server" [ , ...n ] an, wobei server eine Serverinstanz identifiziert, die in der Verfügbarkeitsgruppe ein schreibgeschütztes sekundäres Replikat hostet. Beispiel: -ReadOnlyRoutingList "SecondaryServer","PrimaryServer"

     Hinweis

     Sie müssen die URL für das schreibgeschützte Routing für ein Replikat festlegen, bevor Sie dessen schreibgeschützte Routingliste festlegen.

   Hinweis

   Um die Syntax eines Cmdlets anzuzeigen, verwenden Sie das Get-Help -Cmdlet in der SQL Server PowerShell-Umgebung. Weitere Informationen finden Sie unter Get Help SQL Server PowerShell.

Einrichten und Verwenden des SQL Server PowerShell-Anbieters

• SQL Server PowerShell-Anbieter

• Get Help SQL Server PowerShell

Beispiel (PowerShell)

Im folgenden Beispiel werden das primäre Replikat und ein sekundäres Replikat in einer Verfügbarkeitsgruppe für das schreibgeschützte Routing konfiguriert. Im Beispiel wird zuerst jedem Replikat eine URL für das schreibgeschützte Routing zugewiesen. Anschließend wird die Liste für schreibgeschütztes Routing auf dem primären Replikat festgelegt. Verbindungen, für die in der Verbindungszeichenfolge die ReadOnly-Eigenschaft festgelegt wurde, werden an das sekundäre Replikat umgeleitet. Wenn dieses sekundäre Replikat nicht gelesen werden kann (durch die ConnectionModeInSecondaryRole -Einstellung vorgegeben), wird die Verbindung wiederum zurück an das primäre Replikat geleitet.

Set-Location SQLSERVER:\SQL\PrimaryServer\default\AvailabilityGroups\MyAg  
$primaryReplica = Get-Item "AvailabilityReplicas\PrimaryServer"  
$secondaryReplica = Get-Item "AvailabilityReplicas\SecondaryServer"  
  
Set-SqlAvailabilityReplica -ReadOnlyRoutingConnectionUrl "TCP://PrimaryServer.domain.com:1433" -InputObject $primaryReplica  
Set-SqlAvailabilityReplica -ReadOnlyRoutingConnectionUrl "TCP://SecondaryServer.domain.com:1433" -InputObject $secondaryReplica  
Set-SqlAvailabilityReplica -ReadOnlyRoutingList "SecondaryServer","PrimaryServer" -InputObject $primaryReplica  

Nachverfolgung: Nach dem Konfigurieren von schreibgeschütztem Routing

Sobald das aktuelle primäre Replikat und die lesbaren sekundären Replikate konfiguriert worden sind, sodass sie schreibgeschütztes Routing in beiden Rollen unterstützen, können die lesbaren sekundären Replikate Anforderungen für Leseverbindungen von Clients empfangen, die über den Verfügbarkeitsgruppenlistener eine Verbindung herstellen.

Tipp

Bei Verwendung der Hilfsprogramme bcp oder sqlcmdkönnen Sie den schreibgeschützten Zugriff für jedes sekundäre Replikat angeben, das den schreibgeschützten Zugriff unterstützt, indem Sie den Switch -K ReadOnly angeben.

Anforderungen und Empfehlungen für Clientverbindungszeichenfolgen

Damit eine Clientanwendung schreibgeschütztes Routing verwendet, muss seine Verbindungszeichenfolge die folgenden Anforderungen erfüllen:

• Verwendung des TCP-Protokolls.

• Festlegen des Attributs bzw. der Eigenschaft für die Anwendungsabsicht auf schreibgeschützt

• Verweis auf den Listener einer Verfügbarkeitsgruppe, der zur Unterstützung des schreibgeschützten Routing konfiguriert worden ist.

• Verweis auf eine Datenbank in dieser Verfügbarkeitsgruppennamen.

Außerdem empfiehlt es sich, dass Verbindungszeichenfolgen Multisubnetzfailover aktivieren, das in jedem Subnetz einen parallelen Clientthread für jedes Replikat unterstützt. Dadurch wird die Zeitspanne minimiert, die nach einem Failover zum Wiederherstellen der Verbindung mit dem Client erforderlich ist.

Die Syntax für eine Verbindungszeichenfolge hängt vom SQL Server-Anbieter ab, den eine Anwendung verwendet. Die folgende Beispielverbindungszeichenfolge für den .NET Framework-Datenanbieter 4.0.2 für SQL Server veranschaulicht die Teile einer Verbindungszeichenfolge, die für schreibgeschütztes Routing erforderlich und empfohlen sind.

Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True  

Weitere Informationen zur schreibgeschützten Anwendungsabsicht und zum schreibgeschützten Routing finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server).

Wenn schreibgeschütztes Routing nicht ordnungsgemäß funktioniert

Informationen zum Durchführen einer Problembehandlung an einer schreibgeschützten Routingkonfiguration finden Sie unter Schreibgeschütztes Routing funktioniert nicht ordnungsgemäß.

Nächste Schritte

So zeigen Sie schreibgeschützte Routingkonfigurationen an

• sys.availability_read_only_routing_lists (Transact-SQL)

• sys.availability_replicas (Transact-SQL) (Spalte read_only_routing_url)

So konfigurieren Sie den Clientverbindungszugriff

• Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server)

• Konfigurieren des schreibgeschützten Zugriffs auf ein Verfügbarkeitsreplikat (SQL Server)

So verwenden Sie Verbindungszeichenfolgen in Anwendungen

• SQL Server Native Client-Unterstützung für hohe Verfügbarkeit, Notfallwiederherstellung

• Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit SQL Server Native Client

Blogs:

• Berechnen von „read_only_routing_url“ für AlwaysOn

• SQL Server Always On Team Blogs: The official SQL Server Always On Team Blog (SQL Server Always On-Teamblogs: Der offizielle SQL Server Always On-Teamblog)

• CSS SQL Server-Technikblogs

Whitepaper:

• Whitepapers des SQL Server-Kundenberatungsteams

Zusätzliche Inhalte

• Übersicht über Always On-Verfügbarkeitsgruppen (SQL Server)

• Aktive sekundäre Replikate: Lesbare sekundäre Replikate (Always On-Verfügbarkeitsgruppen)

• Informationen zum Clientverbindungszugriff auf Verfügbarkeitsreplikate (SQL Server)

• Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server)