Condividi tramite

Differenze tra le modalità di disponibilità per un gruppo di disponibilità Always On

  • Articolo

Si applica a:SQL Server

Nei gruppi di disponibilità Always On la modalità di disponibilità è una proprietà della replica che determina se una replica di disponibilità specificata può essere eseguita in modalità con commit sincrono. La modalità di disponibilità per ogni replica di disponibilità deve essere configurata per la modalità con commit sincrono, quella con commit asincrono o per la modalità di sola configurazione. Se la replica primaria è configurata per la modalità con commit asincrono, non attende che alcuna replica secondaria scriva i record del log delle transazioni in ingresso su disco (per rafforzare il log). Se una replica secondaria specificata è configurata per la modalità di commit asincrono, la replica primaria non attende che quella replica secondaria registri il log. Se la replica primaria e una replica secondaria specifica vengono entrambe configurate per la modalità con commit sincrono, la replica primaria attende la conferma della finalizzazione del log da parte della replica secondaria, a meno che la replica secondaria non sia in grado di eseguire il ping alla replica primaria entro il periodo di timeout della sessionedella replica primaria.

Nota

Se il periodo di timeout della sessione della replica primaria viene superato da una replica secondaria, la replica primaria passa temporaneamente in modalità con commit asincrono per questa replica secondaria. Quando la replica secondaria si riconnette alla replica primaria, viene ripristinata la modalità con commit sincrono.

Modalità di disponibilità supportate

I gruppi di disponibilità AlwaysOn supportano tre modalità di disponibilità:

  • Modalità di commit asincrona
  • Modalità di commit sincrono
  • Modalità di sola configurazione

Lamodalità con commit asincrono è una soluzione di ripristino di emergenza che offre risultati ottimali quando le repliche di disponibilità sono distribuite a distanze considerevoli. Se ogni replica secondaria è in esecuzione in modalità con commit asincrono, la replica primaria non attende che il log venga memorizzato permanentemente da alcuna delle repliche secondarie. Bensì, subito dopo la scrittura del record del log nel file di log locale, tramite la replica primaria viene inviata la conferma della transazione al client. La replica primaria viene eseguita con una latenza della transazione minima a fronte di una replica secondaria configurata in modalità con commit asincrono. Se la replica primaria corrente è configurata per la modalità di disponibilità con commit asincrono, esegue il commit delle transazioni in modo asincrono per tutte le repliche secondarie indipendentemente dalle singole impostazioni della modalità di disponibilità.

Per altre informazioni, vedere Modalità di disponibilità con commit asincronopiù avanti in questo argomento.

Con lamodalità con commit sincrono si privilegia la disponibilità elevata rispetto alle prestazioni, aumentando tuttavia la latenza delle transazioni. In modalità di commit sincrono, le transazioni attendono per inviare la conferma della transazione al client fino a quando la replica secondaria non ha scritto il log su disco. Quando inizia la sincronizzazione dei dati in un database secondario, viene avviata l'applicazione dei record del log in entrata dal database primario corrispondente da parte della replica secondaria. Non appena è terminato l'indurimento di tutti i record del log, il database secondario entra nello stato SYNCHRONIZED. Successivamente, ogni nuova transazione viene indurita dalla replica di backup prima che il record del log venga scritto nel file di log locale. Una volta che tutti i database secondari di una determinata replica secondaria sono sincronizzati, la modalità con commit sincrono supporta il failover manuale e, facoltativamente, quello automatico.

Per altre informazioni, vedere Modalità di disponibilità con commit sincronopiù avanti in questo argomento.

La modalità di sola configurazione si applica ai gruppi di disponibilità che non si trovano in un Cluster di Failover di Windows Server. Una replica in modalità di sola configurazione non contiene dati utente. In modalità di sola configurazione il database master della replica archivia i metadati di configurazione del gruppo di disponibilità. Per altre informazioni, vedere Availability group with configuration only replica (Gruppo di disponibilità con replica di sola configurazione).

Nell'illustrazione seguente viene mostrato un gruppo di disponibilità con cinque repliche disponibili. Le repliche primarie e una secondaria sono configurate per la modalità di commit sincrono con failover automatico. Un'altra replica secondaria è configurata per la modalità con commit sincrono con solo failover manuale pianificato e due repliche secondarie sono configurate per la modalità con commit asincrono, che supporta solo il failover manuale forzato, in genere denominato failover forzato.

Disponibilità e modalità di failover delle repliche

La sincronizzazione e il comportamento di failover tra due repliche di disponibilità dipendono dalla modalità di disponibilità di entrambe le repliche. Ad esempio, per il commit sincrono, sia la replica primaria che la replica secondaria devono essere configurate per il commit sincrono. Analogamente per il failover automatico, entrambe le repliche devono essere configurate per il failover automatico. Il comportamento per lo scenario di distribuzione illustrato sopra può pertanto essere riepilogato nella tabella seguente in cui viene esaminato il comportamento con ogni potenziale replica primaria:

Replica primaria corrente Destinazioni di failover automatico Comportamento della modalità di commit sincrono Comportamento in modalità commit asincrono Failover automatico possibile
01 02 02 e 03 04 Sì
02 01 01 e 03 04 Sì
03 01 e 02 04 No
04 01, 02 e 03 No

In genere il nodo 04 come replica con commit asincrono viene distribuito in un sito per il ripristino di emergenza. Il fatto che i nodi 01, 02 e 03 rimangano nella modalità con commit asincrono dopo il failover al nodo 04 contribuisce ad evitare possibili cali delle prestazioni nel gruppo di disponibilità dovute all'elevata latenza di rete tra i due siti.

Modalità di disponibilità con commit asincrono

Nella modalità con commit asincronola replica secondaria non viene mai sincronizzata con la replica primaria. Anche se un determinato database secondario potrebbe essere aggiornato in base al database primario corrispondente, è possibile che un qualsiasi database secondario presenti un ritardo in qualsiasi momento. La modalità commit asincrono può essere utile in uno scenario di ripristino di emergenza in cui la replica primaria e la replica secondaria sono separate da una distanza significativa e in cui non si vuole che piccoli errori influiscano sulla replica primaria o in situazioni in cui le prestazioni sono più importanti della protezione dei dati sincronizzata. Inoltre, poiché la replica primaria non attende i riconoscimenti dalla replica secondaria, i problemi nella replica secondaria non influisce mai sulla replica primaria.

Una replica secondaria con commit asincrono cerca di tenere il passo con i record del log ricevuti dalla replica primaria. I database secondari con commit asincrono, tuttavia, rimangono sempre non sincronizzati ed è probabile che presentino un certo ritardo rispetto ai database primari corrispondenti. In genere, il gap tra un database secondario con commit asincrono e il database primario corrispondente è limitato, ma può diventare significativo in caso di overload del server in cui è ospitata la replica secondaria o se la rete è lenta.

L'unica forma di failover supportata dalla modalità con commit asincrono è il failover forzato (con possibile perdita di dati). Il failover forzato deve essere usato come ultima risorsa solo per le situazioni in cui la replica primaria corrente non sarà disponibile per un lungo periodo di tempo e la disponibilità immediata dei database primari risulti prioritaria rispetto al rischio di una possibile perdita di dati. La destinazione del failover deve essere una replica il cui ruolo è in stato di "SECONDARY" o "RESOLVING". La destinazione del failover assume il ruolo primario e le relative copie dei database diventano il database primario. Tutti i database secondari rimanenti, insieme ai database primari precedenti, non appena diventano disponibili, vengono sospesi finché non vengono ripresi singolarmente manualmente. In modalità commit asincrono, tutti i log delle transazioni che la replica primaria originale non aveva ancora inviato alla replica secondaria precedente vengono persi. Ciò significa che in alcuni o in tutti i nuovi database primari potrebbero mancare alcune transazioni di cui è stato eseguito il commit di recente. Per maggiori informazioni su come funziona il failover forzato e sulle migliori pratiche per il suo utilizzo, vedere Failover e modalità di failover (gruppi di disponibilità Always On).

Modalità di disponibilità con commit sincrono

In modalità di disponibilità con commit sincrono (modalità con commit sincrono), dopo essere stato aggiunto a un gruppo di disponibilità, un database secondario raggiunge il database primario corrispondente ed entra nello stato SYNCHRONIZED. Il database secondario rimane SYNCHRONIZED finché la sincronizzazione dei dati continua. Ciò garantisce che ogni transazione registrata in un determinato database primario venga registrata nel database secondario corrispondente. Una volta che tutti i database secondari in una determinata replica secondaria sono sincronizzati, lo stato di integrità della sincronizzazione della replica secondaria nel suo complesso è HEALTHY.

Contenuto della sezione

Fattori che interrompono la sincronizzazione dei dati

Una volta che tutti i relativi database sono sincronizzati, una replica secondaria viene impostata sullo stato HEALTHY. La replica secondaria sincronizzata rimane integra finché non si verifica uno degli eventi seguenti:

  • Un ritardo o un problema della rete o del computer comporta il timeout della sessione tra la replica secondaria e quella primaria.

    Nota

    Per informazioni sulla proprietà session-time delle repliche di disponibilità, vedere Panoramica di gruppi di disponibilità Always On (SQL Server).

  • Si sospende un database secondario nella replica secondaria. La replica secondaria non è più sincronizzata e il relativo stato di integrità della sincronizzazione viene contrassegnato come NOT_HEALTHY. La replica secondaria non può tornare funzionante finché il database secondario sospeso non viene ripreso e risincronizzato oppure rimosso dal gruppo di disponibilità.

  • Si aggiunge un database primario al gruppo di disponibilità. Le repliche secondarie precedentemente sincronizzate entrano nello stato di integrità della sincronizzazione NOT_HEALTHY. Questo stato indica che almeno un database si trova nello stato di NON SINCRONIZZAZIONE. Una determinata replica secondaria non può essere nuovamente in salute fino a quando un database secondario corrispondente non è stato preparato sulla replica, aggiunto al gruppo di disponibilità e sincronizzato con il nuovo database primario.

  • Si modifica la replica primaria o secondaria in modalità di disponibilità con commit asincrono. Dopo essere stata impostata sulla modalità di commit asincrono, la replica secondaria rimarrà nello stato di integrità della sincronizzazione HEALTHY finché la sincronizzazione dei dati continua. Tuttavia, se viene modificata alla modalità con commit asincrono solo la replica primaria, la replica secondaria con commit sincrono entrerà nello stato di integrità della sincronizzazione PARTIALLY_HEALTHY. Con questo stato viene indicato che almeno un database si trova nello stato SYNCHRONIZING, ma nessuno dei database si trova nello stato NOT SYNCHRONIZING.

  • Si può modificare qualsiasi replica secondaria in modalità di disponibilità con commit sincrono. In questo modo, la replica secondaria viene contrassegnata come in stato di integrità della sincronizzazione "PARTIALLY_HEALTHY" fino a quando tutti i suoi database si trovano nello stato di sincronizzazione "SYNCHRONIZED".

Suggerimento

Per visualizzare l'integrità della sincronizzazione di un gruppo di disponibilità, di una replica di disponibilità o di un database di disponibilità, eseguire una query sulla colonna synchronization_health o synchronization_health_desc di sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_stateso sys.dm_hadr_database_replica_statesrispettivamente.

Funzionamento della sincronizzazione in una replica secondaria

In modalità commit sincrono, dopo che una replica secondaria entra nel gruppo di disponibilità e stabilisce una sessione con la replica primaria:

  1. La replica secondaria scrive i record di log in ingresso su disco (rafforza il log).
  2. La replica secondaria invia un messaggio di conferma alla replica primaria.

Dopo che il log consolidato del database secondario ha raggiunto la fine del log del database primario, lo stato del database secondario viene impostato su SINCRONIZZATO.

Il tempo necessario per la sincronizzazione dipende dalla distanza tra il database secondario e il database primario all'inizio della sessione. Questo delta viene misurato in base al numero di record di log ricevuti inizialmente dalla replica primaria, al carico di lavoro sul database primario e alla velocità dell'host dell'istanza della replica secondaria.

Processo di transazione

In modalità commit sincrono, le transazioni vengono sottoposte a commit in entrambe le repliche in questo ordine:

  1. La replica primaria riceve una transazione da un client.

  2. La replica primaria scrive il record nel log delle transazioni e invia simultaneamente il record di log alle repliche secondarie.

    Dopo che un record di log viene scritto nel log delle transazioni del database primario, la transazione può essere annullata solo se è presente un failover in un database secondario che non ha ricevuto il log.

  3. La replica primaria attende conferma dalla replica secondaria con commit sincrono.

  4. La replica secondaria finalizza il log e restituisce una conferma alla replica primaria.

  5. La replica primaria completa l'elaborazione del commit e invia un messaggio di conferma al client.

Timeout di commit sincrono

Se si verifica il timeout di una replica secondaria con commit sincrono senza confermare la protezione avanzata del log, nel gruppo di disponibilità vengono eseguite le azioni seguenti:

  1. La replica primaria contrassegna la replica secondaria come non riuscita.
  2. Lo stato della replica secondaria cambia in DISCONNECTED.
  3. Il database primario smette di attendere la conferma.
  4. Il gruppo di disponibilità contrassegna lo stato di sincronizzazione come NOT SYNCHRONIZING e lo stato della replica come NOT_HEALTHY.

Questo comportamento garantisce che una replica secondaria con commit sincrono non riuscita non impedisca l'irrobustimento dei log nella replica primaria.

Quando la replica secondaria è di nuovo online:

  1. Lo stato della replica secondaria passa a CONNECTED.
  2. La replica secondaria elabora la coda di invio dei log della replica primaria.
  3. Lo stato di sincronizzazione passa a SYNCHRONIZING e l'integrità della replica a PARTIALLY_HEALTHY.

Dopo l'elaborazione della coda di invio del log, lo stato di sincronizzazione diventa SINCRONIZZATO e l'integrità della replica diventa SALUTARE.

Con la modalità con commit sincrono è possibile proteggere i dati richiedendone la sincronizzazione tra due posizioni, ma con un aumento della latenza delle transazioni.

Modalità di commit sincrono con solo failover manuale

Se queste repliche sono connesse e il database è sincronizzato, il failover manuale è supportato. Se la replica secondaria diventa inattiva, la replica primaria non viene influenzata. La replica primaria viene eseguita in modo esposto se non esistono repliche sincronizzate, senza inviare dati a nessuna replica secondaria. In caso di perdita della replica primaria, le repliche secondarie vengono impostate sullo stato RESOLVING, ma il proprietario del database può forzare un failover sulla replica secondaria (con possibile perdita di dati). Per altre informazioni, vedere Failover e le modalità di failover (Gruppi di disponibilità Always On).

Modalità commit sincrono con failover automatico

Con il failover automatico si garantisce disponibilità elevata assicurando che il database diventi di nuovo disponibile rapidamente dopo la perdita della replica primaria. Per configurare un gruppo di disponibilità per il failover automatico, è necessario impostare sia la replica primaria corrente sia almeno una replica secondaria sulla modalità di commit sincrono con failover automatico. SQL Server 2019 (15.x) ha aumentato il numero massimo di repliche sincrone a 5, rispetto a 3 in SQL Server 2017 (14.x). Puoi configurare questo gruppo di cinque repliche per avere un failover automatico all'interno del gruppo. Sono presenti una replica primaria e quattro repliche secondarie sincrone.

Inoltre, affinché un failover automatico sia possibile in un momento specifico, questa replica secondaria deve essere sincronizzata con la replica primaria (cioè tutti i database secondari sono sincronizzati) e per il cluster WSFC (Windows Server Failover Clustering) deve essere disponibile un quorum. Se la replica primaria non è disponibile in presenza di tali condizioni, si verifica il failover automatico. La replica secondaria assume il ruolo di replica primaria e il relativo database diventa il database primario. Per ulteriori informazioni, vedere la sezione "Failover automatico" dell'argomento Failover e modalità di failover (Gruppi di disponibilità Always On).

Nota

Per informazioni sul quorum WSFC e sui gruppi di disponibilità Always On, vedere Modalità quorum WSFC e configurazione del voto (SQL Server).

Latenza dei dati sulla replica secondaria

L'implementazione dell'accesso di sola lettura alle repliche secondarie è utile qualora i carichi di lavoro di sola lettura possono tollerare una certa latenza dei dati. Nelle situazioni in cui la latenza dei dati non può essere accettata, si consideri la possibilità di eseguire i carichi di lavoro di sola lettura nella replica primaria.

I record di log delle modifiche sul database primario vengono inviati dalla replica primaria alle repliche secondarie. In ogni database secondario, i record di log vengono applicati da un thread dedicato di redo. In un database secondario di accesso in lettura, una modifica dei dati specificata non viene visualizzata nei risultati della query fino a quando il record di log che contiene la modifica è stato applicato al database secondario e la transazione è stata sottoposta a commit nel database primario.

Ciò significa che c'è una certa latenza, in genere solo pochi secondi, tra le repliche primarie e secondarie. In rari casi, tuttavia, ad esempio se problemi di rete compromettono la velocità effettiva, la latenza può diventare significativa. La latenza aumenta quando si verificano colli di bottiglia I/O e quando viene sospeso lo spostamento dati. Per monitorare lo spostamento dei dati sospeso, è possibile utilizzare il Dashboard Always On o la vista di gestione dinamica sys.dm_hadr_database_replica_states.

Per altre informazioni sull'analisi della latenza di rollforward nella replica secondaria, vedere Risoluzione dei problemi: Le modifiche nella replica primaria non vengono riflesse nella replica secondaria.

Attività correlate

Per modificare la modalità di disponibilità e la modalità di failover

Per modificare i voti del quorum

Per eseguire un failover manuale

Per visualizzare il gruppo e la replica di disponibilità, nonché gli stati dei database

Contenuto correlato

Vedere anche

Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server)
Failover e modalità di failover (gruppi di disponibilità Always On)
WSFC (Windows Server Failover Clustering) con SQL Server