Konfigurieren des schreibgeschützten Routing für eine Verfügbarkeitsgruppe (SQL Server)

In SQL Server 2012 können Sie eine AlwaysOn-Verfügbarkeitsgruppe mit Transact-SQL oder mit 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ügbarkeitsgruppenlistener besitzen. Schreibgeschützte Clients müssen die eigenen Verbindungsanforderungen an diesen Listener weiterleiten, und in den Verbindungszeichenfolgen des Clients muss die Anwendungsabsicht als "schreibgeschützt" angeben sein. Es muss sich also um Verbindungsanforderungen für beabsichtigte Lesevorgänge handeln.

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

• Vorbereitungen:

  Voraussetzungen

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

  Sicherheit

• Konfigurieren des schreibgeschützten Routings mit:

  Transact-SQL

  PowerShell

  Hinweis
  Die Konfiguration von schreibgeschütztem Routing wird von SQL Server Management Studio nicht unterstützt.

• Nachverfolgung: Nach dem Konfigurieren von schreibgeschütztem Routing

• Verwandte Aufgaben

• Verwandte Inhalte

Vorbereitungen

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 Replikat ist). 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.

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 Routing angeben. 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 Routing angeben. 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 das erste verfügbare lesbare sekundäre Replikat auf der Liste für schreibgeschütztes Routing des aktuellen primären Replikats weitergeleitet. Es erfolgt kein Lastenausgleich.

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

Sicherheit

Berechtigungen

Aufgabe	Berechtigungen
So konfigurieren Sie Replikate beim Erstellen einer Verfügbarkeitsgruppe	Erfordert die Mitgliedschaft in der festen sysadmin-Serverrolle 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.

[Nach oben]

Verwenden von Transact-SQL

So konfigurieren Sie schreibgeschütztes Routing

Hinweis
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 CREATE AVAILABILITY GROUP-Anweisung von Transact-SQL. Verwenden Sie zum Hinzufügen oder Ändern eines Replikats für eine vorhandene Verfügbarkeitsgruppe die ALTER AVAILABILITY GROUP-Anweisung von Transact-SQL.

   • 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 vom Datenbankmodul 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.

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

Verwenden von PowerShell

So konfigurieren Sie schreibgeschütztes Routing

Hinweis
Ein Codebeispiel finden Sie weiter unten in diesem Abschnitt unter Beispiel (PowerShell).

1. Legen Sie den Standard (cd) auf die Serverinstanz fest, auf der das primäre Replikat gehostet wird.

2. Wenn Sie einer Verfügbarkeitsgruppe ein Verfügbarkeitsreplikat hinzufügen, verwenden Sie das New-SqlAvailabilityReplica-Cmdlet. Wenn Sie ein vorhandenes Verfügbarkeitsreplikat ändern, verwenden Sie das Set-SqlAvailabilityReplica-Cmdlet. Die relevanten Parameter lauten wie folgt:

   • Um schreibgeschütztes Routing für die sekundäre Rolle zu konfigurieren, geben Sie den ReadonlyRoutingConnectionUrl "url"-Parameter an.

     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 Verbindungszugriff für die primäre Rolle zu konfigurieren, geben Sie ReadonlyRoutingList "server" [ ,...n ], 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 Aufrufen der SQL Server PowerShell-Hilfe.

Einrichten und Verwenden des SQL Server PowerShell-Anbieters

• SQL Server PowerShell-Anbieter

• Aufrufen der SQL Server PowerShell-Hilfe

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 vom sekundären 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

[Nach oben]

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 von bcp (Hilfsprogramm) oder sqlcmd (Hilfsprogramm) können Sie den schreibgeschützten Zugriff für jedes sekundäre Replikat angeben, das den schreibgeschützten Zugriff unterstützt, indem Sie den -K ReadOnly-Schalter 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äß.

Verwandte Aufgaben

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

[Nach oben]

Verwandte Inhalte

• **Blogs: **

  Berechnen von read_only_routing_url für AlwaysOn

  SQL Server AlwaysOn-Teamblogs: Der offizielle SQL Server AlwaysOn-Teamblog

  CSS SQL Server-Technikblogs

• **Whitepaper: **

  Microsoft-Whitepapers für SQL Server 2012

  Whitepapers des SQL Server-Kundenberatungsteams

[Nach oben]

Siehe auch

Konzepte

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Aktive sekundäre Replikate: Lesbare sekundäre Replikate (AlwaysOn-Verfügbarkeitsgruppen)

Informationen zum Clientverbindungszugriff auf Verfügbarkeitsreplikate (SQL Server)

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