Konfigurieren des schreibgeschützten Routing für eine Verfügbarkeitsgruppe (SQL Server)
Zum Konfigurieren einer AlwaysOn-Verfügbarkeitsgruppe zur Unterstützung des schreibgeschützten Routings in SQL Server 2014 können Sie entweder Transact-SQL oder PowerShell verwenden. Schreibgeschütztes Routing bezieht sich auf die Fähigkeit von SQL Server, qualifizierende schreibgeschützte Verbindungsanforderungen an ein verfügbares, lesbares sekundäres AlwaysOn-Replikat weiterzuleiten (d. a. ein Replikat, das für schreibgeschützte Workloads konfiguriert ist, wenn sie unter der sekundären Rolle ausgeführt werden). 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.
Hinweis
Informationen zum Konfigurieren eines lesbaren sekundären Replikats finden Sie unter Konfigurieren des schreibgeschützten Zugriffs auf ein Verfügbarkeitsreplikat (SQL Server).
Hinweis
Das Konfigurieren des schreibgeschützten Routings wird von SQL Server Management Studio nicht unterstützt.
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 schreibgeschützt in der sekundären Rolle akzeptiert (d. a . um sekundäre Replikate lesbar zu sein (AlwaysOn%20Availability%20Groups).md)). 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 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 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 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
So konfigurieren Sie schreibgeschütztes Routing
Hinweis
Ein Codebeispiel finden Sie weiter unten in diesem Abschnitt unter Beispiel (Transact-SQL).
Stellen Sie eine Verbindung mit der Serverinstanz her, die das primäre Replikat hostet.
Wenn Sie ein Replikat für eine neue Verfügbarkeitsgruppe angeben, verwenden Sie die Transact-SQL-Anweisung CREATE AVAILABILITY GROUP. Wenn Sie ein Replikat für eine vorhandene Verfügbarkeitsgruppe hinzufügen oder ändern, verwenden Sie die ALTER AVAILABILITY GROUPTransact-SQL-Anweisung.
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.
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
So konfigurieren Sie schreibgeschütztes Routing
Hinweis
Ein Codebeispiel finden Sie weiter unten in diesem Abschnitt unter Beispiel (PowerShell).
Legen Sie den Standard (
cd
) auf die Serverinstanz fest, auf der das primäre Replikat gehostet wird.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 dasSet-SqlAvailabilityReplica
-Cmdlet. Die relevanten Parameter lauten wie folgt:Geben Sie zum Konfigurieren des schreibgeschützten Routings für die sekundäre Rolle den Parameter ReadonlyRoutingConnectionUrl"
url
" 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 den Verbindungszugriff für die primäre Rolle zu konfigurieren, geben Sie ReadonlyRoutingList"
server
" [ ,... an. n ], wobei der Server einen Server instance identifiziert, der ein schreibgeschütztes sekundäres Replikat in der Verfügbarkeitsgruppe 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
Verwenden Sie das Cmdlet in der SQL Server PowerShell-Umgebung, um die
Get-Help
Syntax eines Cmdlets anzuzeigen. Weitere Informationen finden Sie unter Get Help SQL Server PowerShell.
Informationen zum Einrichten und Verwenden des SQL Server PowerShell-Anbieters finden Sie unter SQL Server PowerShell-Anbieter und Hilfe 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 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
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
Wenn Sie das Hilfsprogramm bcp oder sqlcmd verwenden, können Sie den schreibgeschützten Zugriff auf jedes sekundäre Replikat angeben, das für schreibgeschützten Zugriff aktiviert ist, indem Sie den -K ReadOnly
Switch 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äß.
Related Tasks
So zeigen Sie schreibgeschützte Routingkonfigurationen an
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
Verwandte Inhalte
Blogs:
Berechnen von read_only_routing_url für AlwaysOn
SQL Server AlwaysOn-Teamblogs: Der offizielle SQL Server AlwaysOn-Teamblog
Whitepaper:
Weitere Informationen
Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)
Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)
Aktive sekundäre Replikate: Auslagern von schreibgeschützten Arbeitsauslastungen auf ein sekundäres Replikat einer Always On-Verfügbarkeitsgruppe
Informationen zum Clientverbindungszugriff auf Verfügbarkeitsreplikate (SQL Server)
Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server)