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.

Sätt MultiSubnetFailover=True när målet är Azure SQL Database, Azure SQL Managed Instance, SQL-databas i Microsoft Fabric, en tillgänglighetsgrupplyssnare eller en failover-klusterinstans. Drivrutinen försöker upprätta TCP-anslutningar till alla lösta IP-adresser parallellt och använder den anslutning som lyckas först. Om applikationen är ansluten till en databas som växlar över bryts den ursprungliga anslutningen, och applikationen måste öppna en ny anslutning för att fortsätta fungera efter växlingen.

När DNS löses till en adress skapar MultiSubnetFailover=True inga ytterligare parallella anslutningsförsök, så det är säkert på enskilda IP-mål.

Drivrutinerna accepterar True, 1 eller Yes i vilket fall som helst, och skickar alternativet till den underliggande ODBC-drivrutinen. De behandlar alla andra värden som falska utan att rapportera ett fel, så ett felstavat värde inaktiverar tyst alternativet.

MultiSubnetFailover har följande begränsningar:

  • Du kan inte använda det över ett annat protokoll än TCP.

  • Anslutning till en SQL Server-instans konfigurerad med mer än 64 IP-adresser misslyckas.

  • Du kan inte använda det med databasspegling. Ställ inte in när reťazec pripojenia också använder Failover_Partner, eller när du ansluter till en primär replika istället för en tillgänglighetsgrupplyssnare. För mer information, se Uppgradering till användning av multisubnätkluster från databasspegling.

För Azure SQL Database serverless med auto-pause aktiverat, om du sätter LoginTimeout, använd minst 60 sekunder. En automatiskt pausad databas återupptas vid första anslutningsförsöket, och det försöket kan misslyckas med fel 40613 medan databasen återupptas, så applikationen måste försöka igen. Mer information finns i Automatisk paus och automatisk återupptagning.

För mer information om Always On-tillgänglighetsgrupper, se Vad är en Always On tillgänglighetsgrupp?.

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

Transparent Network IP Resolution (TNIR) är ODBC-drivrutinens äldre multi-IP-reservplan, styrd av anslutningsalternativet TransparentNetworkIPResolution och aktiverad som standard.

Följ instruktionerna i föregående avsnitt och sätt MultiSubnetFailover=True för de mål som listas där. När MultiSubnetFailover=True försöker drivrutinen upprätta TCP-anslutningar till alla identifierade IP-adresser parallellt. Alternativet TransparentNetworkIPResolution påverkar inte anslutningssekvensen, så du behöver inte ange det eller ta hänsyn till det i anslutningssträngen.

En fullständig referens för interaktionen mellan TNIR och MultiSubnetFailover finns i Använda transparent nätverks-IP-upplösning med ODBC-drivrutinen.

Uppgradera till att använda multisubnätkluster från databasspegling

Ett anslutningsfel uppstår om anslutningsnyckelorden MultiSubnetFailover och Failover_Partner 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 anslutningsegenskapen Failover_Partner och ersätter den med MultiSubnetFailover som anges till True. Byt ut servernamnet i reťazec pripojenia med en tillgänglighetsgrupplyssnare. Om en reťazec pripojenia 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 du använder databasspegling på den primära repliken i tillgänglighetsgruppen och om du använder MultiSubnetFailover=True i anslutningssträngen som ansluter till en primär replik 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 verkställer avsikten vid anslutning 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 är tillgängliga läser man i stället från den vanliga databasen.

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.

Relaterat innehåll

  • Last updated on