Supporto per il ripristino di emergenza a disponibilità elevata
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 il listener del gruppo di disponibilità di un gruppo di disponibilità di ripristino di emergenza a disponibilità elevata o di un'istanza del cluster di failover come server nella stringa di connessione.
La proprietà di connessione MultiSubnetFailover indica che l'applicazione viene distribuita in un gruppo di disponibilità o nell'istanza del cluster di failover e che il driver tenta di connettersi al database nell'istanza di SQL Server primaria tramite la connessione a tutti gli indirizzi IP. Specificare sempre MultiSubnetFailover=true in caso di connessione a un listener del gruppo di disponibilità di SQL Serve o a un'istanza del cluster di failover di SQL Server. Se l'applicazione è connessa a un database Always On che esegue il failover, la connessione originale viene interrotta e l'applicazione deve aprire una nuova connessione per continuare a funzionare dopo il failover.
Per informazioni dettagliate sui Gruppi di disponibilità Always On, vedere la pagina della documentazione sul ripristino di emergenza a disponibilità elevata.
Risoluzione dell'IP di rete trasparente
La risoluzione dell'IP di rete trasparente (TNIR) è una revisione della funzionalità MultiSubnetFailover esistente. Influisce sulla sequenza di connessione del driver quando il primo IP risolto del nome host non risponde e sono presenti più IP associati al nome host. L'opzione di connessione corrispondente è TransparentNetworkIPResolution. Insieme a MultiSubnetFailover offre le quattro sequenze di connessione seguenti:
- Opzione TNIR abilitata e opzione MultiSubnetFailover disabilitata: viene eseguito un tentativo per un indirizzo IP, seguito da tutti gli indirizzi IP in parallelo
- Opzione TNIR abilitata e opzione MultiSubnetFailover abilitata: viene eseguito un tentativo per tutti gli indirizzi IP in parallelo
- Opzione TNIR disabilitata e opzione MultiSubnetFailover disabilitata: viene eseguito un tentativo per tutti gli indirizzi IP, uno dopo l'altro
- Opzione TNIR disabilitata e opzione MultiSubnetFailover abilitata: viene eseguito un tentativo per tutti gli indirizzi IP in parallelo
Per impostazione predefinita, TNIR è abilitata e MultiSubnetFailover è disabilitata.
Di seguito è riportato un esempio di abilitazione di TNIR e MultiSubnetFailover con il driver 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);
}
?>
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 usa il mirroring del database in uno scenario con più subnet, rimuovere la proprietà di connessione Failover_Partner e sostituirla con MultiSubnetFailover impostata su True e sostituire il nome del server nella stringa di connessione con un listener del gruppo di disponibilità. Se in una stringa di connessione vengono usati Failover_Partner e MultiSubnetFailover=true il driver genera un errore. Se tuttavia in una stringa di connessione vengono usati Failover_Partner e MultiSubnetFailover=false (o ApplicationIntent=ReadWrite) l'applicazione usa il mirroring del database.
Il driver restituisce un errore se il mirroring del database viene usato nel database primario nel gruppo di disponibilità e se MultiSubnetFailover=true viene usato nella stringa di connessione a un database primario anziché a un 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 nessuna di queste destinazioni speciali è disponibile, viene letto il database normale.
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.
Per assicurare la connessione di tutte le richieste di sola lettura alla stessa replica di sola lettura, non passare un listener del gruppo di disponibilità alla parola chiave della stringa di connessione Server. Specificare invece il nome dell'istanza di sola lettura.
Il routing di sola lettura potrebbe richiedere più tempo rispetto alla connessione alla replica primaria. 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.