Umleitung von Lese-/Schreibverbindungen vom sekundären an das primäre Replikat (Always On-Verfügbarkeitsgruppen)

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 NONE sind 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_ROLE muss READ_WRITE_ROUTING_URL enthalten.
  • Die Verbindungszeichenfolge muss auf ReadWrite festgelegt werden, indem ApplicationIntent als ReadWrite definiert wird oder indem ApplicationIntent nicht festgelegt wird, sodass standardmäßig ReadWrite verwendet 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=ReadWrite
Standard
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=ReadWrite
Standard
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.

Verfügbarkeitsgruppe mit primärem, sekundärem und asynchronem sekundärem Replikat

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.

Verbindungsverhalten

Im folgenden Diagramm stellt eine Clientanwendung mit ApplicationIntent=ReadWrite eine Verbindung mit COMPUTER02 her. Die Verbindung wird an das primäre Replikat umgeleitet.

Die Verbindung zu Computer 2 wird wieder zum primären Replikat weitergeleitet.

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.

Die Verbindung wird zum neuen primären Replikat auf Computer 2 weitergeleitet.

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)