Unterstützung für hohe Verfügbarkeit bei Notfallwiederherstellung
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.
Die Verbindungseigenschaft MultiSubnetFailover gibt an, dass die Anwendung in einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz bereitgestellt wird und dass der Treiber versucht, eine Verbindung mit der Datenbank auf der primären SQL Server-Instanz herzustellen, indem er Verbindungsversuche mit allen IP-Adressen unternimmt. Geben Sie immer MultiSubnetFailover=true an, wenn Sie eine Verbindung mit einem SQL Server-Verfügbarkeitsgruppenlistener oder einer SQL Server-Failoverclusterinstanz herstellen. Wenn die 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.
Ausführliche Informationen zu Always On-Verfügbarkeitsgruppen finden Sie auf der Dokumentationsseite Hochverfügbarkeit und Notfallwiederherstellung.
Transparente Netzwerk-IP-Auflösung (TNIR)
Die transparente Netzwerk-IP-Adressauflösung (Transparent Network IP Resolution, TNIR) ist eine Überarbeitung des vorhandenen MultiSubnetFailover-Features. Sie wirkt sich auf die Verbindungssequenz des Treibers aus, wenn die erste aufgelöste IP-Adresse des Hostnamens nicht reagiert und dem Hostnamen mehrere IP-Adressen zugeordnet sind. Die entsprechende Verbindungsoption lautet TransparentNetworkIPResolution. Zusammen mit MultiSubnetFailover stellt diese Option die folgenden vier Verbindungssequenzen bereit:
- TNIR aktiviert und MultiSubnetFailover deaktiviert: Eine IP-Adresse wird ausprobiert, danach werden alle IP-Adressen gleichzeitig ausprobiert.
- TNIR aktiviert und MultiSubnetFailover aktiviert: Alle IP-Adressen werden gleichzeitig ausprobiert.
- TNIR deaktiviert und MultiSubnetFailover deaktiviert: Alle IP-Adressen werden nacheinander ausprobiert.
- TNIR deaktiviert und MultiSubnetFailover aktiviert: Alle IP-Adressen werden gleichzeitig ausprobiert.
TNIR ist standardmäßig aktiviert, MultiSubnetFailover ist standardmäßig deaktiviert.
Im Folgenden sehen Sie ein Beispiel für die Aktivierung sowohl von TNIR als auch von MultiSubnetFailover mit dem PDO_SQLSRV-Treiber:
<?php
$serverName = "yourservername";
$username = "yourusername";
$password = "yourpassword";
$connectionString = "sqlsrv:Server=$serverName; TransparentNetworkIPResolution=Enabled; MultiSubnetFailover=yes";
try {
$conn = new PDO($connectionString, $username, $password, array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));
// your code
// more of your code
// when done, close the connection
unset($conn);
} catch(PDOException $e) {
print_r($e->errorInfo);
}
?>
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 ein Upgrade einer PHP-Anwendung ausführen, die derzeit die Datenbankspiegelung in einem Szenario mit mehreren Subnetzen verwendet, entfernen Sie die Verbindungseigenschaft Failover_Partner, und ersetzen Sie sie durch MultiSubnetFailover, festgelegt auf True. Ersetzen Sie außerdem den Servernamen in der Verbindungszeichenfolge durch einen Verfügbarkeitsgruppenlistener. Wenn eine Verbindungszeichenfolge Failover_Partner und MultiSubnetFailover=trueverwendet, generiert der Treiber einen Fehler. Wenn eine Verbindungszeichenfolge jedoch Failover_Partner und MultiSubnetFailover=false (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=true in der Verbindungszeichenfolge verwendet wird, die statt 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-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.