Teilen über

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

  • Artikel

In diesem Artikel wird die SqlClient-Unterstützung (in .NET Framework 4.5 hinzugefügt) für Hochverfügbarkeit und Notfallwiederherstellung mit den Always On-Features (Always On-Verfügbarkeitsgruppen und Always On-Failoverclusterinstanzen) in SQL Server 2012 oder höher erläutert.

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, für die ein Failover ausgeführt wird, wird die ursprüngliche Verbindung unterbrochen, und die Anwendung muss eine neue Verbindung öffnen, damit ihre Ausführung nach dem Failover fortgesetzt werden kann.

Wenn Sie keine Verbindung mit einer Verfügbarkeitsgruppe oder einer FCI herstellen und mehrere IP-Adressen einem Hostnamen zugeordnet sind, durchläuft SqlClient nacheinander alle IP-Adressen, die dem DNS-Eintrag zugeordnet sind. Dies kann zeitaufwändig sein, wenn die erste vom DNS-Server zurückgegebene IP-Adresse an keine Netzwerkschnittstellenkarte (NIC) gebunden ist. Wenn Sie eine Verbindung mit einer FCI oder dem Listener einer Verfügbarkeitsgruppe herstellen, versucht SqlClient, parallel mit allen IP-Adressen Verbindungen 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 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

Bei .NET Framework 4.6.1 und höheren Versionen muss MultiSubnetFailover nicht auf true festgelegt werden. Dies ist in .NET Core und .NET 5+ erforderlich.

Verbinden mit MultiSubnetFailover

Geben Sie beim Herstellen einer Verbindung mit der FCI oder dem Listener einer Verfügbarkeitsgruppe immer MultiSubnetFailover=True an. MultiSubnetFailover ermöglicht ein schnelleres Failover für alle Verfügbarkeitsgruppen und/oder Failoverclusterinstanzen in SQL Server 2012 oder höher und reduziert die Failoverzeit für Always On-Topologien mit einem Subnetz oder mehreren Subnetzen erheblich. Während eines Multisubnetz-Failovers versucht der Client, Verbindungen parallel herzustellen. Während eines Subnetzfailovers versucht der Client energisch, die TCP-Verbindung wiederherzustellen.

Die Verbindungseigenschaft MultiSubnetFailover gibt an, dass die Anwendung eine Verfügbarkeitsgruppe oder eine Failoverclusterinstanz verwendet und dass SqlClient versucht, eine Verbindung mit der Datenbank in der primären SQL Server-Instanz herzustellen, indem mit allen IP-Adressen Verbindungsversuche unternommen werden. 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 Wiederherstellung der Verbindung nach dem Failover einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz und ist auf Verfügbarkeitsgruppen und Failoverclusterinstanzen mit einem oder mehreren Subnetzen anwendbar.

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

Wenn beim Herstellen einer Verbindung mit einer anderen Entität als einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz MultiSubnetFailover=True angegeben wird, kann dies die Leistung beeinträchtigen. Dies wird daher nicht unterstützt.

Verwenden Sie die folgenden Richtlinien, um mithilfe eines der Always On-Features eine Verbindung mit einem Server 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 Verfügbarkeitsgruppe herzustellen, geben Sie den Listener der Verfügbarkeitsgruppe als Server in der 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

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

  • Sie müssen eine Verbindung zum Verfügbarkeitsgruppenlistener einer AlwaysOn-Verfügbarkeitsgruppe herstellen.
  • Das Schlüsselwort der ApplicationIntent-Verbindungszeichenfolge muss auf ReadOnly festgelegt werden.
  • 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