Typen von Clientverbindungen zu Replikaten in einer Always On-Verfügbarkeitsgruppe

Gilt für:SQL Server

In einer Always On-Verfügbarkeitsgruppe können Sie mindestens ein Verfügbarkeitsreplikat konfigurieren, um schreibgeschützte Verbindungen zuzulassen, wenn es unter der sekundären Rolle ausgeführt wird (d h. bei Ausführung als sekundäres Replikat). Sie können auch jedes Verfügbarkeitsreplikat konfigurieren, um schreibgeschützte Verbindungen bei der Ausführung unter der primären Rolle zuzulassen oder auszuschließen (d. h. bei Ausführung als das primäre Replikat).

Um den Clientzugriff auf primäre oder sekundäre Datenbanken einer bestimmten Verfügbarkeitsgruppe zu erleichtern, sollten Sie einen Verfügbarkeitsgruppenlistener erstellen. Standardmäßig werden eingehende Verbindungen vom Verfügbarkeitsgruppenlistener an das primäre Replikat weitergeleitet. Sie können jedoch eine Verfügbarkeitsgruppe so konfigurieren, dass sie schreibgeschütztes Routing unterstützt, wodurch ihr Verfügbarkeitsgruppenlistener die Verbindungsanforderungen von Anwendungen mit Leseabsicht an ein lesbares sekundäres Replikat umleiten kann. Weitere Informationen finden Sie unter Konfigurieren des schreibgeschützten Routings für eine Verfügbarkeitsgruppe (SQL Server).

Während eines Failovers wechselt ein sekundäres Replikat in die primäre Rolle, und das bisherige primäre Replikat wechselt in die sekundäre Rolle. Während des Failoverprozesses werden alle Clientverbindungen zum primären Replikat und zu den sekundären Replikaten beendet. Nach dem Failover, wenn ein Client die Verbindung mit dem Verfügbarkeitsgruppenlistener wiederherstellt, verbindet der Listener den Client erneut mit dem neuen primären Replikat, sofern es sich dabei nicht um eine Verbindungsanforderung für beabsichtigte Lesevorgänge handelt. Wenn schreibgeschütztes Routing auf dem Client und den Serverinstanzen konfiguriert wird, die das neue primäre Replikat hosten, und auf mindestens einem lesbaren sekundären Replikat, werden die Verbindungsanforderungen für beabsichtigte Lesevorgänge an ein sekundäres Replikat weitergeleitet, das den angeforderten Verbindungszugriffstyp des Clients unterstützt. Um nach einem Failover ein reibungsloses Verhalten auf Clientseite sicherzustellen, ist es wichtig, den Verbindungszugriff sowohl für die sekundäre als auch für die primäre Rolle jedes Verfügbarkeitsreplikats zu konfigurieren.

Hinweis

Informationen zum Verfügbarkeitsgruppenlistener, der Verbindungsanforderungen von Clients verarbeitet, finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server).

Von der sekundären Rolle unterstützte Verbindungszugriffstypen

Die sekundäre Rolle unterstützt die folgenden drei Alternativen für Clientverbindungen:

Keine Verbindungen
Es werden keine Benutzerverbindungen zugelassen. Sekundäre Datenbanken sind nicht für Lesezugriff verfügbar. Dies ist das Standardverhalten in der sekundären Rolle.

Nur Verbindungen mit Leseabsicht
Die sekundären Datenbanken sind nur für Verbindungen verfügbar, für die die Anwendungszweck -Verbindungseigenschaft auf ReadOnly (Verbindungen für beabsichtigte Lesevorgänge) festgelegt ist.

Weitere Informationen zu dieser Verbindungseigenschaft finden Sie unter SQL Server Native Client-Unterstützung für hohe Verfügbarkeit, Wiederherstellung im Notfall.

Beliebige schreibgeschützte Verbindung zulassen
Die sekundären Datenbanken sind alle für Lesezugriffsverbindungen verfügbar. Diese Option ermöglicht es Clients mit älteren Versionen, eine Verbindung herzustellen.

Weitere Informationen finden Sie unter Konfigurieren des schreibgeschützten Zugriffs auf ein Verfügbarkeitsreplikat (SQL Server).

Von der primären Rolle unterstützte Verbindungszugriffstypen

Die primäre Rolle unterstützt die folgenden zwei Alternativen für Clientverbindungen:

Alle Verbindungen sind zugelassen
Sowohl Verbindungen mit Lese-/Schreibzugriff als auch schreibgeschützte Verbindungen sind für primäre Datenbanken zugelassen. Dies ist das Standardverhalten für die primäre Rolle.

Nur Verbindungen mit Lese-/Schreibzugriff zulassen
Wenn die Anwendungszweck -Verbindungseigenschaft auf ReadWrite oder nicht festgelegt ist, wird die Verbindung zugelassen. Verbindungen, für die das Anwendungszweck -Verbindungszeichenfolgen-Schlüsselwort auf ReadOnly festgelegt ist, werden nicht zugelassen. Wenn Sie nur Lese-/Schreibverbindungen zulassen, kann dies dazu beitragen, zu verhindern, dass Ihre Kunden versehentlich eine für Lesezugriffe vorgesehene Workload mit dem primären Replikat verbinden.

Weitere Informationen zu dieser Verbindungseigenschaft finden Sie unter Using Connection String Keywords with SQL Server Native Client.

Weitere Informationen finden Sie unter Konfigurieren des schreibgeschützten Zugriffs auf ein Verfügbarkeitsreplikat (SQL Server).

Auswirkungen der Verbindungszugriffskonfiguration auf die Clientkonnektivität

Die Verbindungszugriffseinstellungen eines Replikats bestimmen, ob ein Verbindungsversuch fehlschlägt oder erfolgreich ist. In der folgenden Tabelle wird für jede Verbindungszugriffseinstellung zusammengefasst, ob ein bestimmter Verbindungsversuch erfolgreich ist oder fehlschlägt.

Replikrolle Verbindungszugriff auf Replikat unterstützt Verbindungsabsicht Ergebnis des Verbindungsversuchs
Sekundär Alle Leseabsicht, Lese-/Schreibabsicht oder keine Verbindungsabsicht angegeben Erfolg
Sekundär Keine (Dies ist das standardmäßige sekundäre Verhalten.) Leseabsicht, Lese-/Schreibabsicht oder keine Verbindungsabsicht angegeben Fehler
Sekundär Nur Leseabsicht Leseabsicht Erfolg
Sekundär Nur Leseabsicht Lese-/Schreibzugriff oder keine Verbindungsabsicht angegeben Fehler
Primär Alle (dies ist das primäre Standardverhalten) Schreibgeschützt, Lese-/Schreibzugriff oder keine Verbindungsabsicht angegeben Erfolg
Primär Lese-/Schreib Nur Leseabsicht Fehler
Primär Lesen/Schreiben Lese-/Schreibverbindung oder keine Verbindungsabsicht angegeben Erfolg

Informationen darüber, wie Sie die Verfügbarkeitsgruppe konfigurieren müssen, damit diese Clientverbindungen zu ihren Replikaten akzeptiert, finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server).

Beispiel für Verbindungszugriffskonfiguration

Abhängig von der unterschiedlichen Konfiguration von Verfügbarkeitsreplikaten für den Verbindungszugriff kann sich die Unterstützung für Clientverbindungen nach dem Failover einer Verfügbarkeitsgruppe ändern. Betrachten Sie z. B. eine Verfügbarkeitsgruppe, für die die Berichterstellung auf sekundären Remotereplikaten mit asynchronem Commit ausgeführt wird. Für alle schreibgeschützten Anwendungen für die Datenbanken in dieser Verfügbarkeitsgruppe ist die Anwendungszweck -Verbindungseigenschaft auf ReadOnlyfestgelegt, damit alle schreibgeschützten Verbindungen Verbindungen für beabsichtigte Lesevorgänge sind.

Diese Beispielverfügbarkeitsgruppe besitzt zwei Replikate mit synchronem Commit im Hauptrechencenter und zwei Replikate mit asynchronem Commit an einem Satellitenstandort. Für die primäre Rolle sind alle Replikate für Lese-/Schreibzugriff konfiguriert, wodurch Verbindungen für beabsichtigte Lesevorgänge zum primären Replikat in allen Situationen verhindert werden. Die sekundäre Rolle mit synchronem Commit verwendet die Standard-Verbindungszugriffskonfiguration ("keine"), die alle Clientverbindungen unter der sekundären Rolle verhindert. Im Gegensatz dazu werden die Replikate mit asynchronem Commit so konfiguriert, dass Read-Intent-Verbindungen in der sekundären Rolle zulässig sind. In der folgenden Tabelle wird diese Beispielkonfiguration zusammengefasst:

Replikat Bestätigungsmodus Anfangsrolle Verbindungszugriff für sekundäre Rolle Zugriff auf Verbindungen für die Hauptrolle
Replica1 Synchron Primär Keine Lesen/Schreiben
Replikat2 Synchron Sekundär Keine Lesen/Schreiben
Replica3 Asynchron Sekundär Nur Leseabsicht Lesen/Schreiben
Replica4 Asynchron Sekundär Nur Leseabsicht Lesen/Schreiben

In der Regel treten in diesem Beispielszenario Failover nur zwischen den Replikaten mit synchronem Commit auf, und sofort nach dem Failover können Anwendungen für beabsichtigte Lesevorgänge erneut eine Verbindung mit einem der sekundären Replikate mit asynchronem Commit herstellen. Wenn jedoch im Hauptrechenzentrum ein Katastrophenfall auftritt, gehen beide Replikate mit synchronem Commit verloren. Der Datenbankadministrator am Satellitenstandort reagiert, indem er ein erzwungenes manuelles Failover zu einem sekundären Replikat mit asynchronem Commit ausführt. Die sekundären Datenbanken auf dem verbleibenden sekundären Replikat werden durch das erzwungene Failover ausgesetzt und sind dadurch für schreibgeschützte Workloads nicht verfügbar. Das neue primäre Replikat, das für Lese-/Schreibverbindungen konfiguriert ist, verhindert, dass die für Lesezugriff vorgesehene Last mit der Lese-/Schreiblast konkurriert. Dies bedeutet, dass bis der Datenbankadministrator die sekundären Datenbanken auf dem verbleibenden sekundären Replikat mit asynchronem Commit fortsetzt, Clients für beabsichtigte Lesevorgänge keine Verbindung mit einem Verfügbarkeitsreplikat herstellen können.

Verwandte Aufgaben

Verwandte Inhalte

  • Last updated on