Stöd för hög tillgänglighet, katastrofåterställning

Ladda ned PHP-drivrutin

I det här avsnittet beskrivs Microsoft-drivrutiner för PHP för SQL Server-stöd (tillagt i version 3.0) för haveriberedskap med hög tillgänglighet.

Från och med version 3.0 av Microsoft Drivers for PHP för SQL Server kan du ange tillgänglighetsgruppens lyssnare för en tillgänglighetsgrupp med hög tillgänglighet, haveriberedskapstillgänglighet eller en redundansklusterinstans som server i anslutningssträngen.

Egenskapen MultiSubnetFailover-anslutning anger att programmet distribueras i en tillgänglighetsgrupp eller redundansklusterinstans och att drivrutinen försöker ansluta till databasen på den primära SQL Server-instansen genom att försöka ansluta till alla IP-adresser. Ange alltid MultiSubnetFailover=True när du ansluter till en SQL Server-tillgänglighetsgrupplyssnare eller SQL Server-redundansklusterinstans. Om programmet är anslutet till en Always On-databas som genomgår en failover, bryts den ursprungliga anslutningen och programmet måste öppna en ny anslutning för att fortsätta fungera efter failovern.

Fullständig information om AlwaysOn-tillgänglighetsgrupper finns på sidan Dokument för hög tillgänglighet, Haveriberedskap .

Transparent nätverks-IP-upplösning (TNIR)

Transparent nätverks-IP-upplösning (TNIR) är en revision av den befintliga MultiSubnetFailover-funktionen . Det påverkar drivrutinens anslutningssekvens när den första lösta IP-adressen för värdnamnet inte svarar och det finns flera IP-adresser som är associerade med värdnamnet. Motsvarande anslutningsalternativ är TransparentNetworkIPResolution. Tillsammans med MultiSubnetFailover tillhandahåller det följande fyra anslutningssekvenser:

• TNIR aktiverad och MultiSubnetFailover inaktiverad: En IP-adress försöks, följt av att alla IP-adresser försöks parallellt
• TNIR aktiverad och MultiSubnetFailover aktiverad: Alla IP-adresser testas parallellt
• TNIR Inaktiverad och MultiSubnetFailover Inaktiverad: Alla IP-adresser försöks en efter en
• TNIR Inaktiverad och MultiSubnetFailover aktiverad: Alla IP-adresser försöks parallellt

TNIR är aktiverat som standard och MultiSubnetFailover är inaktiverat som standard.

Det här är ett exempel på hur du aktiverar både TNIR och MultiSubnetFailover med hjälp av PDO_SQLSRV drivrutinen:

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

Uppgradering till användning av multi-subnätkluster från databasspegling

Ett anslutningsfel uppstår om nyckelorden MultiSubnetFailover och Failover_Partner anslutning finns i anslutningssträngen. Ett fel uppstår också om MultiSubnetFailover används och SQL Server returnerar ett failover-partnersvar som indikerar att den är en del av ett databas-speglingspar.

När du uppgraderar ett PHP-program som för närvarande använder databasspegling till ett scenario med flera undernät tar du bort Failover_Partner-anslutningsegenskapen och ersätter den med MultiSubnetFailover inställd på True och ersätter servernamnet i anslutningssträngen med en tillgänglighetsgrupplyssnare. Om en anslutningssträng använder Failover_Partner och MultiSubnetFailover=true genererar drivrutinen ett fel. Men om en anslutningssträng använder Failover_Partner och MultiSubnetFailover=false (eller ApplicationIntent=ReadWrite) använder programmet databasspegling.

Drivrutinen returnerar ett fel om databasspegling används på den primära databasen i tillgänglighetsgruppen och om MultiSubnetFailover=true används i anslutningssträngen som ansluter till en primär databas i stället för till en tillgänglighetsgrupplyssnare.

Specificera applikationens avsikt

Du kan ange nyckelordet ApplicationIntent i din anslutningssträng. De tilldelbara värdena är ReadWrite (standardvärdena) eller ReadOnly.

När du sätter ApplicationIntent=ReadOnly, begär klienten en läsarbetsbelastning vid anslutning. Servern upprätthåller avsikten vid anslutningstidpunkten och under en USE databassats.

Nyckelordet ApplicationIntent fungerar inte med äldre skrivskyddade databaser.

Mål för ReadOnly

När en anslutning väljer ReadOnly, tilldelas anslutningen någon av följande speciella konfigurationer som kan finnas för databasen:

• Alltid på. En databas kan tillåta eller avvisa läsarbetsbelastningar på den avsedda tillgänglighetsgruppens databas. Detta val styrs genom att använda ALLOW_CONNECTIONS klausulen i PRIMARY_ROLE och SECONDARY_ROLE Transact-SQL-satserna.

• Geo-replication

• Lässkalbarhet

Om inga av dessa specialmål finns tillgängliga läses den vanliga databasen från.

Nyckelordet ApplicationIntent möjliggör skrivskyddad routing.

Skrivskyddad routning

Skrivskyddad routning är en funktion som kan säkerställa tillgången till en skrivskyddad kopia av en databas. För att aktivera skrivskyddad routing gäller alla följande:

• Du måste koppla upp dig till en lyssnare i Always On-tillgänglighetsgruppen.

• Nyckelordet för anslutningssträngen ApplicationIntent måste vara inställt på ReadOnly.

• Databasadministratören måste konfigurera tillgänglighetsgruppen för att möjliggöra skrivskyddad routing.

Flera anslutningar som båda använder skrivskyddad routing kanske inte alla ansluter till samma skrivskyddade replik. Ändringar i databassynkronisering eller ändringar i serverns routningskonfiguration kan resultera i klientanslutningar till olika skrivskyddade repliker.

Du kan säkerställa att alla skrivskyddade förfrågningar ansluter till samma skrivskyddade replika genom att inte skicka en tillgänglighetsgrupplyssnare till anslutningssträngens Server nyckelord. Ange istället namnet på den skrivskyddade instansen.

Read-only-routing kan ta längre tid än att ansluta till primären. Detta beror på att read-only-routing först kopplas till primären och sedan letar efter den bästa tillgängliga läsbara sekundären. På grund av dessa flera steg bör du öka din login timeout till minst 30 sekunder.

Se även

Ansluta till servern