Hochverfügbarkeit und Notfallwiederherstellung unter Linux und macOS

ODBC-Treiber herunterladen

Die ODBC-Treiber für Linux und macOS unterstützen Always On-Verfügbarkeitsgruppen. Weitere Informationen zu Always On-Verfügbarkeitsgruppen:

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

• Erstellung und Konfiguration von Verfügbarkeitsgruppen (SQL Server)

• Failoverclustering und Always On-Verfügbarkeitsgruppen (SQL Server)

• Aktive sekundäre Replikate: Lesbare sekundäre Replikate (Always On-Verfügbarkeitsgruppen)

Sie können den Verfügbarkeitsgruppenlistener einer bestimmten Verfügbarkeitsgruppe in der Verbindungszeichenfolge angeben. Falls eine ODBC-Anwendung unter Linux oder macOS mit einer Datenbank in einer Verfügbarkeitsgruppe verbunden ist, für die ein Failover ausgeführt wird, wird die ursprüngliche Verbindung getrennt. Die Anwendung muss eine neue Verbindung herstellen, um nach dem Failover weiterarbeiten zu können.

Die ODBC-Treiber unter Linux und macOS durchlaufen sequenziell alle IP-Adressen, die einem DNS-Hostnamen zugeordnet wurden, wenn Sie keine Verbindung mit einem Verfügbarkeitsgruppenlistener herstellen. Diese Iterationen können zeitaufwendig sein, falls die erste vom DNS-Server zurückgegebene IP-Adresse nicht verbunden werden kann.

Wenn Sie eine Verbindung mit einem Verfügbarkeitsgruppenlistener herstellen, versucht der Treiber, mit allen IP-Adressen parallel Verbindungen herzustellen. Falls ein Verbindungsversuch erfolgreich war, bricht der Treiber alle weiteren laufenden Verbindungsversuche ab.

Hinweis

Da es für eine Verbindung aufgrund eines Failovers einer Verfügbarkeitsgruppe zu einem Fehler kommen kann, sollten Sie eine Wiederholungslogik für Verbindungen implementieren. Führen Sie für eine getrennte Verbindung so lange Wiederholungsversuche durch, bis sie wiederhergestellt wurde. Die Erhöhung des Verbindungstimeouts sowie die Implementierung einer Verbindungswiederholungslogik erhöhen die Chance auf die Verbindungsherstellung mit einer Verfügbarkeitsgruppe.

Herstellen einer Verbindung mit MultiSubnetFailover

Geben Sie immer MultiSubnetFailover=Yes an, wenn Sie eine Verbindung mit einem SQL Server 2012 (11.x)-Verfügbarkeitsgruppenlistener oder einer SQL Server 2012 (11.x)-Failoverclusterinstanz herstellen. MultiSubnetFailover ermöglicht für alle Verfügbarkeitsgruppen und Failoverclusterinstanzen in SQL Server 2012 (11.x) ein schnelleres Failover.

Mit dieser Verbindungseigenschaft wird auch die Failoverzeit für Always On-Topologien mit einem oder mehreren Subnetzen erheblich reduziert. Während eines Multisubnetz-Failovers versucht der Client, Verbindungen parallel herzustellen. Während eines Subnetzfailovers versucht der Treiber energisch, die TCP-Verbindung wiederherzustellen.

Die MultiSubnetFailover-Verbindungseigenschaft zeigt an, dass die Anwendung in einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz bereitgestellt wird. Der Treiber versucht, sich mit der Datenbank auf der primären SQL Server-Instanz zu verbinden, indem er versucht, sich mit allen IP-Adressen zu verbinden.

Wenn Sie eine Verbindung mit MultiSubnetFailover=Yes herstellen, wiederholt der Client TCP-Verbindungsversuche schneller, als dies bei den standardmäßigen TCP-Neuübertragungsintervallen des Betriebssystems der Fall ist. MultiSubnetFailover=Yes ermöglicht eine schnellere Verbindungswiederherstellung nach dem Failover einer Always On-Verfügbarkeitsgruppe oder einer Always On-Failoverclusterinstanz. MultiSubnetFailover=Yes gilt sowohl für Verfügbarkeitsgruppen und Failoverclusterinstanzen mit nur einem Subnetz als auch mit mehreren Subnetzen.

Verwenden Sie MultiSubnetFailover=Yes, wenn Sie eine Verbindung mit einem Verfügbarkeitsgruppenlistener oder einer Failoverclusterinstanz herstellen. Andernfalls kann die Leistung Ihrer Anwendung negativ beeinträchtigt werden.

Empfehlungen

Gehen Sie wie folgt vor, wenn Sie eine Verbindung mit einem Server in einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz herstellen:

• Geben Sie MultiSubnetFailover=Yes an, um die Leistung bei der Verbindungsherstellung mit einem einzelnen Subnetz oder einer Verfügbarkeitsgruppe mit mehreren Subnetzen zu verbessern.

• Geben Sie in der Verbindungszeichenfolge den Verfügbarkeitsgruppenlistener der Verfügbarkeitsgruppe als Server an.

• Sie können keine Verbindung mit einer SQL Server-Instanz herstellen, die mit mehr als 64 IP-Adressen konfiguriert ist.

• Sowohl die SQL Server-Authentifizierung als auch die Kerberos-Authentifizierung können mit MultiSubnetFailover=Yes verwendet werden, ohne dass dies das Verhalten der Anwendung beeinträchtigt.

• Sie können den Wert von loginTimeout erhöhen, um die Failoverzeit zu berücksichtigen und die Wiederholungsversuche für die Verbindungsherstellung der Anwendung zu reduzieren.

• Verteilte Transaktionen werden nicht unterstützt.

Wenn das schreibgeschützte Routing nicht aktiviert ist, kann in den folgenden Situationen keine Verbindung mit einem sekundären Replikatspeicherort in einer Verfügbarkeitsgruppe hergestellt werden:

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

• Wenn eine Anwendung ApplicationIntent=ReadWrite verwendet 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 Workloads abgelehnt werden, und die Verbindungszeichenfolge ApplicationIntent=ReadOnly enthält.

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.

ODBC-Syntax

Zwei ODBC-Verbindungszeichenfolgen-Schlüsselwörter unterstützen Always On-Verfügbarkeitsgruppen:

• ApplicationIntent

• MultiSubnetFailover

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

Die entsprechende Verbindungsattribute sind die folgenden:

• SQL_COPT_SS_APPLICATION_INTENT

• SQL_COPT_SS_MULTISUBNET_FAILOVER

Weitere Informationen zu den ODBC-Verbindungsattributen finden Sie unter SQLSetConnectAttr.

Eine ODBC-Anwendung, für die Always On-Verfügbarkeitsgruppen verwendet werden, kann eine von zwei Funktionen nutzen, um die Verbindung herzustellen:

Funktion	BESCHREIBUNG
SQLConnect-Funktion	SQLConnect unterstützt sowohl ApplicationIntent als auch MultiSubnetFailover über einen Datenquellennamen (DSN) oder ein Verbindungsattribut.
SQLDriverConnect-Funktion	SQLDriverConnect unterstützt ApplicationIntent und MultiSubnetFailover per DSN, Verbindungszeichenfolgen-Schlüsselwort oder Verbindungsattribut.

Siehe auch

Schlüsselwörter für Verbindungszeichenfolgen und Datenquellennamen (DSNs)

Programmierrichtlinien

Anmerkungen zu dieser Version