Magas rendelkezésre állás, vészhelyreállítás támogatása

PHP-illesztőprogram letöltése

Ez a témakör ismerteti a Microsoft PHP SQL Server-illesztőprogramok támogatását a magas rendelkezésre állás és a vészhelyreállítás tekintetében (hozzáadva a 3.0-s verzióban).

A Microsoft Drivers for PHP for SQL Server 3.0-s verziójától kezdve a kapcsolati sztringben megadhatja egy magas rendelkezésre állású, vészhelyreállítási csoport figyelőjét vagy egy feladatátvételi fürtpéldányt kiszolgálóként.

A MultiSubnetFailover kapcsolati tulajdonság azt jelzi, hogy az alkalmazás egy rendelkezésre állási csoportban vagy feladatátvevőfürt-példányban van üzembe helyezve, és az illesztőprogram megpróbál csatlakozni az elsődleges SQL Server-példány adatbázisához úgy, hogy megpróbál csatlakozni az összes IP-címhez. Mindig állítsa be a MultiSubnetFailover=True értéket, ha SQL Server rendelkezésre állási csoportfigyelőhöz vagy SQL Server feladatátvevőfürt-példányhoz csatlakozik. Ha az alkalmazás egy Always On-adatbázishoz csatlakozik, amely meghiúsul, az eredeti kapcsolat megszakadt, és az alkalmazásnak új kapcsolatot kell megnyitnia a feladatátvétel utáni működés folytatásához.

Az Always On rendelkezésre állási csoportokkal kapcsolatos részletes információk a Magas rendelkezésre állás, Vészhelyreállítási dokumentumok lapon találhatók.

Transzparens hálózati IP-felbontás (TNIR)

A transzparens hálózati IP-feloldás (TNIR) a meglévő MultiSubnetFailover funkció felülvizsgálata. Ez befolyásolja az illesztőprogram kapcsolódási sorrendjét, ha a gazdagépnév első feloldott IP-címe nem válaszol, és több IP-cím is kapcsolódik a gazdagépnévhez. A megfelelő kapcsolati lehetőség a TransparentNetworkIPResolution. A MultiSubnetFailoverrel együtt a következő négy kapcsolati sorozatot biztosítja:

• TNIR Enabled és MultiSubnetFailover Disabled: Először egy IP-cím próbálatos, majd az összes IP-címet párhuzamosan próbálják meg
• TNIR Engedélyezve & MultiSubnetFailover Engedélyezve: Minden IP-cím párhuzamosan kerül megkísérlésre
• A rendszer egymás után próbál meg minden IP-címet, amikor TNIR és MultiSubnetFailover le van tiltva.
• TNIR kikapcsolva, és MultiSubnetFailover bekapcsolva: Minden IP-címet párhuzamosan kísérel megpróbálni.

A TNIR alapértelmezés szerint engedélyezve van, a MultiSubnetFailover pedig alapértelmezés szerint le van tiltva.

Ez egy példa a TNIR és a MultiSubnetFailover engedélyezésére a PDO_SQLSRV illesztőprogram használatával:

<?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);
}
?>

Frissítés a többhálózati klaszterek használatára az adatbázis tükrözésből

Kapcsolati hiba akkor jelentkezik, ha a MultiSubnetFailover és Failover_Partner kapcsolat kulcsszavak jelen vannak a kapcsolati láncban. Hiba akkor is előfordulhat, ha MultiSubnetFailover használ, és az SQL Server egy biztonsági partner választ ad, amely jelzi, hogy az adatbázis tükröző pár része.

Ha egy olyan PHP-alkalmazást frissít, amely jelenleg adatbázis-tükrözést használ több alhálózatos forgatókönyvre, távolítsa el a Failover_Partner kapcsolattulajdonságot, és cserélje le a MultiSubnetFailover értéke True értékre, és cserélje le a kapcsolati sztring kiszolgálónevét egy rendelkezésre állási csoport figyelőjével. Ha egy kapcsolati karakterlánc Failover_Partner és MultiSubnetFailover=true értéket használ, az illesztőprogram hibát fog generálni. Ha azonban egy kapcsolati sztring a Failover_Partner és a MultiSubnetFailover=false (vagy ApplicationIntent=ReadWrite) paramétereket használja, az alkalmazás adatbázis-tükrözést fog alkalmazni.

Az illesztő hibát jelez, ha az adatbázis tükrözését az AG elsődleges adatbázisán alkalmazzák, és a MultiSubnetFailover=true értéket használják a kapcsolat karakterláncban, amely közvetlenül az elsődleges adatbázishoz csatlakozik, ahelyett, hogy a rendelkezésre állási csoport figyelőjén keresztül történne a kapcsolódás.

Megadjuk az alkalmazás szándékát

Megadhatod a kulcsszót ApplicationIntent a kapcsolati láncodban. A hozzárendelhető értékek ReadWrite (az alapértelmezett) vagy ReadOnly.

Amikor beállítod ApplicationIntent=ReadOnly, az ügyfél olvasási munkaterhelést kér a csatlakozáskor. A szerver a szándékot érvényesíti a csatlakozás idején, illetve egy USE adatbázis-kijelentés alatt.

A ApplicationIntent kulcsszó nem működik a régi csak olvasható adatbázisokban.

ReadOnly célpontjai

Amikor egy kapcsolat kiválasztja ReadOnly, a kapcsolatot az alábbi speciális konfigurációk közül bármelyik rendelik hozzá, amelyek létezhetnek az adatbázis számára:

• Mindig bekapcsolva. Egy adatbázis engedélyezheti vagy nem engedélyezheti az olvasási munkaterhelést a célzott elérhetőségi csoport adatbázisán. Ezt a választást a ALLOW_CONNECTIONS és PRIMARY_ROLE Transact-SQL állítások mellékmellékének SECONDARY_ROLE használatával szabályozzuk.

• Georeplikáció

• Olvasási felskálázás

Ha ezek közül egyik sem áll rendelkezésre ezek a speciális célpontok közül, a hagyományos adatbázist olvassák fel.

A ApplicationIntent kulcsszó lehetővé teszi az olvasás nélküli útválasztást.

Írásvédett útválasztás

Az csak olvasható útválasztás egy olyan funkció, amely biztosítja az adatbázis csak olvasható replikájának elérhetőségét. Az csak olvasható útválasztás engedélyezéséhez az alábbiak mind érvényesek:

• Csatlakoznod kell egy Always On elérhetőségi csoport hallgatójához.

• A kapcsolati ApplicationIntent sztring kulcsszavát ReadOnly értékre kell állítani.

• Az adatbázis-adminisztrátornak konfigurálnia kell a rendelkezésre állási csoportot úgy, hogy engedélyezze az olvasás nélküli útválasztást.

Több, mindegyik csak olvasható útvonalat használó kapcsolat nem biztos, hogy mind ugyanahhoz az csak olvasható replikához csatlakozik. Az adatbázis-szinkronizálás vagy a kiszolgáló útválasztási konfigurációjának módosítása ahhoz vezethet, hogy az ügyfelek különböző írásvédett replikákhoz csatlakoznak.

Biztosíthatod, hogy minden csak olvasható kérés ugyanahhoz az csak olvasható replikához csatlakozzon, ha nem adsz át elérhetőségi csoport hallgatóját a Server kapcsolati string kulcsszóhoz. Ehelyett adja meg a csak olvasható példány nevét.

Az csak olvasható útválasztás tovább tarthat, mint a fő útvonalhoz való csatlakozás. Ez azért van, mert az csak olvasható útválasztás először csatlakozik az elsődleges útvonalhoz, majd a legjobb olvasható másodlagos útvonalat keresi. Ezek miatt a több lépés miatt legalább 30 másodpercre kell növelned az login időkérést.

Lásd még:

Csatlakozás a kiszolgálóhoz