Als DBAs begegnen wir im Allgemeinen unseren Kunden, die sich darüber beschweren, dass der aktuelle Produktionsserver die Last auf dem Server nicht halten kann und ob die Last mit dem sekundären Server ausgeglichen werden kann. Dies ist mit einer Datenbank im DR-Server mit schreibgeschützter Datenbank im Protokollversand und sekundären SQL Server-Replikaten in der Always On-Verfügbarkeitsgruppe möglich. Der größte Vorteil von Always On Groups besteht darin, dass wir HA auf Gruppenebene für eine beliebige Anzahl von Datenbanken einrichten und bis zu vier sekundäre Replikate erstellen können, und dies ist eine Kombination aus Clustering, Protokollversand und Datenbankspiegelung, bei der die Datenübertragung erfolgt flexibler und funktioneller.
Always On Readable Secondary Replica verfügt über eine Funktion zur Verarbeitung bestimmter schreibgeschützter Verbindungsanforderungen, die als schreibgeschütztes Routing bezeichnet werden. Im Allgemeinen werden sowohl Lese- als auch Leseabsicht standardmäßig an das primäre Replikat geleitet, und nichts ist für die sekundären Replikate bestimmt. Jetzt können die sekundären Replikate nicht nur für Sicherungs-, DBCC- und Berichtszwecke verwendet werden, sondern können auch in Zukunft abgefragt werden, indem „ReadOnly“ als ihr Anwendungszweck in der Verbindungszeichenfolge der Anwendung verwendet wird.
Wir haben drei Replikate SQL1, SQL2 und SQL3 im Windows-Failovercluster. Auf jedem Knoten ist eine eigenständige SQL Server 2012-Instanz installiert und mit Always On AG konfiguriert. Wir sind immer auf der AG-Gruppe namens „CODEAG“ mit dem Hörernamen „CODELIS“
Im folgenden Screenshot ist SQL1 ein primäres Replikat, SQL2 ein sekundäres Replikat und SQL3 ein sekundäres Replikat.
So konfigurieren Sie eine schreibgeschützte Routingliste in Always-on-Verfügbarkeitsgruppen
Schritt 1:
Verbindungen zur Verfügbarkeitsgruppe werden unter Verwendung des Listener-Namens oder der IP-Adresse hergestellt. Um nun mehrere Listener für eine Verfügbarkeitsgruppe zu erstellen, gehen Sie bitte wie folgt vor.
Zum manuellen Erstellen oder Konfigurieren eines Listeners für eine Verfügbarkeitsgruppe
- Stellen Sie im Objekt-Explorer eine Verbindung mit der Instanz her, die das primäre Replikat der Verfügbarkeitsgruppe enthält.
- Erweitern Sie die AON-Gruppe und klicken Sie auf die Verfügbarkeitsgruppe, für die wir versuchen, den Listener manuell zu konfigurieren, und fahren Sie fort.
- Klicken Sie mit der rechten Maustaste auf den Verfügbarkeitsgruppen-Listener-Knoten und wählen Sie Neuer Listener-Befehl aus. Dies öffnet ein neues Dialogfeld zum Konfigurieren eines Listeners.
- Die Portnummer eines vorhandenen Listeners kann geändert werden, indem Sie den Verfügbarkeitsgruppen-Listener-Knoten erweitern und anschließend mit der rechten Maustaste auf die Listener klicken und die Eigenschaften auswählen.
- Geben Sie nun die neue Portnummer ein und klicken Sie auf OK.
Identifizieren Sie den Listener-Namen, der für die Always On-Replikation konfiguriert ist, indem Sie DMV wie unten beschrieben abfragen.
SELECT AV.name AS AVGName , AVGLis.dns_name AS ListenerName , AVGLis.ip_configuration_string_from_cluster AS ListenerIP FROM sys.availability_group_listeners AVGLis INNER JOIN sys.availability_groups AV on AV.group_id = AV.group_id
Im folgenden Screenshot lautet der AG-Gruppenname CODEAG und die AG-Listener-IP CODELIS.
Schritt 2:
Um schreibgeschütztes Routing zu konfigurieren, müssen wir die Reproduktionen so konfigurieren, dass sie nur Leseabsicht haben, um schreibgeschützte Verbindungen zu sekundären Reproduktionen zuzulassen.
- Verbinden Sie sich mit der Instanz, die das primäre Replikat enthält.
- Erweitern Sie den AON High Availability Node, dann den AG Group Node.
- Klicken Sie auf die AG-Gruppe, deren Replik geändert werden soll.
- Klicken Sie mit der rechten Maustaste auf das Replikat und wählen Sie Eigenschaften aus, um den Verbindungszugriff für die primären und sekundären Rollen wie folgt zu ändern.
Die sekundäre Rolle hat einen neuen Wert aus der lesbaren sekundären Drop-Liste.
Nur Leseabsicht
Diese Option ermöglicht den Lesezugriff auf die sekundären Datenbanken dieses Replikats. Nur schreibgeschützte Verbindungen sind erlaubt.
Ja
Diese Option erlaubt nur Lesezugriff, aber alle Verbindungen sind für das sekundäre Replikat erlaubt.
Nein
Dadurch werden alle Benutzerverbindungen zum sekundären Replikat beendet und Sie können nicht einmal lesen.
Setzen Sie die lesbaren sekundären Eigenschaften auf Nur Leseabsicht.
Im folgenden Screenshot sind die Readable Secondary-Eigenschaften jedes sekundären Replikats auf Read-intent only gesetzt.
Schritt 3:
Jedem lesbaren sekundären Replikat kann eine schreibgeschützte Routing-URL zugewiesen werden, die zum Weiterleiten von Verbindungsanfragen mit Leseabsicht an ein bestimmtes lesbares sekundäres Replikat verwendet wird.
Verwenden Sie T-SQL, um eine schreibgeschützte Routing-URL für alle Replikate in unserer Verfügbarkeitsgruppe anzugeben.
ALTER AVAILABILITY GROUP [CODEAG] MODIFY REPLICA ON N'SQL1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [CODEAG] MODIFY REPLICA ON N'SQL1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://SQL1.abc.com:17999')); ALTER AVAILABILITY GROUP [CODEAG] MODIFY REPLICA ON N'SQL2' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [CODEAG] MODIFY REPLICA ON N'SQL2' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://SQL2.abc.com:17999')); ALTER AVAILABILITY GROUP [CODEAG] MODIFY REPLICA ON N'SQL3' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [CODEAG] MODIFY REPLICA ON N'SQL3' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://SQL3.abc.com:17999'));
Schritt 4:
Für das Replikat, das wir als schreibgeschütztes Routing markieren, wenn es das primäre Replikat ist, muss eine schreibgeschützte Routingliste angegeben werden, und dies wird nur bewirkt, wenn das lokale Replikat unter der primären Rolle ausgeführt wird.
ALTER AVAILABILITY GROUP [CODEAG]
MODIFY REPLICA ON
N'SQL1' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SQL2','SQL3')));
ALTER AVAILABILITY GROUP [CODEAG]
MODIFY REPLICA ON
N'SQL3' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SQL2','SQL1')));
ALTER AVAILABILITY GROUP [CODEAG]
MODIFY REPLICA ON
N'SQL2' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('SQL3','SQL1')));
Im obigen Skript, dem Beispiel, wenn SQL1 das primäre Replikat ist, wird die Workload mit Leseabsicht an die lesbaren sekundären Replikate umgeleitet; SQL2 bzw. SQL3:Wenn SQL3 das primäre Replikat ist, wird die Arbeitslast mit Leseabsicht auf die lesbaren sekundären Replikate umgeleitet; die SQL2 bzw. SQL1.
Der schreibgeschützte gerichtete Datenverkehr wird an das erste verfügbare Replikat geleitet, bis dieser den Datenverkehr an das nächste verfügbare Replikat in der Routing-Liste weiterleitet, sofern nicht darauf zugegriffen werden kann. Wenn Sie mehr als ein Replikat haben, ist es bis SQL Server 2012 und 2014 nicht möglich, die Last zwischen Replikaten aufzuteilen. SQL Server 2016 ermöglicht Ihnen jedoch, die Last zwischen schreibgeschützten Replikaten auszugleichen.
Beispiel:
ALTER AVAILABILITY GROUP [CODEAG]
MODIFY REPLICA ON
N'SQL2' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=(('SQL3','SQL1'), ‘SQL2’)));
Dieses Verhalten der Routingliste „lastet“ schreibgeschützte Verbindungen zwischen SQL3 und SQL1. Oben haben wir zwei eingebettete Listen in der Routing-Liste:
Liste 1:„SQL3“, „SQL1“
Liste 2:„SQL2“
Weiterleitung zu den Reproduktionen in der ersten Liste. SQL3 und SQL1 sind für schreibgeschützte Verbindungen zugänglich. Die erste eingehende schreibgeschützte Verbindung wird an SQL3 weitergeleitet, die zweite schreibgeschützte Verbindung wird an SQL1 weitergeleitet, die dritte schreibgeschützte Verbindung wird an SQL3 weitergeleitet, die vierte schreibgeschützte Verbindung wird an SQL1 weitergeleitet und so weiter, mit einer 'Round-Robin'-Verteilung von Nur-Lese-Verbindungen zwischen den beiden Reproduktionen in der ersten Liste.
Wenn Replikate nicht mehr verfügbar sind, wird das Routing mit den verbleibenden Replikaten in der ersten Liste fortgesetzt. Wenn SQL3 oder SQL1 für schreibgeschützte Verbindungen unzugänglich wird, werden die schreibgeschützten Verbindungen nur an die zugänglichen schreibgeschützten Replikate in der ersten Liste weitergeleitet. Wenn sich beispielsweise SQL3 in einem nicht synchronisierten Zustand befindet oder ALLOW_CONNECTIONS auf NO gesetzt ist, werden alle schreibgeschützten Verbindungen an SQL1 weitergeleitet. Solange einer der Server für Nur-Lese-Verbindungen verfügbar ist, werden KEINE Nur-Lese-Verbindungen zu SQL2 geleitet.
Wenn auf alle Reproduktionen in der ersten Liste nicht zugegriffen werden kann, zu Replikaten in der nächsten Liste weiterleiten. Wenn SQL3 und SQL1 für schreibgeschützte Verbindungen unzugänglich werden, werden alle schreibgeschützten Verbindungen nur an die nächste Liste von Replikaten weitergeleitet, die in diesem Fall SQL2 ist.
Weiterleitung zur ersten Liste fortsetzen, wenn Repliken verfügbar werden. Wenn sekundäre Replikate, die in der Liste eine höhere Priorität haben, für schreibgeschützte Verbindungen zugänglich werden, werden zukünftige schreibgeschützte Verbindungen entsprechend mit ihnen verbunden.
In SQL Server 2016 können Sie den Lastenausgleich für eine Reihe von schreibgeschützten Replikaten konfigurieren.
Schritt 5:
sys.availability_read_only_routing_lists DMV, das die schreibgeschützte Routingliste jedes Replikats der Verfügbarkeitsgruppe in der Always On-Verfügbarkeitsgruppe zurückgibt.
SELECT AVGSrc.replica_server_name AS SourceReplica , AVGRepl.replica_server_name AS ReadOnlyReplica , AVGRepl.read_only_routing_url AS RoutingURL , AVGRL.routing_priority AS RoutingPriority FROM sys.availability_read_only_routing_lists AVGRL INNER JOIN sys.availability_replicas AVGSrc ON AVGRL.replica_id = AVGSrc.replica_id INNER JOIN sys.availability_replicas AVGRepl ON AVGRL.read_only_replica_id = AVGRepl.replica_id INNER JOIN sys.availability_groups AV ON AV.group_id = AVGSrc.group_id ORDER BY SourceReplica
Im folgenden Screenshot zeigt das Ergebnis die Routing-URL und die Routing-Priorität.
Schritt 6:
Um das schreibgeschützte Routing mit SQLCMD zu testen, verwenden Sie den Parameter –K ReadOnly, der anzeigt, dass das sekundäre Replikat Leseverbindungen gemäß der Routingliste empfängt.
Im folgenden Screenshot akzeptiert das sekundäre Replikat die Leseverbindungen, d. h. … SQL2.
Schritt 7:
Failover der Verfügbarkeitsgruppe und Testen des schreibgeschützten Routings.
- Stellen Sie im Objekt-Explorer eine Verbindung zu einer Serverinstanz her, die ein sekundäres Replikat der Verfügbarkeitsgruppe hostet, für die ein Failover erforderlich ist. Erweitern Sie den Serverbaum.
- Erweitern Sie den Knoten „AlwaysOn High Availability“ und den Knoten „Availability Groups“.
- Klicken Sie mit der rechten Maustaste auf die Verfügbarkeitsgruppe, für die ein Failover ausgeführt werden soll, und wählen Sie Failover aus.
Jetzt wird SQL2 zum primären Replikat und Verbindungen werden von SQL1 gehandhabt.
Die Syntax der Verbindungszeichenfolge, die die Anwendung verwenden sollte, hängt vom SQL Server-Anbieter ab.
Wenn es sich um .Net Framework Data Provider 4.0.2 für SQL Server handelt, lautet die Syntax wie folgt:
Server=tcp:MyAgListener,Portnummer;Datenbank=SQL1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True
Schlussfolgerung:
Um die Workloads zu verringern, bleibt dieses schreibgeschützte Routing die beste Option. Eine Anwendung mit SQL Server Reporting Services, die in SharePoint gehostet wird, oder die Installation des Berichtsservers im einheitlichen Modus kann eine schreibgeschützte Absicht verwenden, die die typische Blockierung, Speicher- und CPU-Auslastung auf primären Knoten vermeidet.
