Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für: SQL Server 2019 (15.x) und höher
SQL Server 2019 (15.x) führt die Umleitung von Lese-/Schreibverbindungen von sekundären zu primären Replikaten für Always On-Verfügbarkeitsgruppen ein. Die Umleitung von Lese-/Schreibverbindungen ist auf jeder Betriebssystemplattform verfügbar. Durch dieses Feature können Clientanwendungsverbindungen zum primären Replikat weitergeleitet werden, unabhängig davon, ob der Zielserver in der Verbindungszeichenfolge angegeben ist.
In der Verbindungszeichenfolge kann beispielsweise ein sekundäres Replikat als Ziel angegeben sein. Je nach Konfiguration des Verfügbarkeitsgruppenreplikats und den Einstellungen in der Verbindungszeichenfolge kann die Verbindung automatisch an das primäre Replikat umgeleitet werden.
Anwendungsfälle
Vor SQL Server 2019 (15.x) leiten der AG-Listener und die entsprechende Clusterressource den Benutzerdatenverkehr an das primäre Replikat weiter, um die erneute Verbindung nach einem Failover sicherzustellen. SQL Server 2019 (15.x) unterstützt weiterhin die AG-Listenerfunktion und führt die Umleitung von Replikatverbindungen für Szenarien ein, die keinen Listener enthalten können. Beispiel:
- Die Clustertechnologie, in die SQL Server-Verfügbarkeitsgruppen integriert sind, bietet keine Funktion, die einem Listener ähnelt.
- Eine Konfiguration mit mehreren Subnetzen wie z.B. die Cloud oder Floating IP mit Pacemaker mit mehreren Subnetzen – solche Konfigurationen können aufgrund der Menge an beteiligten Komponenten sehr komplex, fehleranfällig und schwer zu korrigieren sein.
- Leseskalierung, Notfallwiederherstellung oder der Clustertyp
NONEsind nicht möglich, da es keinen einfachen Mechanismus gibt, um nach einem manuellen Failover eine transparente Neuverbindung sicherzustellen.
Anforderung
Damit ein sekundäres Replikat Lese-/Schreibverbindungsanforderungen umleiten kann, müssen folgende Voraussetzungen erfüllt sein:
- Das sekundäre Replikat muss online sein.
- Die Replikatspezifikation
PRIMARY_ROLEmussREAD_WRITE_ROUTING_URLenthalten. - Die Verbindungszeichenfolge muss auf
ReadWritefestgelegt werden, indemApplicationIntentalsReadWritedefiniert wird oder indemApplicationIntentnicht festgelegt wird, sodass standardmäßigReadWriteverwendet wird.
Festlegen der READ_WRITE_ROUTING_URL-Option
Um die Umleitung von Lese-/Schreibverbindungen zu konfigurieren, legen Sie beim Erstellen der Verfügbarkeitsgruppe für das primäre Replikat READ_WRITE_ROUTING_URL fest.
In SQL Server 2019 (15.x) wurde READ_WRITE_ROUTING_URL zur <add_replica_option>-Spezifikation hinzugefügt. Weitere Informationen finden Sie in den folgenden Artikeln:
PRIMARY_ROLE(READ_WRITE_ROUTING_URL) nicht festgelegt (Standardeinstellung)
Standardmäßig ist die Umleitung von Lese-/Schreibverbindungen für ein Replikat nicht konfiguriert. Wie ein sekundäres Replikat Verbindungsanforderungen behandelt, richtet sich danach, ob das Zulassen von Verbindungen für das sekundäre Replikat festgelegt ist, und nach den ApplicationIntent-Einstellung in der Verbindungszeichenfolge. Die folgende Tabelle zeigt, wie ein sekundäres Replikat basierend auf SECONDARY_ROLE (ALLOW CONNECTIONS = ) und ApplicationIntent Verbindungen behandelt.
ApplicationIntent Wert |
SECONDARY_ROLE (ALLOW CONNECTIONS = NO) |
SECONDARY_ROLE (ALLOW CONNECTIONS = READ_ONLY) |
SECONDARY_ROLE (ALLOW CONNECTIONS = ALL) |
|---|---|---|---|
ApplicationIntent=ReadWriteStandard |
Verbindungen werden nicht hergestellt | Verbindungen werden nicht hergestellt | Verbindungen werden erfolgreich hergestellt Lesevorgänge erfolgreich Schreibvorgänge schlagen fehl |
ApplicationIntent=ReadOnly |
Verbindungen werden nicht hergestellt | Verbindungen werden erfolgreich hergestellt | Verbindungen werden erfolgreich hergestellt |
Die vorhergehende Tabelle zeigt das Standardverhalten, das mit dem von SQL Server-Versionen vor SQL Server 2019 (15.x) identisch ist.
PRIMARY_ROLE(READ_WRITE_ROUTING_URL) gesetzt
Nachdem Sie die Umleitung von Lese-/Schreibverbindungen festgelegt haben, behandelt das Replikat Verbindungsanforderungen anders. Das Verbindungsverhalten richtet sich weiterhin nach den Einstellungen für SECONDARY_ROLE (ALLOW CONNECTIONS = ) und ApplicationIntent. Die folgende Tabelle zeigt, wie ein sekundäres Replikat, bei dem READ_WRITE_ROUTING festgelegt ist, Verbindungen basierend auf SECONDARY_ROLE (ALLOW CONNECTIONS = ) und ApplicationIntent behandelt.
ApplicationIntent-Wert |
SECONDARY_ROLE (ALLOW CONNECTIONS = NO) |
SECONDARY_ROLE (ALLOW CONNECTIONS = READ_ONLY) |
SECONDARY_ROLE (ALLOW CONNECTIONS = ALL) |
|---|---|---|---|
ApplicationIntent=ReadWriteStandard |
Verbindungen werden nicht hergestellt | Verbindungen werden nicht hergestellt | Verbindungen werden an die primäre Instanz weitergeleitet |
ApplicationIntent=ReadOnly |
Verbindungen werden nicht hergestellt | Verbindungen werden erfolgreich hergestellt | Verbindungen werden erfolgreich hergestellt |
Die oben stehende Tabelle zeigt Folgendes: Bei festgelegter READ_WRITE_ROUTING_URL-Option für das primäre Replikat leitet das sekundäre Replikat Verbindungen an das primäre Replikat um, wenn SECONDARY_ROLE (ALLOW CONNECTIONS = ALL) festgelegt ist. Die Verbindung gibt ReadWrite an.
Wiederherstellen des Standardroutingverhaltens
Ab SQL Server 2025 (17.x) können Sie NONE als READ_WRITE_ROUTING_URL oder READ_ONLY_ROUTING_URL Ziel angeben, um das angegebene Routing für das Verfügbarkeitsreplikat rückgängig zu machen und den Datenverkehr basierend auf dem Standardverhalten weiterzuleiten. Weitere Informationen finden Sie unter ALTER AVAILABILITY GROUP Transact-SQL Befehl.
Beispiel
In diesem Beispiel weist die Verfügbarkeitsgruppe drei Replikat auf:
- Ein primäres Replikat auf COMPUTER01
- Ein synchrones sekundäres Replikat auf COMPUTER02
- Ein asynchrones sekundäres Replikat auf COMPUTER03
Die folgende Abbildung zeigt die Verfügbarkeitsgruppe.
Das folgende Transact-SQL-Skript erstellt diese Verfügbarkeitsgruppe. In diesem Beispiel gibt jedes Replikat die READ_WRITE_ROUTING_URL an.
CREATE AVAILABILITY GROUP MyAg
WITH ( CLUSTER_TYPE = NONE )
FOR
DATABASE [<Database1>]
REPLICA ON
'COMPUTER01' WITH
(
ENDPOINT_URL = 'TCP://COMPUTER01.<domain>.<tld>:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL,
READ_ONLY_ROUTING_URL = 'TCP://COMPUTER01.<domain>.<tld>:1433' ),
PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE,
READ_ONLY_ROUTING_LIST = ('COMPUTER02', 'COMPUTER03'),
READ_WRITE_ROUTING_URL = 'TCP://COMPUTER01.<domain>.<tld>:1433' ),
SESSION_TIMEOUT = 10
),
'COMPUTER02' WITH
(
ENDPOINT_URL = 'TCP://COMPUTER02.<domain>.<tld>:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL,
READ_ONLY_ROUTING_URL = 'TCP://COMPUTER02.<domain>.<tld>:1433' ),
PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE,
READ_ONLY_ROUTING_LIST = ('COMPUTER01', 'COMPUTER03'),
READ_WRITE_ROUTING_URL = 'TCP://COMPUTER02.<domain>.<tld>:1433' ),
SESSION_TIMEOUT = 10
),
'COMPUTER03' WITH
(
ENDPOINT_URL = 'TCP://COMPUTER03.<domain>.<tld>:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL,
READ_ONLY_ROUTING_URL = 'TCP://COMPUTER03.<domain>.<tld>:1433' ),
PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE,
READ_ONLY_ROUTING_LIST = ('COMPUTER01', 'COMPUTER02'),
READ_WRITE_ROUTING_URL = 'TCP://COMPUTER03.<domain>.<tld>:1433' ),
SESSION_TIMEOUT = 10
);
GO
<domain>.<tld>- Domäne und Top-Level-Domäne des vollqualifizierten Domänennamens. Beispiel:
corporation.com.
- Domäne und Top-Level-Domäne des vollqualifizierten Domänennamens. Beispiel:
Verbindungsverhalten
Im folgenden Diagramm stellt eine Clientanwendung mit ApplicationIntent=ReadWrite eine Verbindung mit COMPUTER02 her. Die Verbindung wird an das primäre Replikat umgeleitet.
Das sekundäre Replikat leitet Lese-/Schreibaufrufe an das primäre Replikat um. Eine Lese-/Schreibverbindung mit jedem der beiden Replikate wird zum primären Replikat umgeleitet.
Im folgenden Diagramm wurde ein manuelles Failover des primären Replikats auf COMPUTER02 durchgeführt. Eine Clientanwendung stellt mit ApplicationIntent=ReadWrite eine Verbindung mit COMPUTER01 her. Die Verbindung wird an das primäre Replikat umgeleitet.
Siehe auch
Übersicht über Always On-Verfügbarkeitsgruppen (SQL Server)
Informationen zum Clientverbindungszugriff auf Verfügbarkeitsreplikate (SQL Server)
Verfügbarkeitsgruppenlistener, Clientverbindungen und Anwendungsfailover (SQL Server)