Sdílet prostřednictvím

Podpora vysoké dostupnosti, zotavení po havárii

Stáhnout ovladač PHP

Toto téma popisuje ovladače Microsoftu pro PHP pro podporu SQL Serveru (přidané ve verzi 3.0) pro zajištění vysoké dostupnosti a zotavení po havárii.

Počínaje verzí 3.0 ovladačů Microsoft pro PHP pro SQL Server můžete zadat posluchače skupiny dostupnosti v rámci vysoké dostupnosti, zotavení po havárii nebo instance clusteru s podporou převzetí služeb při selhání jako server v připojovacím řetězci.

Vlastnost připojení MultiSubnetFailover označuje, že aplikace se nasazuje ve skupině dostupnosti nebo instanci clusteru s podporou failoveru a že ovladač se pokusí připojit k databázi na primární instanci SQL Serveru snahou připojit se ke všem IP adresám. Při připojování k naslouchacímu procesu skupiny dostupnosti SQL Serveru nebo instanci clusteru s podporou převzetí služeb při selhání SQL Serveru vždy zadejte MultiSubnetFailover=True . Pokud je aplikace připojená k databázi AlwaysOn, která převezme služby při selhání, původní připojení se přeruší a aplikace musí otevřít nové připojení, aby po převzetí služeb při selhání pokračovala v práci.

Úplné podrobnosti o skupinách dostupnosti Always On najdete na stránce Dokumentace k vysoké dostupnosti a zotavení po havárii.

Transparentní rezoluce IP adres (TNIR)

Transparent Network IP Resolution (TNIR) představuje revizi stávající funkce MultiSubnetFailover. Ovlivňuje posloupnost připojení ovladače, když první přeložená IP adresa názvu hostitele nereaguje a k názvu hostitele je přidružených více IP adres. Odpovídající možností připojení je TransparentNetworkIPResolution. Společně s funkcí MultiSubnetFailover poskytuje následující čtyři sekvence připojení:

  • TNIR Enabled & MultiSubnetFailover Disabled: Jedna IP adresa se pokusí nejprve, následuje paralelní pokus o všechny IP adresy.
  • TNIR povoleno & MultiSubnetFailover povoleno: Všechny IP adresy se zkoušejí současně
  • Zakázáno TNIR a zakázáno MultiSubnetFailover: Všechny IP adresy jsou zkoušeny jedna po druhé.
  • TNIR je deaktivováno a MultiSubnetFailover je povoleno: Všechny IP adresy jsou zkoušeny paralelně

Funkce TNIR je ve výchozím nastavení povolená a MultiSubnetFailover je ve výchozím nastavení zakázaná.

Toto je příklad, jak povolit TNIR i MultiSubnetFailover s použitím ovladače PDO_SQLSRV:

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

Upgrade na používání vícepodsíťových clusterů z databázového zrcadlení

Chyba spojení nastane, pokud jsou v řetězci přípojových slov přítomna klíčová slova MultiSubnetFailover a Failover_Partner connection. Chyba nastane také v případě, že je použit MultiSubnetFailOver a SQL Server vrátí odpověď partnera pro failover, která označuje, že je součástí dvojice zrcadlení databáze.

Při upgradu aplikace PHP, která aktuálně používá zrcadlení databáze na vícepodsíťový scénář, odeberte vlastnost připojení Failover_Partner a nahraďte ji parametrem MultiSubnetFailover nastaveným na True a nahraďte název serveru v připojovacím řetězci listenerem skupiny dostupnosti. Pokud připojovací řetězec používá Failover_Partner a MultiSubnetFailover=true, ovladač vygeneruje chybu. Pokud ale připojovací řetězec používá Failover_Partner a MultiSubnetFailover=false (nebo ApplicationIntent=ReadWrite), bude aplikace používat zrcadlení databáze.

Ovladač vrátí chybu, pokud se zrcadlení databáze používá v primární databázi ve skupině dostupnosti a pokud MultiSubnetFailover=true se používá v připojovacím řetězci, který se připojuje k primární databázi místo k posluchači skupiny dostupnosti.

Specifikovat záměr aplikace

Klíčové slovo ApplicationIntent můžete zadat ve svém spojovacím řetězci. Přiřaditelné hodnoty jsou ReadWrite (výchozí) nebo ReadOnly.

Když nastavíte ApplicationIntent=ReadOnly, klient požádá o čtení při připojení. Server vynucuje záměr při připojení a během příkazu do databáze USE .

Klíčové ApplicationIntent slovo nefunguje s legacy databázemi pouze pro čtení.

Cíle ReadOnly

Když spojení zvolí ReadOnly, je spojení přiřazeno k některé z následujících speciálních konfigurací, které mohou pro databázi existovat:

Pokud žádný z těchto speciálních cílů není k dispozici, běžná databáze se čte.

Klíčové ApplicationIntent slovo umožňuje směrování pouze pro čtení.

Směrování pouze pro čtení

Směrování pouze pro čtení je funkce, která může zajistit dostupnost repliky databáze pouze pro čtení. Pro umožnění směrování pouze pro čtení platí vše následující:

  • Musíte se připojit ke skupinovému posluchači Always On availability.

  • Klíčové slovo v připojovacím řetězci ApplicationIntent musí být nastaveno na ReadOnly.

  • Správce databáze musí nakonfigurovat skupinu dostupnosti tak, aby umožnila směrování pouze pro čtení.

Více připojení, z nichž každé používá směrování pouze pro čtení, nemusí být všechna připojena ke stejné replikě pouze pro čtení. Změny synchronizace databáze nebo změny v konfiguraci směrování serveru můžou vést k klientským připojením k různým replikám jen pro čtení.

Můžete zajistit, že všechny požadavky pouze pro čtení se připojí ke stejné replikě pouze pro čtení tím, že nepředáte posluchači skupiny dostupnosti ke Server klíčovému slovu řetězce spojů. Místo toho zadejte název instance jen pro čtení.

Směrování pouze pro čtení může trvat déle než připojení k primárnímu kanálu. Je to proto, že směrování pouze pro čtení se nejprve připojí k primárnímu a poté hledá nejlepší dostupnou čitelnou sekundární složku. Díky těmto několika krokům byste měli prodloužit login časovou pauzu alespoň na 30 sekund.

Viz také

Připojení k serveru

  • Last updated on