Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
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.
Nastavte MultiSubnetFailover=True, když je cílem Azure SQL Database, Azure SQL Managed Instance, SQL databáze v Microsoft Fabric, listener skupiny dostupnosti nebo instance failover clusteru. Ovladač se paralelně pokouší navázat TCP spojení na všechny přeložené IP adresy a použije první spojení, které se podaří navázat. Pokud je aplikace připojena k databázi, která přejde na failover, původní spojení je přerušeno a aplikace musí otevřít nové připojení, aby mohla pokračovat v práci po failoveru.
Když se DNS přeloží na jednu adresu, MultiSubnetFailover=True nevytváří další paralelní pokusy o připojení, takže je bezpečné pro cíle s jednou IP adresou.
Ovladače přijímají True, 1 nebo Yes v každém případě a předávají tuto možnost podkladovému ODBC ovladači. Každou jinou hodnotu považují za False bez hlášení chyby, takže špatně napsaná hodnota možnost tiše deaktivuje.
MultiSubnetFailover má následující limity:
Nemůžete ho použít přes jiný protokol než TCP.
Připojení k instanci SQL Server nakonfigurované s více než 64 IP adresami selže.
S databázovým zrcadlením to nelze použít. Nenastavujte to, když připojovací řetězec také používá Failover_Partner nebo když se připojujete k primární replice místo k naslouchači skupiny dostupnosti. Další informace naleznete v tématu Upgrade na použití clusterů s více podsítěmi z databázového zrcadlení.
Pro serverless Azure SQL Database s povoleným automatickým pauzováním, pokud nastavíte LoginTimeout, použijte alespoň 60 sekund. Automaticky pozastavená databáze se obnoví při prvním pokusu o připojení a tento pokus může selhat s chybou 40613, zatímco databáze pokračuje, takže aplikace musí zkusit znovu. Více informací naleznete v části Automatické pozastavení a automatické obnovení.
Pro více informací o skupinách dostupnosti Always On viz Co je skupina Always On Availability?.
Transparentní rezoluce IP adres (TNIR)
Transparentní rozlišení IP v síti (TNIR) je starší mechanismus přepnutí na jinou IP adresu v ovladači ODBC, ovládaný možností připojení TransparentNetworkIPResolution, která je ve výchozím nastavení povolena.
Řiďte se pokyny v předchozí sekci a nastavte MultiSubnetFailover=True pro cíle uvedené v této části. Když MultiSubnetFailover=True, ovladač se pokusí o TCP spojení se všemi vyřešenými IP adresami paralelně. Volba TransparentNetworkIPResolution neovlivňuje sekvenci připojení, takže ji nemusíte nastavovat ani zohledňovat v připojovací řetězec.
Úplné informace o interakci mezi TNIR a MultiSubnetFailover naleznete v tématu Použití funkce Transparent Network IP Resolution s ovladačem ODBC.
Přechod ze zrcadlení databáze na používání vícepodsíťových clusterů
K chybě připojení dojde, pokud jsou v připojovacím řetězci uvedena klíčová slova MultiSubnetFailover a Failover_Partner. 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 aktualizaci PHP aplikace, která aktuálně používá zrcadlení databáze, na scénář s více podsítěmi, odstraňte vlastnost Failover_Partner connection a nahraďte ji nastavením MultiSubnetFailover na True. Nahraďte název serveru v připojovací řetězec za posluchač skupiny dostupnosti. Pokud připojovací řetězec obsahuje Failover_Partner a MultiSubnetFailover=True, ovladač vyvolá chybu. Pokud však připojovací řetězec používá Failover_Partner a MultiSubnetFailover=False (nebo ApplicationIntent=ReadWrite), aplikace používá zrcadlení databází.
Ovladač vrátí chybu, pokud použijete zrcadlení databáze pro primární repliku ve skupině dostupnosti a pokud použijete MultiSubnetFailover=True v připojovacím řetězci, který se připojuje k primární replice 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 si při navazování připojení vyžádá úlohu pro čtení. 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:
Vždy zapnutý. V databázi lze povolit nebo zakázat úlohy čtení v cílové databázi ve skupině dostupnosti. Tato volba se řídí použitím klauzule
ALLOW_CONNECTIONSpříkazů Transact-SQLPRIMARY_ROLEaSECONDARY_ROLE.
Pokud žádný z těchto speciálních cílů není k dispozici, čte se z běžné databáze.
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
ApplicationIntentmusí být nastaveno naReadOnly.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, aby se všechny požadavky jen pro čtení připojovaly ke stejné replice jen pro čtení, tím že neuvedete naslouchací proces skupiny dostupnosti v parametru Server připojovacího řetězce. 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í jen pro čtení se nejprve připojí k primární replice a pak vyhledá nejlepší dostupnou sekundární repliku pro čtení. Díky těmto několika krokům byste měli prodloužit login časovou pauzu alespoň na 30 sekund.