Condividi tramite

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

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 una replica secondaria con commit sincrono supera il periodo di timeout della sessione della replica primaria (il valore predefinito è 10 secondi), la replica primaria contrassegna temporaneamente lo stato di sincronizzazione di ogni database in questa replica secondaria come NOT SYNCHRONIZING e lo stato della replica come NOT_HEALTHY. 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 Asynchronous-Commit modalità di disponibilità più avanti in questo articolo.

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 ogni record di log è stato sottoposto a protezione avanzata, il database secondario entra nello SYNCHRONIZED stato. 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 Synchronous-Commit modalità di disponibilità più avanti in questo articolo.

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 di replica master archivia i metadati di configurazione del gruppo di disponibilità. Per altre informazioni, vedi Disponibilità elevata e protezione dei dati per le configurazioni del gruppo di disponibilità.

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.

Diagramma delle modalità di disponibilità e 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. Di conseguenza, il comportamento per lo scenario di distribuzione illustrato in precedenza può essere riepilogato nella tabella seguente, che esplora il comportamento con ogni potenziale replica primaria:

Replica primaria attuale Destinazioni di failover automatico Comportamento della modalità commit sincrono con Comportamento della modalità commit asincrona con 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 di failover deve essere una replica il cui ruolo è nello stato 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à commit sincrono), dopo essere stato aggiunto a un gruppo di disponibilità, un database secondario raggiunge il database primario corrispondente e passa allo SYNCHRONIZED stato. 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. Quando ogni database secondario in una determinata replica secondaria viene sincronizzato, lo stato di integrità della sincronizzazione della replica secondaria nel suo complesso è HEALTHY.

In questa sezione:

Fattori che interrompono la sincronizzazione dei dati

Una volta sincronizzati tutti i database, una replica secondaria entra nello HEALTHY stato . La replica secondaria sincronizzata rimane integra a meno che non si verifichi uno dei seguenti elementi:

  • 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 Che cos'è un gruppo di disponibilità AlwaysOn?

  • 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. Questo stato indica che almeno un database si trova nello stato di NOT SYNCHRONIZING sincronizzazione. Una replica secondaria specificata non può essere HEALTHY nuovamente eseguita fino a quando non è stato preparato un database secondario corrispondente nella replica, è stato aggiunto al gruppo di disponibilità ed è diventato sincronizzato con il nuovo database primario.

  • Si modifica la replica primaria o secondaria in modalità di disponibilità con commit asincrono. Dopo la modifica alla modalità di commit asincrona, la replica secondaria rimarrà nello stato di integrità della sincronizzazione, fintanto che la sincronizzazione dei dati continua. Tuttavia, se solo la replica primaria viene modificata in modalità con commit asincrono, la replica secondaria con commit sincrono entrerà nello stato di integrità della PARTIALLY_HEALTHY sincronizzazione. Questo stato indica che almeno un database è nello SYNCHRONIZING stato di sincronizzazione, ma nessuno dei database è nello NOT SYNCHRONIZING stato .

  • Si può modificare qualsiasi replica secondaria in modalità di disponibilità con commit sincrono. Ciò fa sì che la replica secondaria venga contrassegnata come nello PARTIALLY_HEALTHY stato di integrità della sincronizzazione fino a quando tutti i relativi database non sono nello SYNCHRONIZED stato di sincronizzazione.

Suggerimento

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

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 sul database secondario ha raggiunto la fine del log sul database primario, lo stato del database secondario è impostato su SYNCHRONIZED.

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 passa a 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 SYNCHRONIZINGe l'integrità della replica a PARTIALLY_HEALTHY.

Dopo l'elaborazione della coda di invio del log, lo stato di sincronizzazione diventa SYNCHRONIZEDe l'integrità della replica diventa HEALTHY.

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 funziona esposta se non esistono repliche SYNCHRONIZED, ovvero senza inviare dati a una replica secondaria. Se la replica primaria viene persa, le repliche secondarie entrano nello RESOLVING stato, ma il proprietario del database può forzare un failover nella 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'articolo 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 usare il dashboard del gruppo di disponibilità AlwaysOn (SQL Server Management Studio) o la visualizzazione a gestione dinamica sys.dm_hadr_database_replica_states.

Per ridurre la latenza nell'anteprima di SQL Server 2025 (17.x) e versioni successive, è possibile ridurre il tempo (in millisecondi) impiegato dalla replica primaria per eseguire il commit delle transazioni nella replica secondaria. Per altre informazioni, vedere Configurazione del server: tempo di commit del gruppo di disponibilità (ms).

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