SqlClient-Unterstützung für hohe Verfügbarkeit, Notfallwiederherstellung

  • Artikel
  • 5 Minuten Lesedauer

In diesem Artikel werden die SqlClient-Unterstützung (in .NET Framework 4.5) für hohe Verfügbarkeit, Notfallwiederherstellung mit den Always On Features erläutert – Always On Verfügbarkeitsgruppen (AGs) und Always On Failoverclusterinstanzen (FCIs) mit SQL Server 2012 oder höher.

Sie können jetzt einen Verfügbarkeitsgruppenlistener oder den Namen einer FCI in der Verbindungseigenschaft angeben. Wenn eine SqlClient-Anwendung mit einer Datenbank verbunden ist, die fehlschlägt, wird die ursprüngliche Verbindung unterbrochen, und die Anwendung muss eine neue Verbindung öffnen, um nach dem Failover weiterzuarbeiten.

Wenn Sie keine Verbindung mit einer AG oder FCI herstellen, und wenn mehrere IP-Adressen einem Hostnamen zugeordnet sind, wird SqlClient sequenziell durch alle IP-Adressen, die dem DNS-Eintrag zugeordnet sind, durchlaufen. Dies kann zeitaufwändig sein, wenn die erste vom DNS-Server zurückgegebene IP-Adresse an keine Netzwerkschnittstellenkarte (NIC) gebunden ist. Beim Herstellen einer Verbindung mit einer FCI oder dem Listener einer Verfügbarkeitsgruppe versucht SqlClient, Verbindungen mit allen IP-Adressen parallel herzustellen. Falls ein Verbindungsversuch erfolgreich war, bricht der Treiber alle weiteren laufenden Verbindungsversuche ab.

Hinweis

Das Erhöhen des Verbindungstimeouts sowie die Implementierung von Verbindungswiederholungslogik erhöhen die Wahrscheinlichkeit, dass eine Anwendung eine Verbindung zu einer Verfügbarkeitsgruppe herstellt. Da zudem eine Verbindung aufgrund eines Failovers fehlschlagen kann, empfiehlt sich die Implementierung von Verbindungswiederholungslogik, wodurch im Fall einer fehlgeschlagenen Verbindung bis zur erneuten Verbindung Wiederholungsversuche erfolgen.

Die folgenden Verbindungseigenschaften wurden zu SqlClient in .NET Framework 4.5 hinzugefügt:

  • ApplicationIntent

  • MultiSubnetFailover

Sie können diese Schlüsselwörter für Verbindungszeichenfolgen folgendermaßen programmgesteuert ändern:

Hinweis

true Die Einstellung MultiSubnetFailover für .NET Framework Versionen 4.6.1 und höher ist nicht erforderlich. Es ist in .NET Core und .NET 5+ erforderlich.

Verbinden mit MultiSubnetFailover

Geben Sie immer an MultiSubnetFailover=True , wenn Sie eine Verbindung mit dem FCI oder dem Listener einer AG herstellen. MultiSubnetFailoverermöglicht einen schnelleren Failover für alle AGs und ODER FCIs in SQL Server 2012 oder höher und reduziert die Failoverzeit für einzelne und multi-subnetz-Always On Topologien erheblich. Während eines Multisubnetz-Failovers versucht der Client, Verbindungen parallel herzustellen. Während eines Subnetz-Failovers ruft der Client die TCP-Verbindung aggressiv zurück.

Die MultiSubnetFailover Verbindungseigenschaft gibt an, dass die Anwendung entweder eine AG oder eine FCI verwendet und sqlClient versucht, eine Verbindung mit der Datenbank in der primären SQL Server-Instanz herzustellen, indem Sie versuchen, eine Verbindung mit allen IP-Adressen herzustellen. Wenn MultiSubnetFailover=True für eine Verbindung angegeben wird, wiederholt der Client TCP-Verbindungsversuche schneller als dies bei den standardmäßigen TCP-Neuübertragungsintervallen des Betriebssystems der Fall ist. Dies ermöglicht eine schnellere Verbindung nach dem Failover einer AG oder einer FCI und gilt sowohl für Einzel- als auch für Multi-Subnetz-AGs und FCIs.

Weitere Informationen zu den Schlüsselwörtern für Verbindungszeichenfolgen, die in SqlClient unterstützt werden, finden Sie unter ConnectionString.

Wenn Sie MultiSubnetFailover=True eine Verbindung mit einem anderen Als einer AG oder FCI herstellen, kann eine negative Leistungswirkung auftreten und nicht unterstützt werden.

Verwenden Sie die folgenden Richtlinien, um eine Verbindung mit einem Server mit einem der Always On Features herzustellen:

  • Verwenden Sie die MultiSubnetFailover-Verbindungseigenschaft, wenn Sie eine Verbindung mit einem Einzelsubnetz oder Multisubnetz herstellen. Dadurch wird die Leistung für beide verbessert.

  • Um eine Verbindung mit einer AG herzustellen, geben Sie den Listener der Verfügbarkeitsgruppe als Server in Ihrer Verbindungszeichenfolge an.

  • Ein Verbindungsversuch mit einer mit mehr als 64 IP-Adressen konfigurierten SQL Server -Instanz verursacht einen Verbindungsfehler.

  • Das Verhalten einer Anwendung, die die MultiSubnetFailover-Verbindungseigenschaft verwendet, wird nicht vom Authentifizierungstyp beeinflusst: SQL Server-Authentifizierung, Kerberos-Authentifizierung oder Windows-Authentifizierung.

  • Vergrößern Sie den Wert von Connect Timeout, um eine ausreichende Failoverzeit zu konfigurieren und die Anzahl der Verbindungsherstellungsversuche der Anwendung zu reduzieren.

  • Verteilte Transaktionen werden nicht unterstützt.

Wenn das schreibgeschützte Routing nicht in Kraft ist, scheitert das Herstellen einer Verbindung mit einem sekundären Replikatspeicherort in den folgenden Situationen:

  • Wenn der sekundäre Replikatspeicherort nicht zum Akzeptieren von Verbindungen konfiguriert ist.

  • Wenn eine Anwendung ApplicationIntent=ReadWrite verwendet (weiter unten erläutert), und der sekundäre Replikatspeicherort für schreibgeschützten Zugriff konfiguriert ist.

SqlDependency wird bei schreibgeschützten sekundären Replikaten nicht unterstützt.

Es kann keine Verbindung hergestellt werden, wenn ein primäres Replikat so konfiguriert ist, dass schreibgeschützte Arbeitslasten abgelehnt werden, und die Verbindungszeichenfolge ApplicationIntent=ReadOnly enthält.

Aktualisieren zur Verwendung von Multisubnetzclustern aus Datenbankspiegelung

Ein Verbindungsfehler (ArgumentException) tritt auf, wenn die Verbindungsschlüsselwörter MultiSubnetFailover und Failover Partner in der Verbindungszeichenfolge vorhanden sind oder wenn MultiSubnetFailover=True und ein anderes Protokoll als TCP verwendet wird. Es tritt auch ein Fehler (SqlException) auf, wenn MultiSubnetFailover verwendet wird und SQL Server eine Failoverpartnerantwort zurückgibt, die angibt, dass es Teil eines Datenbankspiegelungspaars ist.

Wenn Sie eine SqlClient-Anwendung aktualisieren, die derzeit Datenbankspiegelung in einem Multisubnetz-Szenario verwendet, müssen Sie die Failover Partner-Verbindungseigenschaft entfernen und mit MultiSubnetFailover, festgelegt auf True, ersetzen, sowie den Servernamen in der Verbindungszeichenfolge mit einem Verfügbarkeitsgruppenlistener ersetzen. Wenn eine Verbindungszeichenfolge Failover Partner und MultiSubnetFailover=True verwendet, generiert der Treiber einen Fehler. Wenn eine Verbindungszeichenfolge jedoch Failover Partner und MultiSubnetFailover=False (oder ApplicationIntent=ReadWrite) verwendet, verwendet die Anwendung Datenbankspiegelung.

Der Treiber gibt einen Fehler zurück, wenn die Datenbankspiegelung für die primäre Datenbank in der Verfügbarkeitsgruppe verwendet wird und wenn MultiSubnetFailover=True in der Verbindungszeichenfolge angegeben ist, wodurch eine Verbindung mit einer primären Datenbank und nicht mit einem Verfügbarkeitsgruppen-Listener hergestellt wird.

Angeben des Anwendungszwecks

Im Fall von ApplicationIntent=ReadOnly fordert der Client eine Lesearbeitslast an, wenn eine Verbindung mit einer AlwaysOn-Datenbank hergestellt wird. Der Server erzwingt den Versuch zur Verbindungszeit und während einer USE-Datenbankanweisung, aber nur für eine AlwaysOn-aktivierte Datenbank.

Das ApplicationIntent-Schlüsselwort funktioniert nicht mit schreibgeschützten Legacy-Datenbanken.

Eine Datenbank kann Lesearbeitslasten auf der AlwaysOn-Zieldatenbank zulassen bzw. nicht zulassen. (Dies geschieht über die ALLOW_CONNECTIONS-Klausel der Transact-SQL-Anweisungen PRIMARY_ROLE und SECONDARY_ROLE.)

Das ApplicationIntent-Schlüsselwort wird verwendet, um schreibgeschütztes Routing zu aktivieren.

Schreibgeschütztes Routing

Schreibgeschütztes Routing ist eine Funktion, die die Verfügbarkeit eines schreibgeschützten Replikats einer Datenbank sicherstellen kann. So aktivieren Sie schreibgeschütztes Routing:

  1. Sie müssen eine Verbindung zum Verfügbarkeitsgruppenlistener einer AlwaysOn-Verfügbarkeitsgruppe herstellen.

  2. Das Schlüsselwort der ApplicationIntent-Verbindungszeichenfolge muss auf ReadOnly festgelegt werden.

  3. Die Verfügbarkeitsgruppe muss vom Datenbankadministrator konfiguriert werden, um schreibgeschütztes Routing zu aktivieren.

Möglicherweise werden bei mehreren Verbindungen mithilfe von schreibgeschütztem Routing nicht alle mit demselben schreibgeschützten Replikat verbunden. Änderungen in der Datenbanksynchronisierung oder Änderungen in der Routingkonfiguration des Servers können zu Clientverbindungen mit anderen schreibgeschützten Replikaten führen. Sie gewährleisten, dass alle schreibgeschützten Anforderungen Verbindungen mit demselben schreibgeschützten Replikat herstellen, indem Sie keinen Verfügbarkeitsgruppenlistener an das Schlüsselwort der Data Source-Verbindungszeichenfolge übermitteln. Geben Sie stattdessen den Namen der schreibgeschützten Instanz an.

Schreibgeschütztes Routing dauert möglicherweise länger als das Herstellen einer primären Verbindung, da schreibgeschütztes Routing zuerst eine primäre Verbindung herstellt und dann nach der besten verfügbaren lesbaren Sekundärverbindung sucht. Deswegen sollten Sie das Anmeldetimeout vergrößern.

Siehe auch