Konfigurieren Sie schreibgeschütztes Routing in einer AlwaysOn-Verfügbarkeitsgruppe unter Server on SQL AWS - AWS Prescriptive Guidance

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Konfigurieren Sie schreibgeschütztes Routing in einer AlwaysOn-Verfügbarkeitsgruppe unter Server on SQL AWS

Erstellt von Subhani Shaik () AWS

Umgebung: PoC oder Pilotprojekt

Technologien: Datenbanken; Infrastruktur

Arbeitslast: Microsoft

AWSDienste: AWS Verwaltetes Microsoft AD; Amazon EC2

Übersicht

Dieses Muster beschreibt, wie das sekundäre Standby-Replikat in SQL Server Always On verwendet wird, indem die schreibgeschützten Workloads vom primären Replikat auf das sekundäre Replikat verlagert werden.

Die Datenbankspiegelung verfügt über eine Zuordnung. one-to-one Sie können die sekundäre Datenbank nicht direkt lesen, daher müssen Sie Snapshots erstellen. Die Always-On-Verfügbarkeitsgruppenfunktion wurde in Microsoft SQL Server 2012 eingeführt. In späteren Versionen wurden wichtige Funktionen eingeführt, darunter schreibgeschütztes Routing. In Always-On-Verfügbarkeitsgruppen können Sie die Daten direkt aus dem sekundären Replikat lesen, indem Sie den Replikatmodus auf Schreibgeschützt ändern.

Die Always-On-Lösung für Verfügbarkeitsgruppen unterstützt Hochverfügbarkeit (HA), Notfallwiederherstellung (DR) und ist eine Alternative zur Datenbankspiegelung. Always-On-Verfügbarkeitsgruppen arbeiten auf Datenbankebene und maximieren die Verfügbarkeit einer Reihe von Benutzerdatenbanken.

SQLDer Server verwendet den Nur-Lese-Routing-Mechanismus, um die eingehenden schreibgeschützten Verbindungen an das sekundäre Lesereplikat umzuleiten. Um dies zu erreichen, sollten Sie der Verbindungszeichenfolge die folgenden Parameter und Werte hinzufügen:

  • ApplicationIntent=ReadOnly

  • Initial Catalog=<database name>

Voraussetzungen und Einschränkungen

Voraussetzungen

  • Ein aktives AWS Konto mit einer virtuellen privaten Cloud (VPC), zwei Availability Zones, privaten Subnetzen und einer Sicherheitsgruppe

  • Zwei Amazon Elastic Compute Cloud (AmazonEC2) -Maschinen mit SQLServer 2019 Enterprise Edition Amazon Machine Image with Windows Server Failover Clustering (WSFC), die auf Instanzebene konfiguriert sind, und einer Always-On-Verfügbarkeitsgruppe, die auf SQL Serverebene zwischen dem primären Knoten (WSFCNODE1) und dem sekundären Knoten (WSFCNODE2) konfiguriert ist, die Teil des AWS Verzeichnisses Directory Service for Microsoft Active Directory mit dem Namen tagechtalk.com

  • Ein oder mehrere Knoten, die für die Annahme read-only im sekundären Replikat konfiguriert sind

  • Ein Listener, der nach der SQLAG1 Always-On-Verfügbarkeitsgruppe benannt ist

  • SQLServer Database Engine wird mit demselben Dienstkonto auf zwei Knoten ausgeführt

  • SQLServer Management Studio (SSMS)

  • Eine Testdatenbank mit dem Namen test

Produktversionen

  • SQLServer 2014 und später

Architektur

Zieltechnologie-Stack

  • Amazon EC2

  • AWS Managed Microsoft AD

  • Amazon FSx

Zielarchitektur

Das folgende Diagramm zeigt, wie der Always On Availability Group (AG) -Listener Abfragen, die den ApplicationIntent Parameter in der Verbindung enthalten, an den entsprechenden sekundären Knoten umleitet.

Dreistufiger Prozess zwischen zwei Availability Zones für Knoten 1 WSFC und Knoten 2 WSFC mit Amazon. EFS
  1. Eine Anfrage wird an den Listener der Always-On-Verfügbarkeitsgruppe gesendet.

  2. Wenn die Verbindungszeichenfolge den ApplicationIntent Parameter nicht enthält, wird die Anfrage an die primäre Instanz gesendet.

  3. Wenn die Verbindungszeichenfolge Folgendes enthältApplicationIntent=ReadOnly, wird die Anforderung an die sekundäre Instanz mit schreibgeschützter Routingkonfiguration gesendet, die über eine WSFC Always-On-Verfügbarkeitsgruppe verfügt.

Tools

AWSDienste

  • AWSDer Directory Service für Microsoft Active Directory ermöglicht es Ihren verzeichnissensitiven Workloads und AWS Ressourcen, Microsoft Active Directory in der Cloud zu verwenden. AWS

  • Amazon Elastic Compute Cloud (AmazonEC2) bietet skalierbare Rechenkapazität in der AWS Cloud. Sie können so viele virtuelle Server wie nötig nutzen und sie schnell nach oben oder unten skalieren.

  • Amazon FSx bietet Dateisysteme, die branchenübliche Konnektivitätsprotokolle unterstützen und eine hohe Verfügbarkeit und Replikation über AWS Regionen hinweg bieten.

Andere Dienste

  • SQLServer Management Studio (SSMS) ist ein Tool zum Verbinden, Verwalten und Verwalten der SQL Serverinstanzen.

  • sqlcmd ist ein Befehlszeilenprogramm.

Bewährte Methoden

Weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen finden Sie in der Serverdokumentation. SQL

Epen

AufgabeBeschreibungErforderliche Fähigkeiten

Aktualisieren Sie die Replikate so, dass sie schreibgeschützt sind.

Um sowohl das primäre als auch das sekundäre Replikat auf schreibgeschützt zu aktualisieren, stellen Sie eine Verbindung zum primären Replikat von her und führen Sie den Schritt SSMS 1-Code aus dem Abschnitt Zusätzliche Informationen aus.

DBA

Erstellen Sie das Routing. URL

Um das Routing URL für beide Replikate zu erstellen, führen Sie den Schritt 2-Code aus dem Abschnitt Zusätzliche Informationen aus. In diesem Code tagechtalk.com steht der Name des AWS verwalteten Microsoft AD-Verzeichnisses.

DBA

Erstellen Sie die Routingliste.

Um die Routingliste für beide Replikate zu erstellen, führen Sie den Schritt 3-Code aus dem Abschnitt Zusätzliche Informationen aus.

DBA

Überprüfen Sie die Routingliste.

Stellen Sie von SQL Server Management Studio aus eine Connect der primären Instanz her und führen Sie den Schritt 4-Code aus dem Abschnitt Zusätzliche Informationen aus, um die Routingliste zu überprüfen.

DBA
AufgabeBeschreibungErforderliche Fähigkeiten

Stellen Sie mithilfe des ApplicationIntent Parameters eine Verbindung her.

  1. VonSSMS, stellen Sie mit dem Listener-Namen der Always-On-Verfügbarkeitsgruppe eine Verbindung her. ApplicationIntent=ReadOnly;Initial Catalog=test

  2. Die Verbindung wird mit dem sekundären Replikat hergestellt. Um dies zu testen, führen Sie den folgenden Befehl aus, um den Namen des verbundenen Servers anzuzeigen.

    SELECT SERVERPROPERTY('ComputernamePhysicalNetBios')

    In der Ausgabe wird der aktuelle Name des sekundären Replikats (WSFCNODE2) angezeigt.

DBA

Führen Sie einen Failover durch.

  1. VonSSMS, stellen Sie eine Verbindung zum Listener-Namen der Always-On-Verfügbarkeitsgruppe her.

  2. Stellen Sie sicher, dass die primäre und die sekundäre Datenbank synchron und ohne Datenverlust synchronisiert sind.

  3. Führen Sie einen Failover durch, sodass das aktuelle primäre Replikat zum sekundären Replikat und das sekundäre Replikat zum primären Replikat wird.

  4. VonSSMS, stellen Sie mit dem Listener-Namen der Always-On-Verfügbarkeitsgruppe eine Verbindung her. ApplicationIntent=ReadOnly;Initial Catalog=test

  5. Die Verbindung wird mit dem sekundären Replikat hergestellt. Um dies zu testen, zeigen Sie den Namen des verbundenen Servers an, indem Sie den folgenden Befehl ausführen.

    SELECT SERVERPROPERTY('ComputernamePhysicalNetBios')

    Es wird der aktuelle Name des sekundären Replikats angezeigt (WSFCNODE1).

DBA
AufgabeBeschreibungErforderliche Fähigkeiten

Stellen Sie mithilfe von sqlcmd eine Connect.

Um von sqlcmd aus eine Verbindung herzustellen, führen Sie in der Befehlszeile den Schritt 5-Code aus dem Abschnitt Zusätzliche Informationen aus. Nachdem Sie die Verbindung hergestellt haben, führen Sie den folgenden Befehl aus, um den Namen des verbundenen Servers anzuzeigen.

SELECT SERVERPROPERTY('ComputernamePhysicalNetBios') .

In der Ausgabe wird der aktuelle Name des sekundären Replikats (WSFCNODE1) angezeigt.

DBA

Fehlerbehebung

ProblemLösung

Das Erstellen des Listeners schlägt fehl und es wird die Meldung „Der WSFC Cluster konnte die Netzwerknamenressource nicht online bringen“ angezeigt.

Weitere Informationen finden Sie im Microsoft-Blogbeitrag Create Listener Fails with Message 'The WSFC cluster could not bring the Network Name resource online'.

Mögliche Probleme, einschließlich anderer Listener-Probleme oder Netzwerkzugriffsprobleme.

Weitere Informationen finden Sie unter Problembehandlung bei der Konfiguration von Always-On-Verfügbarkeitsgruppen (SQLServer) in der Microsoft-Dokumentation.

Zugehörige Ressourcen

Zusätzliche Informationen

Schritt 1. Aktualisieren Sie die Replikate so, dass sie schreibgeschützt sind

ALTER AVAILABILITY GROUP [SQLAG1] MODIFY REPLICA ON N'WSFCNODE1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)) GO ALTER AVAILABILITY GROUP [SQLAG1] MODIFY REPLICA ON N'WSFCNODE2' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)) GO

Schritt 2. Erstellen Sie das Routing URL

ALTER AVAILABILITY GROUP [SQLAG1] MODIFY REPLICA ON N'WSFCNODE1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://WSFCNode1.tagechtalk.com:1433')) GO ALTER AVAILABILITY GROUP [SQLAG1] MODIFY REPLICA ON N'WSFCNODE2' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://WSFCNode2.tagechtalk.com:1433')) GO

Schritt 3. Erstellen Sie die Routing-Liste

ALTER AVAILABILITY GROUP [SQLAG1] MODIFY REPLICA ON N'WSFCNODE1' WITH (PRIMARY_ROLE(READ_ONLY_ROUTING_LIST=('WSFCNODE2','WSFCNODE1'))); GO ALTER AVAILABILITY GROUP [SQLAG1] MODIFY REPLICA ON N'WSFCNODE2' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('WSFCNODE1','WSFCNODE2'))); GO

Schritt 4. Validieren Sie die Routing-Liste

SELECT AGSrc.replica_server_name AS PrimaryReplica, AGRepl.replica_server_name AS ReadOnlyReplica, AGRepl.read_only_routing_url AS RoutingURL , AGRL.routing_priority AS RoutingPriority FROM sys.availability_read_only_routing_lists AGRL INNER JOIN sys.availability_replicas AGSrc ON AGRL.replica_id = AGSrc.replica_id INNER JOIN sys.availability_replicas AGRepl ON AGRL.read_only_replica_id = AGRepl.replica_id INNER JOIN sys.availability_groups AV ON AV.group_id = AGSrc.group_id ORDER BY PrimaryReplica

Schritt 5. SQLBefehlsdienstprogramm

sqlcmd -S SQLAG1,1433 -E -d test -K ReadOnly