Disponibilità elevata e ripristino di emergenza in Linux e macOS

  • Articolo

Scaricare il driver ODBC

I driver ODBC per Linux e macOS supportano Gruppi di disponibilità Always On. Per altre informazioni su Gruppi di disponibilità Always On, vedere:

È possibile specificare il listener del gruppo di disponibilità per un gruppo specifico nella stringa di connessione. Se un'applicazione ODBC in Linux o macOS è connessa a un database in un gruppo di disponibilità che effettua il failover, la connessione originale viene interrotta. Per continuare a funzionare dopo il failover, l'applicazione deve aprire una nuova connessione.

I driver ODBC in Linux e macOS eseguono l'iterazione in modo sequenziale di tutti gli indirizzi IP associati a un nome host DNS se non ci si sta connettendo a un listener del gruppo di disponibilità. Se il primo indirizzo IP restituito dal server DNS non consente la connessione, queste iterazioni possono impiegare molto tempo.

Quando ci si connette a un listener del gruppo di disponibilità, il driver cerca di stabilire connessioni a tutti gli indirizzi IP in parallelo. Se un tentativo di connessione ha esito positivo, il driver ignora tutti i tentativi di connessione in sospeso.

Nota

Poiché il failover di un gruppo di disponibilità può causare un errore di connessione, è consigliabile implementare una logica di ripetizione dei tentativi di connessione. Provare di nuovo a stabilire una connessione non riuscita finché la riconnessione non riesce. Aumentando il timeout connessione e implementando una logica di ripetizione dei tentativi di connessione, si aumentano le probabilità di connessione a un gruppo di disponibilità.

Stabilire la connessione con MultiSubnetFailover

Specificare sempre MultiSubnetFailover=Yes in caso di connessione a un listener del gruppo di disponibilità di SQL Server 2012 (11.x) o a un'istanza del cluster di failover di SQL Server 2012 (11.x). MultiSubnetFailover consente failover più rapidi per tutti i gruppi di disponibilità e le istanze del cluster di failover in SQL Server 2012 (11.x).

Questa proprietà di connessione riduce anche notevolmente il tempo di failover per le topologie Always On su una o più subnet. Durante un failover su più subnet, il client cerca di eseguire le connessioni in parallelo. Durante un failover su una subnet, il driver ritenta in modo insistente la connessione TCP.

La proprietà di connessione MultiSubnetFailover indica che l'applicazione viene distribuita in un gruppo di disponibilità o in un'istanza del cluster di failover. Il driver cerca di connettersi al database nell'istanza di SQL Server primaria eseguendo un tentativo di connessione a tutti gli indirizzi IP.

In caso di connessione con MultiSubnetFailover=Yes, il client ripete i tentativi di connessione TCP più velocemente rispetto agli intervalli di ritrasmissione TCP predefiniti del sistema operativo. MultiSubnetFailover=Yes consente una riconnessione più veloce di un gruppo di disponibilità Always On o di un'istanza del cluster di failover Always On dopo il failover. MultiSubnetFailover=Yes si applica alle istanze del cluster di failover e ai gruppi di disponibilità su una o più subnet.

Usare MultiSubnetFailover=Yes in caso di connessione a un listener del gruppo di disponibilità o a un'istanza del cluster di failover. In caso contrario, le prestazioni dell'applicazione potrebbero essere influenzate negativamente.

Consigli

Quando si stabilisce la connessione a un server in un gruppo di disponibilità o in un'istanza del cluster di failover:

  • Specificare MultiSubnetFailover=Yes per migliorare le prestazioni in caso di connessione a un gruppo di disponibilità su una o più subnet.

  • Specificare il listener del gruppo di disponibilità come server nella stringa di connessione.

  • Non è possibile connettersi a un'istanza di SQL Server configurata con più di 64 indirizzi IP.

  • È possibile usare sia l'autenticazione di SQL Server che Kerberos con MultiSubnetFailover=Yes senza influire sul comportamento dell'applicazione.

  • È possibile aumentare il valore di loginTimeout per adattarlo alla durata del failover e ridurre il numero di nuovi tentativi di connessione dell'applicazione.

  • Le transazioni distribuite non sono supportate.

Se il routing di sola lettura non è attivo, non è possibile stabilire una connessione a un percorso di replica secondaria in un gruppo di disponibilità nelle situazioni seguenti:

  • Se il percorso di replica secondaria non è configurato per accettare le connessioni.

  • Se un'applicazione usa ApplicationIntent=ReadWrite e il percorso di replica secondaria è configurato per l'accesso di sola lettura.

Una connessione non riesce se una replica primaria è configurata per rifiutare i carichi di lavoro di sola lettura e la stringa di connessione contiene ApplicationIntent=ReadOnly.

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_CONNECTIONS delle istruzioni Transact-SQL PRIMARY_ROLE e SECONDARY_ROLE.

  • Replica geografica

  • 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 ApplicationIntent deve essere impostata su ReadOnly.

  • 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.

Sintassi ODBC

Due parole chiave per la stringa di connessione ODBC supportano Gruppi di disponibilità Always On:

  • ApplicationIntent

  • MultiSubnetFailover

Per altre informazioni sulle parole chiave per le stringhe di connessione ODBC, vedere Uso di parole chiave per le stringhe di connessione con SQL Server Native Client.

Gli attributi delle proprietà di connessione equivalenti sono:

  • SQL_COPT_SS_APPLICATION_INTENT

  • SQL_COPT_SS_MULTISUBNET_FAILOVER

Per altre informazioni sugli attributi di connessione ODBC, vedere SQLSetConnectAttr.

Un'applicazione ODBC che usa Gruppi di disponibilità Always On può stabilire la connessione tramite una delle due funzioni seguenti:

Funzione Descrizione
Funzione SQLConnect SQLConnect supporta sia ApplicationIntent sia MultiSubnetFailover tramite un nome di origine dati (DSN) o attributi di connessione.
Funzione SQLDriverConnect SQLDriverConnect supporta ApplicationIntent e MultiSubnetFailover tramite DSN, parola chiave della stringa di connessione o attributo di connessione.

Vedi anche

Parole chiave delle stringhe di connessione e nomi delle origini dati (DSN)

Linee guida per la programmazione

Note sulla versione