Freigeben über


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.

HinweisHinweis

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

    HinweisHinweis

    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

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.

    HinweisHinweis

    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.

HinweisHinweis

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.

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird[Nach oben]

Verwenden von Transact-SQL

So konfigurieren Sie schreibgeschütztes Routing

HinweisHinweis

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'))

      HinweisHinweis

      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

HinweisHinweis

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"

      HinweisHinweis

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

    HinweisHinweis

    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

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

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird[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.

TippTipp

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

So konfigurieren Sie den Clientverbindungszugriff

So verwenden Sie Verbindungszeichenfolgen in Anwendungen

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird[Nach oben]

Verwandte Inhalte

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird[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)