Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Thema wird die Unterstützung von Microsoft-Treiber für PHP für SQL Server (in Version 3.0 hinzugefügt) für Hochverfügbarkeit und Notfallwiederherstellung erläutert.
Ab Version 3.0 der Microsoft-Treiber für PHP für SQL Server können Sie den Verfügbarkeitsgruppenlistener einer Verfügbarkeitsgruppe für Hochverfügbarkeit und Notfallwiederherstellung oder einer Failoverclusterinstanz als Server in der Verbindungszeichenfolge angeben.
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-Instanz ist. Der Treiber versucht, TCP-Verbindungen parallel zu allen aufgelösten IP-Adressen herzustellen und verwendet die erste erfolgreiche Verbindung. Wenn die Anwendung mit einer Datenbank verbunden ist, die ein Failover hat, wird die ursprüngliche Verbindung unterbrochen und die Anwendung muss eine neue Verbindung öffnen, um nach dem Failover weiterzuarbeiten.
Wenn DNS auf eine Adresse aufgelöst wird, erzeugt MultiSubnetFailover=True keine weiteren parallelen Verbindungsversuche, sodass es auf Einzel-IP-Zielen sicher ist.
Die Treiber akzeptieren auf jeden Fall True, 1 oder Yes und geben die Option an den zugrundeliegenden ODBC-Treiber weiter. Sie behandeln jeden anderen Wert als Falsch, ohne einen Fehler zu melden, sodass ein falsch geschriebener Wert die Option stillschweigend deaktiviert.
MultiSubnetFailover hat folgende Grenzen:
Du kannst es nicht über ein anderes Protokoll als TCP verwenden.
Die Verbindung zu einer SQL Server-Instanz, die mit mehr als 64 IP-Adressen konfiguriert ist, schlägt fehl.
Man kann es nicht mit Datenbankspiegelung verwenden. Lege dies nicht fest, wenn die Verbindungszeichenfolge ebenfalls Failover_Partner verwendet oder wenn du statt mit einem Availability Group Listener eine Verbindung mit einer primären Replik herstellst. Weitere Informationen finden Sie unter Aktualisieren auf die Verwendung von Multi-Subnetz-Clustern anstelle von Datenbankspiegelung.
Für Azure SQL-Datenbank serverlos mit aktivierter automatischer Pause, wenn du LoginTimeout einstellst, nutze mindestens 60 Sekunden. Eine automatisch pausierte Datenbank wird beim ersten Verbindungsversuch fortgesetzt, und dieser Versuch kann mit dem Fehler 40613 fehlschlagen, während die Datenbank fortgesetzt wird, sodass die Anwendung einen neuen Versuch machen muss. Weitere Informationen finden Sie unter Auto-pause und Auto-resume.
Weitere Informationen zu den Always On-Verfügbarkeitsgruppen finden Sie unter Was ist eine Always On Verfügbarkeitsgruppe?
Transparente Netzwerk-IP-Auflösung (TNIR)
Transparent Network IP Resolution (TNIR) ist der veraltete Multi-IP-Fallback des ODBC-Treibers, gesteuert durch die Verbindungsoption TransparentNetworkIPResolution und standardmäßig aktiviert.
Befolge die Anweisungen im vorherigen Abschnitt und setze MultiSubnetFailover=True für die dort aufgeführten Ziele. Wenn MultiSubnetFailover=True ist, versucht der Treiber gleichzeitig TCP-Verbindungen zu allen gelösten IP-Adressen. Die Option TransparentNetworkIPResolution beeinflusst die Verbindungsreihenfolge nicht, daher musst du sie nicht festlegen oder in der Verbindungszeichenfolge berücksichtigen.
Für die vollständige TNIR- und MultiSubnetFailover-Interaktionsreferenz siehe Verwendung der transparenten Netzwerk-IP-Auflösung mit dem ODBC-Treiber.
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 PHP-Anwendung aktualisieren, die derzeit Datenbankspiegelung auf ein Multi-Subnet-Szenario verwendet, entfernen Sie die Failover_Partner Connection-Eigenschaft und ersetzen Sie sie durch MultiSubnetFailover , die auf True eingestellt ist. Ersetzen Sie den Servernamen in der Verbindungszeichenfolge durch einen Availability Group Listener. Wenn ein Verbindungszeichenfolge Failover_Partner verwendet und MultiSubnetFailover=True, erzeugt der Treiber einen Fehler. Wenn jedoch ein Verbindungszeichenfolge Failover_Partner und MultiSubnetFailover=False (oder ApplicationIntent=ReadWrite) verwendet, verwendet die Anwendung Datenbankspiegelung.
Der Treiber gibt einen Fehler zurück, wenn Sie Datenbankspiegelung auf der primären Replik in der Verfügbarkeitsgruppe verwenden und wenn Sie MultiSubnetFailover=True in der Verbindungszeichenfolge verwenden, die sich mit einem primären Replikat statt mit einem Availability Group Listener verbindet.
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-AnweisungenPRIMARY_ROLEundSECONDARY_ROLEgesteuert.
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 aufReadOnlyfestgelegt 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.