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

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 Anwendung, die den Microsoft JDBC-Treiber für SQL Server verwendet, mit einer Always-On-Datenbank verbunden ist, bei der ein Failover auftritt, wird die ursprüngliche Verbindung unterbrochen, und die Anwendung muss eine neue Verbindung öffnen, um die Arbeit nach dem Failover fortzusetzen. Die folgenden Verbindungseigenschaften wurden in Microsoft JDBC-Treiber 4.0 für SQL Server eingeführt:

  • multiSubnetFailover

  • applicationIntent

Setze multiSubnetFailover=true, wenn das Ziel Azure SQL-Datenbank, Azure SQL Managed Instance, SQL Database in Microsoft Fabric, ein Availability Group Listener oder eine Failover Cluster Instance ist.

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 zutrifft, verwendet der erste Verbindungsversuch einen Timeout-Wert von 500 Millisekunden. Die übrigen Verbindungsversuche folgen derselben Logik wie die multiSubnetFailover-Funktion.

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. Außerdem kann eine Verbindung aufgrund eines Failovers einer Verfügbarkeitsgruppe fehlschlagen. Daher sollten Sie eine Logik für Verbindungswiederholungen implementieren, indem Sie eine fehlgeschlagene Verbindung so lange erneut versuchen, bis sie wiederhergestellt ist.

Verbindung mit multiSubnetFailover herstellen

Geben Sie immer multiSubnetFailover=true an, wenn das Ziel Azure SQL-Datenbank, Azure SQL Managed Instance, eine SQL-Datenbank in Microsoft Fabric, ein Verfügbarkeitsgruppenlistener einer SQL Server 2012 (11.x)-Verfügbarkeitsgruppe oder eine SQL Server 2012 (11.x)-Failoverclusterinstanz ist.

Wenn der Servername in deiner Verbindungszeichenfolge auf mehr als eine IP-Adresse aufgelöst wird, sorgt multiSubnetFailover=true dafür, dass der Microsoft JDBC-Treiber für SQL Server gleichzeitig Verbindungen zu allen Adressen öffnet und die erste verwendet, die antwortet. Ohne sie greift der Treiber auf Transparent Network IP Resolution (TNIR) zurück, die standardmäßig aktiviert ist. TNIR versucht eine einzelne Adresse mit einem 500-Millisekunden-Timeout und öffnet Verbindungen zu allen gelösten Adressen erst beim nächsten Versuch. Wenn du auch transparentNetworkIPResolution=false setzt, versucht der Treiber eine einzelne Adresse mit dem vollen LoginTimeout und die anderen nie, sodass eine Verbindung, die gegen eine andere Adresse erfolgreich sein würde, stattdessen fehlschlägt. Nachdem ein Failover die Datenbank auf eine Replik an einer anderen Adresse verlegt, erreicht multiSubnetFailover=true beim ersten Versuch die neue Adresse.

multiSubnetFailover=true ändert, wie schnell der Client das Replikat findet, das die Datenbank bedient. Es ändert nichts, wie lange der Server zum Failover braucht.

multiSubnetFailover=true ist bei Zielsystemen mit nur einer IP-Adresse sicher. Wenn DNS auf eine einzige Adresse aufgelöst wird, versucht der Treiber eine einzige Verbindung und startet keine parallelen Verbindungsthreads, sodass die Einstellung nichts kostet, wenn sie nicht benötigt wird.

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

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

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

  • Setze die multiSubnetFailover-Verbindungseigenschaft auf true.

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

  • Du kannst die instanceName-Connection-Eigenschaft zusammen mit multiSubnetFailover verwenden. Der Treiber befragt den SQL-Browser unter jeder aufgelösten Adresse, um den Port für die Instanz zu ermitteln. Wenn du auch portNumber angibst, verwendet der Treiber portNumber und fragt den SQL-Browser nicht ab.

  • Die Verbindung zu einer SQL Server-Instanz, die mit mehr als 64 IP-Adressen konfiguriert ist, schlägt fehl. Der Treiber behandelt es als nicht unterstützte Konfiguration und versucht die Verbindung nicht erneut.

  • MultiSubnetFailover mit Datenbankspiegelung kann man nicht verwenden. Der Treiber liefert einen Fehler, wenn die Verbindungszeichenfolge failoverPartner angibt, und auch wenn der Server einen Failover-Partner zurückgibt. Datenbankspiegelung ist in allen unterstützten Versionen von SQL Server veraltet. Verwenden Sie stattdessen Always On-Verfügbarkeitsgruppen.

  • 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 der Failover-Zeit Rechnung zu tragen und die Anzahl der Wiederholungsversuche der Anwendungsverbindung zu verringern. Für serverlose Azure SQL-Datenbanken mit aktiviertem AutoAnhalten muss loginTimeout außerdem lang genug sein, um die Verbindungswiederholversuche des Treibers abzudecken. Weitere Informationen finden Sie unter Verbinden mit einer automatisch pausierten serverlosen Datenbank.

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 (später in diesem Artikel beschrieben) und der sekundäre Replikastandort für den Nur-Lesezugriff konfiguriert ist.

Eine Verbindung schlägt fehl, wenn ein primäres Replikat so konfiguriert ist, dass es schreibgeschützte Workloads ablehnt und die Verbindungszeichenfolge ApplicationIntent=ReadOnly enthält.

Upgrade von der Datenbankspiegelung auf die Verwendung von Clustern mit mehreren Subnetzen

Wenn Sie eine Anwendung, die derzeit den Microsoft JDBC-Treiber für SQL Server mit Datenbankspiegelung verwendet, auf ein Multisubnetz-Szenario umstellen, sollten Sie die Verbindungseigenschaft failoverPartner entfernen, sie durch multiSubnetFailover mit dem Wert true ersetzen und 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 Sie Datenbankspiegelung auf der primären Replik in der AG verwenden und wenn Sie multiSubnetFailover=true in der Verbindungszeichenfolge verwenden, die eine Verbindung mit einer primären Replik statt mit einem Listener der Verfügbarkeitsgruppe 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 Vorgabe beim Verbindungsaufbau 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.

Verwandte Inhalte

  • Zuletzt aktualisiert um