Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo argomento illustra il supporto dei driver Microsoft per PHP per SQL Server (aggiunto nella versione 3.0) per il ripristino di emergenza e la disponibilità elevata.
A partire dalla versione 3.0 dei driver Microsoft per PHP per SQL Server, è possibile specificare come server nella stringa di connessione il listener del gruppo di disponibilità di un gruppo di disponibilità per l'alta disponibilità e il ripristino di emergenza oppure un'istanza cluster di failover.
Imposta MultiSubnetFailover=True quando la destinazione è database SQL di Azure, Istanza gestita di SQL di Azure, un database SQL in Microsoft Fabric, un listener di gruppo di disponibilità o un'istanza del cluster di failover. Il driver tenta connessioni TCP a tutti gli indirizzi IP risolti in parallelo e utilizza la prima connessione che riesce. Se l'applicazione è collegata a un database che effettua il failover, la connessione originale viene interrotta e l'applicazione deve aprire una nuova connessione per continuare a funzionare dopo il failover.
Quando il DNS si risolve su un indirizzo, MultiSubnetFailover=True non crea ulteriori tentativi di connessione parallela, quindi è sicuro su target a singolo IP.
I driver accettano True, 1 o Yes, indipendentemente da maiuscole e minuscole, e passano l'opzione al driver ODBC sottostante. Trattano qualsiasi altro valore come Falso senza segnalare errori, quindi un valore scritto male disabilita silenziosamente l'opzione.
MultiSubnetFailover ha i seguenti limiti:
Non puoi usarlo su un protocollo diverso da TCP.
La connessione a un'istanza SQL Server configurata con più di 64 indirizzi IP fallisce.
Non puoi usarlo con il mirroring del database. Non impostarlo quando anche nella stringa di connessione viene usato Failover_Partner o quando ci si connette a una replica primaria anziché al listener di un gruppo di disponibilità. Per ulteriori informazioni, vedere Aggiornamento all'uso di cluster multi-subnet partendo dal mirroring del database.
Per database SQL di Azure serverless con auto-pausa attivata, se imposti LoginTimeout, usa almeno 60 secondi. Un database in pausa automatica riprende al primo tentativo di connessione, e questo tentativo può fallire con l'errore 40613 mentre il database riprende, quindi l'applicazione deve riprovare. Per ulteriori informazioni, vedi Pausa automatica e ripresa automatica.
Per maggiori informazioni sui gruppi di disponibilità Always On, vedi Cos'è un gruppo Always On Availability?.
Risoluzione IP di rete trasparente
Transparent Network IP Resolution (TNIR) è il meccanismo di fallback multi-IP storico del driver ODBC, controllato dall'opzione di connessione TransparentNetworkIPResolution e abilitato per impostazione predefinita.
Segui le indicazioni della sezione precedente e imposta MultiSubnetFailover=True per i target elencati lì. Quando MultiSubnetFailover=True, il driver tenta connessioni TCP a tutti gli indirizzi IP risolti in parallelo. L'opzione TransparentNetworkIPResolution non influisce sulla sequenza di connessione, quindi non è necessario impostarla o considerarla nella stringa di connessione.
Per il riferimento completo all'interazione tra TNIR e MultiSubnetFailover, consultare Utilizzo della Risoluzione trasparente dell'IP di rete con il driver ODBC.
Aggiornamento per l'utilizzo di cluster su più subnet dal mirroring del database
Si verificherà un errore di connessione se nella stringa di connessione sono presenti le parole chiave di connessione MultiSubnetFailover e Failover_Partner. Si verificherà un errore anche nel caso in cui venga usata MultiSubnetFailover e SQL Server restituisca una risposta del partner di failover che indica che è parte di una coppia di mirroring del database.
Quando si aggiorna un'applicazione PHP che attualmente utilizza il mirroring del database per uno scenario multi-subnet, rimuovere la proprietà di connessione Failover_Partner e sostituirla con MultiSubnetFailover impostata su True. Sostituisci il nome del server nella stringa di connessione con un listener del gruppo di disponibilità. Se un stringa di connessione usa Failover_Partner e MultiSubnetFailover=True, il driver genera un errore. Tuttavia, se un stringa di connessione utilizza Failover_Partner e MultiSubnetFailover=False (o ApplicationIntent=ReadWrite), l'applicazione utilizza il mirroring del database.
Il driver restituisce un errore se si utilizza il mirroring del database sulla replica primaria nel gruppo di disponibilità e se si usa MultiSubnetFailover=True nella stringa di connessione che si connette a una replica primaria anziché al listener del gruppo di disponibilità.
Specificare la finalità dell'applicazione
È possibile specificare la parola chiave ApplicationIntent nella stringa di connessione. I valori assegnabili sono ReadWrite (impostazione predefinita) e ReadOnly.
Quando si imposta il valore ApplicationIntent=ReadOnly, il client richiede un carico di lavoro di lettura durante la connessione. Il server applica la finalità al momento della connessione e durante un'istruzione di database USE.
La parola chiave ApplicationIntent non funziona con i database legacy di sola lettura.
Destinazioni di ReadOnly
Quando una connessione sceglie ReadOnly, la connessione viene assegnata a una delle configurazioni speciali seguenti che potrebbero essere disponibili per il database:
Sempre attivo. Un database può consentire o impedire carichi di lavoro di lettura nel database del gruppo di disponibilità di destinazione. Questa scelta viene controllata usando la clausola
ALLOW_CONNECTIONSdelle istruzioni Transact-SQLPRIMARY_ROLEeSECONDARY_ROLE.Read scale-out (Scalabilità in lettura)
Se nessuno di questi target speciali è disponibile, si legge il database standard.
La parola chiave ApplicationIntent è utilizzata per abilitare il routing di sola lettura.
Routing di sola lettura
Il routing di sola lettura è una funzionalità che può garantire la disponibilità di una replica di sola lettura di un database. Per abilitare il routing di sola lettura, si applicano tutte le condizioni seguenti:
È necessario connettersi a un listener del gruppo di disponibilità Always On.
La parola chiave della stringa di connessione
ApplicationIntentdeve essere impostata suReadOnly.L'amministratore del database deve configurare il gruppo di disponibilità in modo da abilitare il routing di sola lettura.
Più connessioni che usano il routing di sola lettura potrebbero non connettersi tutte alla stessa replica di sola lettura. Le modifiche nella sincronizzazione del database o nella configurazione di routing del server possono comportare connessioni client a repliche di sola lettura diverse.
Puoi garantire che tutte le richieste di sola lettura si connettano alla stessa replica di sola lettura non passando un listener del gruppo di disponibilità alla parola chiave della stringa di connessione Server. Specificare invece il nome dell'istanza di sola lettura.
L'instradamento di sola lettura potrebbe richiedere più tempo del collegamento al primario. Ciò dipende dal fatto che il routing di sola lettura si connette prima alla replica primaria e quindi cerca la migliore replica secondaria leggibile disponibile. A causa di questi passaggi aggiuntivi, è consigliabile aumentare il timeout di login ad almeno 30 secondi.