Informationen zum Clientverbindungszugriff auf Verfügbarkeitsreplikate (SQL Server)

In einer AlwaysOn-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 konfigurieren, um schreibgeschütztes Routing zu unterstützen, das seinem Verfügbarkeitsgruppenlistener ermöglicht, die Verbindungsanforderungen von Anwendungen für beabsichtigte Lesevorgänge an ein lesbares, sekundäres Replikat umzuleiten. Weitere Informationen finden Sie unter Konfigurieren des schreibgeschützten Routing für eine Verfügbarkeitsgruppe (SQL Server).

Während eines Failovers geht ein sekundäres Zielreplikat in die primäre Rolle über, und das frühere primäre Replikat geht in die sekundäre Rolle über. 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 ordnungsgemäße Clientfunktionen sicherzustellen, ist es wichtig, den Verbindungszugriff für sekundäre und primäre Rollen jedes Verfügbarkeitsreplikats zu konfigurieren.

Hinweis
Informationen zum Verfügbarkeitsgruppenlistener, der Clientverbindungsanforderungen behandelt, finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server).

In diesem Thema:

• Von der sekundären Rolle unterstützte Verbindungszugriffstypen

• Von der primären Rolle unterstützte Verbindungszugriffstypen

• Auswirkungen der Verbindungszugriffskonfiguration auf die Clientkonnektivität

• Verwandte Aufgaben

• Verwandte Inhalte

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 für beabsichtigte Lesevorgänge
  Die sekundären Datenbanken sind nur für Verbindungen verfügbar, für das die Application Intent-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, Notfallwiederherstellung.

• Schreibgeschützte Verbindungen 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).

[Nach oben]

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 Application Intent-Verbindungseigenschaft auf READWRITE oder nicht festgelegt ist, wird die Verbindung zugelassen. Verbindungen, für die das Application Intent-Verbindungszeichenfolgen-Schlüsselwort auf ReadOnly festgelegt ist, werden nicht zugelassen. Durch das Zulassen nur von Verbindungen mit Lese-/Schreibzugriff kann verhindert werden, dass die Kunden mit dem primären Replikat versehentlich eine leseintensive Arbeitsauslastung verbinden.

  Weitere Informationen zu dieser Verbindungseigenschaft finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit SQL Server Native Client.

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

[Nach oben]

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.

Informationen zum Konfigurieren einer Verfügbarkeitsgruppe für das Akzeptieren von Clientverbindungen zu ihren Replikaten 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 Application Intent-Verbindungseigenschaft auf ReadOnly festgelegt, 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 konfiguriert, um Verbindungen für beabsichtigte Lesevorgänge unter der sekundären Rolle zuzulassen. In der folgenden Tabelle wird diese Beispielkonfiguration zusammengefasst:

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. Bei einem Notfall im Hauptrechencenter gehen jedoch 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 vom erzwungenen Failover angehalten und dadurch für schreibgeschützte Arbeitsauslastungen nicht verfügbar. Das für Lese-/Schreibverbindungen konfigurierte neue primäre Replikat verhindert, dass die Arbeitsauslastung für beabsichtigte Lesevorgänge mit der Auslastung für Lese-/Schreibzugriff 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.

[Nach oben]

Verwandte Aufgaben

• Konfigurieren des schreibgeschützten Zugriffs auf ein Verfügbarkeitsreplikat (SQL Server)

• Konfigurieren des schreibgeschützten Routing für eine Verfügbarkeitsgruppe (SQL Server)

• Überwachen von Verfügbarkeitsgruppen (Transact-SQL)

• Anzeigen von Verfügbarkeitsreplikateigenschaften (SQL Server)

• Verwenden des Dialogfelds Neue Verfügbarkeitsgruppe (SQL Server Management Studio)

[Nach oben]

Verwandte Inhalte

• Microsoft SQL Server AlwaysOn-Lösungshandbuch zu hoher Verfügbarkeit und Notfallwiederherstellung

• SQL Server AlwaysOn-Teamblog: Der offizielle SQL Server AlwaysOn-Teamblog

[Nach oben]

Siehe auch

Konzepte

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server)

Statistik