JDBC-Treiber-Unterstützung für hohe Verfügbarkeit, Notfallwiederherstellung

  • Artikel

JDBC-Treiber herunterladen

Dieser Artikel behandelt die Unterstützung des Microsoft JDBC-Treibers für SQL Server für Hochverfügbarkeit und Notfallwiederherstellung: Always On-Verfügbarkeitsgruppen. Weitere Informationen über Always On-Verfügbarkeitsgruppen finden Sie unter SQL Server 2012 (11.x) Books Online.

Ab Version 4.0 von Microsoft JDBC-Treiber für SQL Server können Sie den Verfügbarkeitsgruppenlistener einer Verfügbarkeitsgruppe (Hochverfügbarkeit, Notfallwiederherstellung) in der Verbindungseigenschaft angeben. Wenn eine Microsoft JDBC-Treiber für SQL Server-Anwendung mit einer Always-On-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. Die folgenden Verbindungseigenschaften wurden in Microsoft JDBC-Treiber 4.0 für SQL Server eingeführt:

  • multiSubnetFailover

  • applicationIntent

Geben Sie immer „multiSubnetFailover=true“ an, wenn Sie eine Verbindung mit dem Verfügbarkeitsgruppenlistener einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz herstellen.

Hinweis

multiSubnetFailover ist standardmäßig auf „false“ festgelegt. Verwenden Sie applicationIntent, um den Workloadtyp der Anwendung zu deklarieren. Weitere Informationen finden Sie in den folgenden Abschnitten.

Ab Version 6.0 des Microsoft-JDBC-Treibers für SQL Server wird die neue Verbindungseigenschaft transparentNetworkIPResolution (TNIR) hinzugefügt, um transparente Verbindungen mit Always On-Verfügbarkeitsgruppen oder mit einem Server zu ermöglichen, dem mehrere IP-Adressen zugeordnet sind. Wenn transparentNetworkIPResolution auf „true“ festgelegt ist, versucht der Treiber, eine Verbindung mit der ersten verfügbaren IP-Adresse herzustellen. Wenn der erste Versuch nicht erfolgreich ist, versucht der Treiber, parallel eine Verbindung mit allen IP-Adressen herzustellen, bis ein Timeout auftritt. Dabei werden alle ausstehenden Verbindungsversuche verworfen, wenn ein Versuch erfolgreich ist.

Hinweis:

  • transparentNetworkIPResolution ist standardmäßig „true“.
  • „transparentNetworkIPResolution“ wird ignoriert, wenn „multiSubnetFailover“ „true“ ist.
  • „transparentNetworkIPResolution“ wird ignoriert, wenn die Datenbankspiegelung verwendet wird.
  • „transparentNetworkIPResolution“ wird ignoriert, wenn mehr als 64 IP-Adressen vorhanden sind.
  • Wenn transparentNetworkIPResolution „true“ ist, verwendet der erste Verbindungsversuch einen Timeoutwert von 500 ms. Alle anderen Verbindungsversuche folgen der gleichen Logik wie beim multiSubnetFailover-Feature.

Hinweis

Wenn Sie Version 4.2 (oder niedriger) des Microsoft-JDBC-Treibers für SQL Server verwenden und multiSubnetFailover auf „false“ festgelegt ist, versucht der Microsoft JDBC-Treiber für SQL Server, eine Verbindung mit der ersten IP-Adresse herzustellen. Wenn Microsoft JDBC-Treiber für SQL Server keine Verbindung mit der ersten IP-Adresse herstellen kann, tritt ein Verbindungsfehler auf. Microsoft JDBC-Treiber für SQL Server versucht nicht, eine Verbindung mit einer der nachfolgenden IP-Adressen herzustellen, die dem Server zugeordnet sind.

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 Verfügbarkeitsgruppenfailovers fehlschlagen kann, empfiehlt sich die Implementierung von Verbindungswiederholungslogik, wodurch im Fall einer fehlgeschlagenen Verbindung bis zur erneuten Verbindung Wiederholungsversuche erfolgen.

Herstellen einer Verbindung mit multiSubnetFailover

Geben Sie immer multiSubnetFailover=true an, wenn Sie eine Verbindung mit dem Verfügbarkeitsgruppenlistener einer SQL Server 2012 (11.x)-Verfügbarkeitsgruppe oder einer SQL Server 2012 (11.x)-Failoverclusterinstanz herstellen. multiSubnetFailover ermöglicht ein schnelleres Failover für alle Verfügbarkeitsgruppen und Failoverclusterinstanzen in SQL Server 2012 (11.x) und verringert die Failoverzeit für Always-On-Topologien mit einem oder mehreren Subnetzen deutlich. Während eines Multisubnetzfailovers versucht der Client Verbindungen parallel. Während eines Subnetz-Failovers unternimmt Microsoft JDBC-Treiber für SQL Server aggressive Wiederholungsversuche zum Herstellen der TCP-Verbindung.

Die multiSubnetFailover-Verbindungseigenschaft gibt an, dass die Anwendung in einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz bereitgestellt wird und Microsoft JDBC-Treiber für SQL Server versucht, eine Verbindung mit der Datenbank auf der primären SQL Server-Instanz herzustellen, indem mit allen IP-Adressen der Verfügbarkeitsgruppe 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. Dieses Verhalten ermöglicht, die Verbindung nach einem Failover einer Always-On-Verfügbarkeitsgruppe oder einer Always-On-Failoverclusterinstanz schneller wiederherzustellen, und gilt sowohl für Einzelsubnetz- als auch Multisubnetz-Verfügbarkeitsgruppen und -Failoverclusterinstanzen.

Weitere Informationen zu Schlüsselwörtern für Verbindungszeichenfolgen im Microsoft JDBC-Treiber für SQL Server finden Sie unter Festlegen der Verbindungseigenschaften.

Das Angeben von multiSubnetFailover=true für ein anderes Verbindungsziel als einen Verfügbarkeitsgruppenlistener oder eine Failoverclusterinstanz kann die Leistung beeinträchtigen und wird nicht unterstützt.

Wenn der Sicherheits-Manager nicht installiert ist, werden virtuelle IP-Adressen (VIPs) von der Java Virtual Machine für einen begrenzten Zeitraum zwischengespeichert. Die jeweilige Dauer wird durch Ihre JDK-Implementierung und die Java-Eigenschaften „networkaddress.cache.ttl“ und „networkaddress.cache.negative.ttl“ bestimmt. Wenn der JDK-Sicherheits-Manager installiert ist, werden VIPs von der Java Virtual Machine zwischengespeichert, und der Cache wird standardmäßig nicht aktualisiert. Es empfiehlt sich die Gültigkeitsdauer, d. h. "time-to-live" (networkaddress.cache.ttl), für den Cache der Java Virtual Machine auf einen Tag festzulegen. Wenn Sie den Standardwert nicht auf einen Tag oder eine ähnliche Einstellung festlegen, wird der alte Wert beim Hinzufügen oder Aktualisieren einer VIP nicht aus dem Java Virtual Machine-Cache gelöscht. Weitere Informationen zu „networkaddress.cache.ttl“ und „networkaddress.cache.negative.ttl“ finden Sie unter https://download.oracle.com/javase/6/docs/technotes/guides/net/properties.html.

Befolgen Sie beim Herstellen einer Verbindung mit einem Server in einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz die folgenden Richtlinien:

  • Der Treiber generiert einen Fehler, wenn die Verbindungseigenschaft instanceName in derselben Verbindungszeichenfolge wie die Verbindungseigenschaft multiSubnetFailover verwendet wird. Dieser Fehler spiegelt den Umstand wider, dass der SQL Browser-Dienst in Verfügbarkeitsgruppen nicht verwendet wird. Wenn jedoch die Verbindungseigenschaft portNumber ebenfalls angegeben wird, ignoriert der Treiber instanceName und verwendet portNumber.

  • Verwenden Sie die multiSubnetFailover-Verbindungseigenschaft, wenn Sie eine Verbindung mit einem oder mehreren Subnetzen herstellen. Dadurch wird die Leistung auf beiden Seiten verbessert.

  • Um eine Verbindung mit einer Verfügbarkeitsgruppe herzustellen, geben Sie in der Verbindungszeichenfolge den Verfügbarkeitsgruppenlistener der Verfügbarkeitsgruppe als Server an. Beispiel: jdbc:sqlserver://VNN1.

  • 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.

  • Erhöhen Sie den Wert von loginTimeout, um die Failoverzeit zu berücksichtigen und Wiederholungsversuche für Anwendungsverbindungen zu reduzieren.

Wenn das schreibgeschützte Routing nicht aktiviert ist, scheitert das Herstellen der Verbindung mit einem sekundären Replikatspeicherort in einer Verfügbarkeitsgruppe 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

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

Aktualisieren zur Verwendung von Multisubnetzclustern aus Datenbankspiegelung

Wenn Sie eine Microsoft JDBC-Treiber für SQL Server-Anwendung aktualisieren, die derzeit Datenbankspiegelung in einem Multisubnetz-Szenario verwendet, müssen Sie die failoverPartner-Verbindungseigenschaft entfernen und durch multiSubnetFailover festgelegt auf TRUE ersetzen sowie den Servernamen in der Verbindungszeichenfolge durch einen Verfügbarkeitsgruppenlistener ersetzen. Wenn eine Verbindungszeichenfolge failoverPartner und multiSubnetFailover=true verwendet, generiert der Treiber einen Fehler. Wenn eine Verbindungszeichenfolge jedoch failoverPartner und multiSubnetFailover=false (oder ApplicationIntent=ReadWrite) verwendet, greift die Anwendung auf Datenbankspiegelung zurück.

Der Treiber gibt einen Fehler zurück, wenn die Datenbankspiegelung in der primären Datenbank in der Verfügbarkeitsgruppe und multiSubnetFailover=true in der Verbindungszeichenfolge verwendet werden, die anstatt mit einem Verfügbarkeitsgruppenlistener eine Verbindung mit einer primären Datenbank herstellt.

Angeben der Anwendungsabsicht

Sie können das Schlüsselwort ApplicationIntent in Ihrer Verbindungszeichenfolge angeben. Es können die Werte ReadWrite (Standard) und ReadOnly zugewiesen werden.

Wenn Sie ApplicationIntent=ReadOnly festlegen, fordert der Client bei der Verbindungsherstellung eine Leseworkload an. Der Server erzwingt die Absicht zur Verbindungszeit und während einer USE-Datenbankanweisung.

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

Ziele von ReadOnly

Wenn eine Verbindung ReadOnly auswählt, wird sie einer der folgenden speziellen Konfigurationen zugewiesen, die für die Datenbank ggf. vorhanden sind:

  • Always On: Eine Datenbank kann Leseworkloads in der Verfügbarkeitsgruppen-Zieldatenbank zulassen bzw. nicht zulassen. Diese Auswahl wird über die ALLOW_CONNECTIONS-Klausel der Transact-SQL-Anweisungen PRIMARY_ROLE und SECONDARY_ROLE gesteuert.

  • Georeplikation

  • Horizontale Leseskalierung

Wenn keins dieser speziellen Ziele verfügbar ist, erfolgt der Lesevorgang in der regulären Datenbank.

Das Schlüsselwort ApplicationIntent ermöglicht schreibgeschütztes Routing.

Schreibgeschütztes Routing

Das schreibgeschützte Routing ist eine Funktion, die die Verfügbarkeit des schreibgeschützten Replikats einer Datenbank sicherstellen kann. Zum Aktivieren des schreibgeschützten Routings gelten sämtliche der folgenden Voraussetzungen:

  • Sie müssen eine Verbindung mit einem Always On-Verfügbarkeitsgruppenlistener herstellen.

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

  • Der Datenbankadministrator muss die Verfügbarkeitsgruppe für das schreibgeschützte Routing konfigurieren.

Mehrere Verbindungen, für die jeweils das schreibgeschützte Routing verwendet wird, werden ggf. nicht alle mit demselben schreibgeschützten Replikat hergestellt. Änderungen in der Datenbanksynchronisierung oder Änderungen in der Routingkonfiguration des Servers können zu Clientverbindungen mit anderen schreibgeschützten Replikaten führen.

Sie können sicherstellen, dass für alle schreibgeschützten Anforderungen eine Verbindung mit demselben schreibgeschützten Replikat hergestellt wird, indem Sie keinen Verfügbarkeitsgruppenlistener an das Verbindungszeichenfolgen-Schlüsselwort Server übermitteln. Geben Sie stattdessen den Namen der schreibgeschützten Instanz an.

Das schreibgeschützte Routing kann ggf. länger als das Herstellen einer Verbindung mit der primären Instanz dauern. Dies liegt daran, dass beim schreibgeschützten Routing zunächst eine Verbindung mit dem primären Replikat hergestellt wird und dann nach dem besten verfügbaren lesbaren sekundären Replikat gesucht wird. Da mehrere Schritte ausgeführt werden, sollten Sie das Timeout für login auf mindestens 30 Sekunden erhöhen.

Verbindungspooling

Beim Verwenden des Microsoft JDBC-Treibers für SQL Server in Kombination mit einer Verbindungspoolbibliothek sollten Sie Folgendes beachten:

  • Wenn Sie schreibgeschütztes Routing sowie einen Pool aus schreibgeschützten Servern konfiguriert haben, über die Sie Last verteilen möchten, wird beim Verbindungspooling die Anzahl von Möglichkeiten für neue Verbindungen zum Verteilen auf die Zielserver reduziert.
  • Wählen Sie Pooloptionen aus, die eine gleichmäßige Verteilung von Verbindungen im Pool unterstützen, um in einem Pool eine hohe Last auf einem einzelnen Server zu vermeiden.
  • Stellen Sie sicher, dass der Verbindungspool mit einer Verbindungslebensdauer konfiguriert ist. Wenn ein schreibgeschütztes Replikat bei einer schreibgeschützten Verbindung nicht verfügbar ist, sollte durch die Konfiguration sichergestellt werden, dass die Verbindung ggf. geschlossen und auf einem schreibgeschützten Replikat neu erstellt wird, sobald ein solches wieder verfügbar ist.

Neue Methoden mit Unterstützung für multiSubnetFailover und applicationIntent

Mit den folgenden Methoden erhalten Sie programmgesteuerten Zugriff auf die Schlüsselwörter multiSubnetFailover, applicationIntent und transparentNetworkIPResolution für Verbindungszeichenfolgen:

Die Methoden getMultiSubnetFailover, setMultiSubnetFailover, getApplicationIntent, setApplicationIntent, getTransparentNetworkIPResolution und setTransparentNetworkIPResolution werden ebenfalls SQLServerDataSource Class, SQLServerConnectionPoolDataSource Class und SQLServerXADataSource Class hinzugefügt.

TLS-/SSL-Zertifikatüberprüfung

Eine Verfügbarkeitsgruppe besteht aus mehreren physischen Servern. Mit Microsoft JDBC-Treiber 4.0 für SQL Server wurde die Unterstützung von Alternativen Antragstellernamen in TLS-/SSL-Zertifikaten eingeführt, sodass einem Zertifikat mehrere Hosts zugeordnet werden können. Weitere Informationen zu TLS finden Sie unter Verstehen der Verschlüsselungsunterstützung.

Weitere Informationen

Verbinden mit SQL Server mit dem JDBC-Treiber
Festlegen von Verbindungseigenschaften