SQL Server Native Client-Unterstützung für hohe Verfügbarkeit, Notfallwiederherstellung
In diesem Thema wird die (in SQL Server 2012 eingeführte) SQL Server Native Client-Unterstützung für AlwaysOn-Verfügbarkeitsgruppen erläutert. Weitere Informationen zu AlwaysOn-Verfügbarkeitsgruppen finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server), Erstellung und Konfiguration von Verfügbarkeitsgruppen (SQL Server), Failoverclustering und AlwaysOn-Verfügbarkeitsgruppen (SQL Server) und Aktive sekundäre Replikate: Lesbare sekundäre Replikate (AlwaysOn-Verfügbarkeitsgruppen).
Sie können den Verfügbarkeitsgruppenlistener einer bestimmten Verfügbarkeitsgruppe in der Verbindungszeichenfolge angeben. Wenn eine SQL Server Native Client-Anwendung mit einer Datenbank in einer Verfügbarkeitsgruppe verbunden ist, die ein Failover ausführt, wird die ursprüngliche Verbindung unterbrochen, und die Anwendung muss eine neue Verbindung öffnen, um die Arbeit nach dem Failover fortzusetzen.
Wenn Sie keine Verbindung mit einem Verfügbarkeitsgruppenlistener herstellen, und wenn mehrere IP-Adressen einem Hostnamen zugeordnet sind, durchläuft SQL Server Native Client alle dem DNS-Eintrag zugeordneten IP-Adressen sequenziell. Dies kann zeitaufwändig sein, wenn die erste vom DNS-Server zurückgegebene IP-Adresse an keine Netzwerkschnittstellenkarte (NIC) gebunden ist. Wenn eine Verbindung mit einem Verfügbarkeitsgruppenlistener hergestellt wird, versucht SQL Server Native Client, Verbindungen mit allen IP-Adressen parallel herzustellen. Wenn ein Verbindungsversuch erfolgreich ist, verwirft der Treiber alle ausstehenden Verbindungsversuche.
.gif "Hinweis") 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. |
Verbinden mit MultiSubnetFailover
Geben Sie immer MultiSubnetFailover=Yes an, wenn Sie eine Verbindung mit einem SQL Server 2012-Verfügbarkeitsgruppenlistener oder einer SQL Server 2012-Failoverclusterinstanz herstellen. MultiSubnetFailover aktiviert schnelleres Failover für alle Verfügbarkeitsgruppen und die Failoverclusterinstanz in SQL Server 2012 und reduziert die Failoverzeit für einzelne und Multisubnetz-AlwaysOn-Topologien erheblich. Während eines Multisubnetzfailovers versucht der Client Verbindungen parallel. Während eines Subnetzfailovers wird der TCP-Verbindungsversuch vom SQL Server-Native Client aggressiv wiederholt.
Die MultiSubnetFailover-Verbindungseigenschaft gibt an, dass die Anwendung in einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz bereitgestellt wird und SQL Server Native Client 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=Yes 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. Auf diese Weise kann die Verbindung nach einem Failover einer AlwaysOn-Verfügbarkeitsgruppe oder einer AlwaysOn-Failoverclusterinstanz schneller wiederhergestellt werden. Diese Einstellung gilt sowohl für Einzelsubnetz- als auch Multisubnetz-Verfügbarkeitsgruppen und -Failoverclusterinstanzen.
Weitere Informationen zu Verbindungszeichenfolgeschlüsselwörtern finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit SQL Server Native Client.
Das Angeben von MultiSubnetFailover=Yes für ein anderes Verbindungsziel als einen Verfügbarkeitsgruppenlistener oder eine Failoverclusterinstanz kann die Leistung beeinträchtigen und wird nicht unterstützt.
Befolgen Sie beim Herstellen einer Verbindung mit einem Server in einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz die folgenden Richtlinien:
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 in der Verbindungszeichenfolge den Verfügbarkeitsgruppenlistener der Verfügbarkeitsgruppe als Server 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.
Sie können den Wert von loginTimeout erhöhen, um die Failoverzeit zu berücksichtigen und Wiederholungsversuche für Anwendungsverbindungen zu reduzieren.
Verteilte Transaktionen werden nicht unterstützt.
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=ReadOnly enthält.
Aktualisieren zur Verwendung von Multisubnetzclustern aus Datenbankspiegelung
Ein Verbindungsfehler tritt auf, wenn die Verbindungsschlüsselwörter MultiSubnetFailover und Failover_Partner in der Verbindungszeichenfolge vorhanden sind. Es tritt auch ein Fehler auf, wenn MultiSubnetFailover verwendet wird und SQL Server eine Failoverpartnerantwort zurückgibt, die angibt, dass es Teil eines Datenbankspiegelungspaars ist.
Wenn Sie eine SQL Server Native Client-Anwendung aktualisieren, die derzeit Datenbankspiegelung in einem Multisubnetz-Szenario verwendet, müssen Sie die Failover_Partner-Verbindungseigenschaft entfernen und mit MultiSubnetFailover, festgelegt auf Yes, ersetzen, sowie den Servernamen in der Verbindungszeichenfolge mit einem Verfügbarkeitsgruppenlistener ersetzen. Wenn eine Verbindungszeichenfolge Failover_Partner und MultiSubnetFailover=Yes verwendet, generiert der Treiber einen Fehler. Wenn eine Verbindungszeichenfolge jedoch Failover_Partner und MultiSubnetFailover=No (oder ApplicationIntent=ReadWrite) verwendet, verwendet die Anwendung Datenbankspiegelung.
Der Treiber gibt einen Fehler zurück, wenn die Datenbankspiegelung in der primären Datenbank in der Verfügbarkeitsgruppe verwendet wird, und wenn MultiSubnetFailover=Yes in der Verbindungszeichenfolge verwendet wird, die statt mit einem Verfügbarkeitsgruppenlistener eine Verbindung mit einer primären Datenbank herstellt.
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 PRIMARY_ROLE- und SECONDARY_ROLE Transact-SQL-Anweisungen.)
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:
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 Server-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.
ODBC
Zur Unterstützung von AlwaysOn-Verfügbarkeitsgruppen wurden in SQL Server Native Client zwei Schlüsselwörter für ODBC-Verbindungszeichenfolgen hinzugefügt:
ApplicationIntent
MultiSubnetFailover
Weitere Informationen zu den Schlüsselwörtern für ODBC-Verbindungszeichenfolgen, die in SQL Server Native Client unterstützt werden, finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit SQL Server Native Client.
Die entsprechenden Verbindungseigenschaften sind:
SQL_COPT_SS_APPLICATION_INTENT
SQL_COPT_SS_MULTISUBNET_FAILOVER
Weitere Informationen zu den ODBC-Verbindungseigenschaften in SQL Server Native Client finden Sie unter SQLSetConnectAttr.
Die Funktionalität des ApplicationIntent- und des MultiSubnetFailover-Schlüsselworts wird ab SQL Server 2012 im ODBC-Datenquellen-Administrator für DSNs verfügbar gemacht, die den SQL Server Native Client-Treiber verwenden.
Eine SQL Server Native Client-ODBC-Anwendung kann eine von drei Funktionen verwenden, um die Verbindung herzustellen:
Funktion |
Beschreibung |
|---|---|
Die Liste der Server, die von SQLBrowseConnect zurückgegeben wird, schließt keine VNNs ein. Sie sehen nur eine Liste von Servern ohne Angabe, ob es sich bei dem Server um einen eigenständigen Server oder einen primären oder sekundären Server in einem WSFC-Cluster (Windows Server-Failoverclustering) handelt. der zwei oder mehr SQL Server-Instanzen enthält, die für AlwaysOn-Verfügbarkeitsgruppen aktiviert wurden. Wenn Sie eine Verbindung mit einem Server herstellen, und es wird ein Fehler angezeigt, kann dies daran liegen, dass Sie eine Verbindung mit einem Server hergestellt haben und die Einstellung ApplicationIntent nicht mit der Serverkonfiguration kompatibel ist. Da SQLBrowseConnect keine Server in einem WSFC-Cluster (Windows Server-Failoverclustering) erkennt, der zwei oder mehr SQL Server-Instanzen enthält, die für AlwaysOn-Verfügbarkeitsgruppen aktiviert wurden, ignoriert SQLBrowseConnect das Schlüsselwort für die MultiSubnetFailover-Verbindungszeichenfolge. |
|
SQLConnect unterstützt sowohl ApplicationIntent als auch MultiSubnetFailover über einen Datenquellennamen (DSN) oder Verbindungseigenschaften. |
|
SQLDriverConnect unterstützt ApplicationIntent und MultiSubnetFailover über Schlüsselwörter für Verbindungszeichenfolgen, Verbindungseigenschaften oder DSN. |
OLE DB
OLE DB im SQL Server Native Client unterstützt das MultiSubnetFailover-Schlüsselwort nicht.
OLE DB im SQL Server Native Client unterstützt Anwendungsabsicht. Die Anwendungsabsicht verhält sich für OLE DB-Anwendungen und ODBC-Anwendungen gleiche (siehe oben).
Zur Unterstützung von AlwaysOn-Verfügbarkeitsgruppen wurde in SQL Server Native Client ein Schlüsselwort für OLE-Verbindungszeichenfolgen hinzugefügt:
- Application Intent
Weitere Informationen zu den Schlüsselwörtern für Verbindungszeichenfolgen, die in SQL Server Native Client unterstützt werden, finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit SQL Server Native Client.
Die entsprechenden Verbindungseigenschaften sind:
SSPROP_INIT_APPLICATIONINTENT
DBPROP_INIT_PROVIDERSTRING
Eine SQL Server Native Client-OLE DB-Anwendung kann eine der folgenden Methoden zum Angeben der Anwendungsabsicht verwenden:
IDBInitialize::Initialize
IDBInitialize::Initialize verwendet den zuvor konfigurierten Satz von Eigenschaften, um die Datenquelle zu initialisieren und das Datenquellenobjekt zu erstellen. Geben Sie die Anwendungsabsicht als Anbietereigenschaft oder als einen Teil der erweiterten Eigenschaftenzeichenfolge an.IDataInitialize::GetDataSource
IDataInitialize::GetDataSource verwendet eine Eingabeverbindungszeichenfolge, die das Application Intent-Schlüsselwort enthalten kann.IDBProperties::GetProperties
IDBProperties::GetProperties ruft den Wert der Eigenschaft ab, die derzeit in der Datenquelle festgelegt wird. Sie können den Application Intent-Wert über die DBPROP_INIT_PROVIDERSTRING-Eigenschaft und die SSPROP_INIT_APPLICATIONINTENT-Eigenschaft abrufen.IDBProperties::SetProperties
Um den ApplicationIntent-Eigenschaftswert festzulegen, rufen Sie IDBProperties::SetProperties auf, indem Sie die SSPROP_INIT_APPLICATIONINTENT-Eigenschaft mit dem Wert "ReadWrite" oder "ReadOnly" oder die DBPROP_INIT_PROVIDERSTRING-Eigenschaft mit dem Wert angeben, der "ApplicationIntent=ReadOnly" oder "ApplicationIntent=ReadWrite" enthält.
Sie können die Anwendungsabsicht im Feld für die Eigenschaften der Anwendungsabsicht auf der Registerkarte Alle im Dialogfeld Datenverknüpfungseigenschaften angeben.
Wenn implizite Verbindungen hergestellt werden, verwendet die implizite Verbindung die Einstellung der Anwendungsabsicht der übergeordneten Verbindung. Auf ähnliche Weise erben mehrere aus der gleichen Datenquelle erstellte Sitzungen die Einstellung für die Anwendungsabsicht der Datenquelle.
Siehe auch
Konzepte
Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit SQL Server Native Client