Condividi tramite

Informazioni sulla connessione client alle repliche di disponibilità del server SQL (SQL Server)

In un gruppo di disponibilità AlwaysOn è possibile configurare una o più repliche di disponibilità per consentire connessioni di sola lettura durante l'esecuzione nel ruolo secondario, ovvero quando è in esecuzione come replica secondaria. È anche possibile configurare ogni replica di disponibilità per consentire o escludere connessioni di sola lettura durante l'esecuzione nel ruolo primario, ovvero quando viene eseguita come replica primaria.

Per facilitare l'accesso client ai database primari o secondari di un determinato gruppo di disponibilità, è necessario definire un listener del gruppo di disponibilità. Per impostazione predefinita, il listener del gruppo di disponibilità indirizza le connessioni in ingresso alla replica primaria. Tuttavia, è possibile configurare un gruppo di disponibilità per supportare il routing di sola lettura, che consente al listener del gruppo di disponibilità di reindirizzare le richieste di connessione delle applicazioni con finalità di lettura a una replica secondaria leggibile. Per ulteriori informazioni, vedere Configurare l'instradamento Read-Only per il gruppo di disponibilità (SQL Server).

Durante un failover, una replica secondaria passa al ruolo primario e la replica primaria precedente passa al ruolo secondario. Durante il processo di failover, tutte le connessioni client alla replica primaria e alle repliche secondarie vengono terminate. Dopo il failover, quando un client si riconnette al listener del gruppo di disponibilità, il listener riconnette il client alla nuova replica primaria, ad eccezione di una richiesta di connessione con finalità di lettura. Se il routing di sola lettura è configurato nel client e nelle istanze del server che ospita la nuova replica primaria e in almeno una replica secondaria leggibile, le richieste di connessione con finalità di lettura vengono reindirizzate a una replica secondaria che supporta il tipo di accesso alla connessione richiesto dal client. Per garantire un'esperienza client fluida dopo un failover, è importante configurare l'accesso alla connessione per i ruoli secondari e primari di ogni replica di disponibilità.

Annotazioni

Per informazioni sul listener del gruppo di disponibilità, che gestisce le richieste di connessione dei client, vedere Listener del gruppo di disponibilità, connettività dei client e failover delle applicazioni (SQL Server).

In questo argomento:

Tipi di accesso alla connessione supportati dal ruolo secondario

Il ruolo secondario supporta tre alternative per le connessioni client, come indicato di seguito:

Nessuna connessione
Non sono consentite connessioni utente. I database secondari non sono disponibili per l'accesso in lettura. Si tratta del comportamento predefinito nel ruolo secondario.

Solo connessioni con finalità di lettura
I database secondari sono disponibili solo per la connessione per cui la Application Intent proprietà di connessione è impostata su ReadOnly (connessioni con finalità di lettura).

Per informazioni su questa proprietà di connessione, vedere Supporto di SQL Server Native Client per disponibilità elevata, ripristino di emergenza.

Consenti qualsiasi connessione di sola lettura
I database secondari sono tutti disponibili per le connessioni di lettura. Questa opzione consente ai client con versioni inferiori di connettersi.

Per altre informazioni, vedere Configurare l'accesso in sola lettura in una replica di disponibilità (SQL Server).

Tipi di accesso alla connessione supportati dal ruolo primario

Il ruolo primario supporta due alternative per le connessioni client, come indicato di seguito:

Tutte le connessioni sono consentite
Sia le connessioni di lettura/scrittura che di sola lettura sono consentite ai database primari. Si tratta del comportamento predefinito per il ruolo primario.

Consenti solo connessioni di lettura/scrittura
Quando la Application Intent proprietà di connessione è impostata su ReadWrite o non è impostata, la connessione è consentita. Le connessioni per le quali la parola chiave della Application Intent stringa di connessione è impostata su ReadOnly non sono consentite. Consentire solo connessioni di lettura/scrittura può impedire ai clienti di collegare un carico di lavoro destinato alla lettura alla replica primaria per errore.

Per informazioni su questa proprietà di connessione, vedere Uso delle parole chiave della stringa di connessione con SQL Server Native Client.

Per altre informazioni, vedere Configurare l'accesso in sola lettura in una replica di disponibilità (SQL Server).

Impatto della configurazione dell'accesso alla connessione sulla connettività client

Le impostazioni di accesso alla connessione di una replica determinano se un tentativo di connessione ha esito negativo o ha esito positivo. La tabella seguente riepiloga se un determinato tentativo di connessione ha esito positivo o negativo per ogni impostazione di accesso alla connessione.

Ruolo replica Accesso alla connessione supportato nella replica Finalità di connessione Connection-Attempt Risultato
Secondario Tutti Finalità di lettura, lettura/scrittura o nessuna finalità di connessione specificata Successo
Secondario Nessuno (si tratta del comportamento secondario predefinito). Finalità di lettura, lettura/scrittura o nessuna finalità di connessione specificata Fallimento
Secondario Sola finalità di lettura Finalità di lettura Successo
Secondario Sola finalità di lettura Lettura/scrittura o nessuna finalità di connessione specificata Fallimento
Primaria Tutto (si tratta del comportamento primario predefinito). Proprietà di sola lettura, lettura/scrittura o nessuna finalità di connessione specificata Successo
Primaria Lettura/scrittura Sola finalità di lettura Fallimento
Primaria Lettura/scrittura Lettura/scrittura o nessuna finalità di connessione specificata Successo

Per informazioni sulla configurazione di un gruppo di disponibilità per accettare connessioni client alle relative repliche, vedere Listener del gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server).

Esempio di configurazione Connection-Access

A seconda del modo in cui sono configurate repliche di disponibilità diverse per l'accesso alla connessione, il supporto per le connessioni client potrebbe cambiare dopo il failover di un gruppo di disponibilità. Si consideri, ad esempio, un gruppo di disponibilità per il quale la creazione di report viene eseguita su repliche secondarie con commit asincrono remoto. Tutte le applicazioni di sola lettura per i database di questo gruppo di disponibilità impostano la proprietà Application Intent di connessione su ReadOnly, in modo che tutte le connessioni di sola lettura siano connessioni con finalità di lettura.

Questo gruppo di disponibilità di esempio possiede due repliche con commit sincrono nel centro di calcolo principale e due repliche con commit asincrono in un sito satellite. Per il ruolo primario, tutte le repliche sono configurate per l'accesso in lettura/scrittura, che impedisce le connessioni con finalità di lettura alla replica primaria in tutte le situazioni. Il ruolo secondario commit sincrono usa la configurazione di accesso alla connessione predefinita ("none"), che impedisce tutte le connessioni client nel ruolo secondario. Al contrario, le repliche con commit asincrono sono configurate per consentire le connessioni con finalità di lettura nel ruolo secondario. La tabella seguente riepiloga questa configurazione di esempio:

Replica Modalità commit Ruolo iniziale Accesso alla connessione per un ruolo secondario Accesso alla connessione per ruolo principale
Replica1 Sincrono Primaria Nessuno Lettura/scrittura
Replica2 Sincrono Secondario Nessuno Lettura/scrittura
Replica3 Asincrono Secondario Read-intentonly Lettura/scrittura
Replica4 Asincrono Secondario Sola finalità di lettura Lettura/scrittura

In genere, in questo scenario di esempio, i failover si verificano solo tra le repliche con commit sincrono e immediatamente dopo il failover, le applicazioni con finalità di lettura possono riconnettersi a una delle repliche secondarie con commit asincrono. Tuttavia, quando si verifica un disastro nel centro di calcolo principale, entrambe le repliche con commit sincrono vengono perse. L'amministratore del database presso il sito satellite risponde effettuando un failover manuale forzato su una replica secondaria con commit asincrono. I database secondari nella replica secondaria rimanente sono sospesi a causa del failover forzato, rendendoli non disponibili per carichi di lavoro di sola lettura. La nuova replica primaria, configurata per le connessioni di lettura e scrittura, impedisce al carico di lavoro in sola lettura di competere con il carico di lavoro di lettura e scrittura. Ciò significa che finché l'amministratore del database non riprende i database secondari nella replica secondaria con commit asincrono rimanente, i client con finalità di lettura non possono connettersi a alcuna replica di disponibilità.

Attività correlate

Contenuto correlato

Vedere anche

Panoramica dei gruppi di disponibilità AlwaysOn (SQL Server)
Listener dei gruppi di disponibilità, connettività dei client e failover delle applicazioni (SQL Server)
Statistica

  • Last updated on