Condividi tramite

Che cos'è un gruppo di disponibilità Always On?

Si applica a:SQL Server

In questo articolo sono introdotti i concetti dei gruppi di disponibilità Always On, fondamentali per la configurazione e la gestione di uno o più gruppi di disponibilità nell’edizione Enterprise di SQL Server. Per l'edizione Standard, vedere Gruppi di disponibilità Always On di base per un database singolo.

I gruppi di disponibilità Always On sono una soluzione di disponibilità elevata e recupero di emergenza che offre un'alternativa di livello aziendale al mirroring del database. I Gruppi di disponibilità AlwaysOn ottimizzano la disponibilità di un set di database utente per un'azienda. Un gruppo di disponibilità supporta un ambiente di failover per un set discreto di database utente, noti come database di disponibilità, che eseguono il failover insieme. Un gruppo di disponibilità supporta un set di database primari di lettura e scrittura e da uno a otto set di database secondari corrispondenti. Facoltativamente, i database secondari possono essere resi disponibili per l'accesso di sola lettura e/o alcune operazioni di backup.

Con SQL Server abilitato da Azure Arc, è possibile visualizzare i gruppi di disponibilità nel portale di Azure.

Panoramica

Un gruppo di disponibilità supporta un ambiente di replica per un set discreto di database utente, noti come database di disponibilità. È possibile creare un gruppo di disponibilità per la disponibilità elevata (HA) o per la scalabilità in lettura. Un gruppo di disponibilità elevata è un set di database il cui failover viene eseguito contemporaneamente. Un gruppo di disponibilità Read-Scale è un insieme di database copiati in altre istanze di SQL Server per gestire carichi di lavoro in sola lettura. Un gruppo di disponibilità supporta un set di database primari e da uno a otto set di database secondari corrispondenti. I database secondari non sono dei backup. Continuare a eseguire il backup dei database e dei log delle transazioni regolarmente.

Suggerimento

È possibile creare qualsiasi tipo di backup di un database primario. In alternativa, è possibile creare backup del log e backup completi di sola copia dei database secondari. Per maggiori informazioni, vedere Spostamento dei backup supportati alle repliche secondarie di un gruppo di disponibilità.

Ogni set di database di disponibilità è ospitato da una replica di disponibilità. Esistono due tipi di repliche di disponibilità: una singola replica primaria, in cui sono ospitati i database primari e da una a otto repliche secondarie, ognuna ospitante un set di database secondari, che sono usate come destinazione del failover potenziale per il gruppo di disponibilità. Il failover di un gruppo di disponibilità avviene a livello di una replica di disponibilità. Una replica di disponibilità fornisce la ridondanza solo a livello di database, cioè per il set di database in un gruppo di disponibilità. I failover non sono dovuti a database ritenuti sospetti in seguito a una perdita di un file di dati o al danneggiamento di un log delle transazioni.

La replica primaria rende disponibili i database primari per le connessioni in lettura e scrittura dei client La replica primaria invia i record di log delle transazioni di ogni database primario a ogni database secondario. Questo processo, noto come sincronizzazione dei dati, si verifica a livello di database. Ogni replica secondaria memorizza nella cache i record del log delle transazioni (finalizza il log), quindi li applica al database secondario corrispondente. La sincronizzazione dei dati si verifica tra il database primario e ogni database secondario collegato, indipendentemente dagli altri database. Pertanto, un database secondario può essere sospeso o non riuscire senza influire su altri database secondari e un database primario può essere sospeso o non riuscire senza influire su altri database primari.

Facoltativamente, è possibile configurare una o più repliche secondarie per supportare l'accesso in sola lettura ai database secondari e una qualsiasi replica secondaria per consentire l'esecuzione di backup sui database secondari.

SQL Server 2017 ha introdotto due architetture diverse per i gruppi di disponibilità. I gruppi di disponibilità Always On offrono disponibilità elevata, ripristino di emergenza e bilanciamento del carico di lettura. Questi gruppi di disponibilità richiedono una gestione del cluster. In Windows, la funzionalità di clustering di failover fornisce la gestione del cluster. In Linux è possibile utilizzare Pacemaker. L'altra architettura è data dai gruppi di disponibilità con scalabilità in lettura. Un gruppo di disponibilità con scalabilità in lettura fornisce repliche per i carichi di lavoro di sola lettura, ma non un'elevata disponibilità. In un gruppo di disponibilità con scalabilità di lettura, non c'è un gestore del cluster, poiché il failover non può essere automatico.

La distribuzione di Gruppi di disponibilità Always On per alta disponibilità in Windows richiede un cluster WSFC (Windows Server Failover Cluster). Ogni replica di disponibilità di un determinato gruppo di disponibilità deve risiedere su un nodo diverso dello stesso cluster WSFC. L'unica eccezione è che quando viene eseguita la migrazione a un altro cluster WSFC, un gruppo di disponibilità può risiedere temporaneamente in due cluster.

Nota

Per informazioni sui gruppi di disponibilità in Linux, vedere Gruppo di disponibilità per SQL Server in Linux.

In una configurazione ad alta disponibilità, viene creato un ruolo cluster per ogni gruppo di disponibilità. Il cluster WSFC monitora questo ruolo per valutare lo stato di integrità della replica primaria. Il quorum di Gruppi di disponibilità Always On si basa su tutti i nodi del cluster WSFC, indipendentemente dal fatto che un nodo del cluster ospiti una replica di disponibilità o meno. A differenza del mirroring del database, non esiste alcun ruolo di testimone nei gruppi di disponibilità Always On.

Nota

Per informazioni sulla relazione dei componenti di SQL Server AlwaysOn con il cluster WSFC, vedere Windows Server Failover Clustering con SQL Server.

Di seguito viene illustrato un gruppo di disponibilità contenente una replica primaria e quattro repliche secondarie. Sono supportate fino a otto repliche secondarie, compresa una replica primaria e quattro repliche secondarie a commit sincrono.

Diagramma di un gruppo di disponibilità con cinque repliche.

Configurare la crittografia TLS 1.3

SQL Server 2025 (17.x) introduce il supporto Tabular Data Stream 8.0, che consente di applicare la crittografia TLS 1.3 per la comunicazione tra il cluster di failover di Windows Server e le repliche dei gruppi di disponibilità Always On. Per iniziare, vedere Connettersi con la crittografia rigorosa.

Termini e definizioni

Termine Descrizione
gruppo di disponibilità Un contenitore per un insieme di database, i database di disponibilità, che effettuano il failover insieme.
database di disponibilità Database che appartiene a un gruppo di disponibilità. Per ogni database di disponibilità, il gruppo di disponibilità gestisce una sola copia di lettura e scrittura (il database primario) e da una a otto copie di sola lettura (database secondari).
database primario Copia leggibile e scrivibile di un database di disponibilità.
database secondario Copia di sola lettura di un database di disponibilità.
replica di disponibilità Creazione di un'istanza di un gruppo di disponibilità che un'istanza specifica di SQL Server ospita e gestisce una copia locale di ogni database di disponibilità appartenente al gruppo di disponibilità. Sono disponibili due tipi di replica di disponibilità: una replica primaria e da una a otto repliche secondarie.
replica primaria Replica di disponibilità che rende disponibili i database primari per le connessioni in lettura e scrittura dai client e invia i record del log delle transazioni per ogni database primario a ogni replica secondaria.
replica secondaria Una replica di disponibilità che mantiene una copia secondaria di ogni database di disponibilità, e che rappresenta una destinazione potenziale del failover per il gruppo di disponibilità. Facoltativamente, una replica secondaria può supportare l'accesso in sola lettura ai database secondari creando backup sui database secondari.
listener del gruppo di disponibilità Nome del server a cui i client possono connettersi per accedere a un database in una replica primaria o secondaria di un gruppo di disponibilità. I listener del gruppo di disponibilità indirizzano le connessioni in ingresso alla replica primaria o a una replica secondaria in sola lettura.

Database di disponibilità

Per poter essere aggiunto a un gruppo di disponibilità, il database deve essere online, di lettura e scrittura ed esistere sull'istanza del server che ospita la replica primaria. Il database viene aggiunto al gruppo di disponibilità come database primario, pur rimanendo disponibile ai client. Non esiste alcun database secondario corrispondente fino a quando non si ripristinano i backup del nuovo database primario nell'istanza del server che ospita la replica secondaria (usando RESTORE WITH NORECOVERY). Il nuovo database secondario si trova nello stato di ripristino fino a quando non viene aggiunto al gruppo di disponibilità. Per altre informazioni, vedere Avviare lo spostamento dati su un database secondario Always On (SQL Server).

Dopo la creazione di un join, il database secondario passa allo stato ONLINE e avvia la sincronizzazione dati con il database primario corrispondente. Lasincronizzazione dati è il processo tramite cui le modifiche apportate a un database primario sono riprodotte in un database secondario. La sincronizzazione dei dati comporta che il database primario invia i record del log delle transazioni al database secondario.

Importante

Un database di disponibilità viene a volte definito replica di database in Transact-SQL, PowerShell e nei nomi di oggetti SMO (SQL Server Management Objects). Ad esempio, il termine "database replica" (replica di database) viene utilizzato nei nomi delle viste di gestione dinamica Always On che restituiscono informazioni sui database di disponibilità: sys.dm_hadr_database_replica_states e sys.dm_hadr_database_replica_cluster_states. Tuttavia, nella documentazione online di SQL Server il termine "replica" si riferisce solitamente alle repliche di disponibilità. Ad esempio, "replica primaria" e "replica secondaria" si riferiscono sempre a repliche di disponibilità.

Repliche di disponibilità

Ogni gruppo di disponibilità definisce un set di due o più partner di failover noti come repliche di disponibilità. Le repliche di disponibilità sono componenti del gruppo di disponibilità. Ogni replica di disponibilità ospita una copia dei database di disponibilità del gruppo di disponibilità. Per un determinato gruppo di disponibilità, istanze separate di SQL Server che risiedono in nodi diversi di un cluster WSFC devono ospitare le repliche di disponibilità. Ognuna di queste istanze del server deve essere abilitata per AlwaysOn.

SQL Server 2019 (15.x) aumenta il numero massimo di repliche sincrone a 5, rispetto a 3 in SQL Server 2017 (14.x). È possibile configurare questo gruppo di cinque repliche in modo da avere il failover automatico all'interno del gruppo. Sono presenti una replica primaria e quattro repliche secondarie sincrone.

In un'istanza specifica può essere ospitata solo una replica di disponibilità per ogni gruppo di disponibilità. Tuttavia, è possibile usare ogni istanza per molti gruppi di disponibilità. Un'istanza specificata può essere un'istanza autonoma o un'istanza del cluster di failover di SQL Server. Se è necessaria la ridondanza a livello di server, utilizzare le istanze di cluster di failover.

A ogni replica di disponibilità viene assegnato un ruolo iniziale, ovvero il ruolo primario o il ruolo secondario, che ereditano i database di disponibilità di tale replica. Il ruolo di una determinata replica determina se ospiterà database di lettura e scrittura o database di sola lettura. La replica primaria, a cui viene assegnato il ruolo primario, ospiterà i database di lettura e scrittura, noti come database primari. Ad almeno un'altra replica, nota come replica secondariaviene assegnato il ruolo secondario. Una replica secondaria ospita i database di sola lettura, noti come database secondari.

Nota

Quando il ruolo di una replica di disponibilità è indeterminato, ad esempio durante un failover, i relativi database si trovano temporaneamente nello stato NOT SYNCHRONIZING. Il ruolo è impostato su RESOLVING finché il ruolo della replica di disponibilità non si risolve. Se una replica di disponibilità assume il ruolo primario, i relativi database diventano i database primari. Se a una replica di disponibilità viene assegnato il ruolo secondario, i relativi database diventano secondari.

Modalità di disponibilità

Ogni replica di disponibilità ha una proprietà della modalità di disponibilità. La modalità di disponibilità determina se la replica primaria attende il commit delle transazioni in un database fino a quando una determinata replica secondaria scrive i record del log delle transazioni su disco (rafforza il log). Gruppi di disponibilità Always On supportano due modalità di disponibilità: modalità con commit asincrono e modalità con commit sincrono.

  • Modalità di commit asincrona

    Una replica di disponibilità che usa questa modalità di disponibilità viene chiamata replica con commit asincrono. Nella modalità commit asincrono, la replica primaria esegue il commit delle transazioni senza attendere la conferma da parte delle repliche con commit asincrono per consolidare i loro log delle transazioni. La modalità commit asincrono riduce la latenza delle transazioni sui database secondari, ma consente un certo ritardo rispetto ai database primari, rendendo possibile la perdita di dati.

  • Modalità commit sincrono

    Una replica di disponibilità che utilizza questa modalità di disponibilità è nota come replica con commit sincrono. In modalità commit sincrono, prima di eseguire il commit delle transazioni, una replica primaria attende che una replica secondaria riconosca di aver completato il consolidamento del log. Nella modalità commit sincrono si può essere sicuri che al termine della sincronizzazione di un determinato database secondario con il database primario, le transazioni di cui è stato eseguito il commit sono completamente protette. Questa protezione comporta un aumento della latenza delle transazioni. SQL Server 2017 ha introdotto in modo opzionale una funzionalità di repliche secondarie sincronizzate necessarie per aumentare ulteriormente la sicurezza, a costo della latenza, quando desiderato. La funzionalità REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT può essere abilitata per richiedere un numero specifico di repliche sincrone per eseguire il commit di una transazione prima che una replica primaria possa eseguire il commit.

Per altre informazioni, vedere Differenze tra le modalità di disponibilità per un gruppo di disponibilità Always On.

Tipi di failover

All'interno del contesto di una sessione tra la replica primaria e una replica secondaria, i ruoli primario e secondario possono scambiarsi in un processo noto come failover. Durante un failover, la replica secondaria di destinazione passa al ruolo primario e diventa la nuova replica primaria. La nuova replica primaria porta i relativi database online come database primari, consentendo alle applicazioni client di connettersi ad essi. Quando la replica primaria precedente è disponibile, viene modificata nel ruolo secondario e diventa una replica secondaria. I database primari precedenti diventano database secondari e la sincronizzazione dati viene ripresa.

Il failover di un gruppo di disponibilità avviene a livello di una replica di disponibilità. Il failover non si verifica a causa di problemi del database, come ad esempio quando un database viene ritenuto sospetto per la perdita di un file dati, l'eliminazione di un database o il danneggiamento di un registro delle transazioni.

Esistono tre forme di failover: automatico, manuale e forzato (con possibile perdita di dati). Il formato o le forme di failover supportate da una determinata replica secondaria dipendono dalla modalità di disponibilità. Per la modalità commit sincrono, dipende anche dalla modalità di failover nella replica primaria e nella replica secondaria di destinazione, come indicato di seguito.

  • La modalità commit sincrono supporta due forme di failover: failover manuale pianificato e failover automatico, se la replica secondaria è attualmente sincronizzata con la replica primaria. L'impostazione della modalità di failover nella proprietà dei partner di failover determina il supporto per queste forme di failover. Se si imposta la modalità di failover su manuale nella replica primaria o secondaria, la replica secondaria supporta solo il failover manuale. Se si imposta la modalità di failover su automatico nelle repliche primarie e secondarie, la replica secondaria supporta sia il failover automatico che quello manuale.

    • Failover manuale pianificato (senza perdita di dati)

    Un failover manuale si verifica dopo che un amministratore del database rilascia un comando di failover. Determina la transizione di una replica secondaria sincronizzata al ruolo primario (con protezione dei dati garantita) e alla replica primaria di passare al ruolo secondario. Un failover manuale richiede che sia la replica primaria che la replica secondaria di destinazione vengano eseguite in modalità commit sincrono e che la replica secondaria sia già sincronizzata.

    • Failover automatico (senza perdita di dati)

    Un failover automatico si verifica in risposta a un errore. Fa sì che una replica secondaria sincronizzata passi al ruolo primario (con protezione dei dati garantita). Quando la replica primaria precedente diventa disponibile, assume il ruolo secondario. Il failover automatico richiede che sia la replica primaria che la replica secondaria di destinazione vengano eseguite in modalità commit sincrono con la modalità di failover impostata su Automatico. È inoltre necessario che la replica secondaria sia già sincronizzata, disponga del quorum WSFC e soddisfi le condizioni specificate dai criteri di failover flessibili del gruppo di disponibilità.

  • Nella modalità commit asincrono, l'unica forma di failover supportata è il failover manuale forzato (con possibile perdita di dati), in genere denominato failover forzato. Il failover forzato è una forma di failover manuale perché è necessario avviarlo manualmente. Il failover forzato rappresenta un'opzione di ripristino di emergenza. È l'unica forma di failover possibile quando la replica secondaria di destinazione non è sincronizzata con la replica primaria.

Per ulteriori informazioni, vedere Failover e modalità di Failover (Gruppi di Disponibilità Always On).

Importante

  • Le istanze del cluster di failover di SQL Server non supportano il failover automatico da parte dei gruppi di disponibilità, quindi è possibile configurare solo il failover manuale per qualsiasi replica di disponibilità ospitata da un'istanza del cluster di failover.
  • Se si esegue un comando di failover forzato su una replica secondaria sincronizzata, la replica secondaria si comporta come con un failover manuale pianificato.

Vantaggi

I gruppi di disponibilità Always On offrono un ampio set di opzioni con cui è possibile migliorare la disponibilità del database e l’uso delle risorse. I componenti chiave sono i seguenti:

Connessioni cliente

È possibile fornire la connettività del client alla replica primaria di un determinato gruppo di disponibilità creando un listener di gruppo di disponibilità. Un listener del gruppo di disponibilità fornisce un insieme di risorse associato a un determinato gruppo di disponibilità per reindirizzare le connessioni client alla replica di disponibilità appropriata.

Un listener del gruppo di disponibilità è associato a un nome DNS univoco che funge da nome di rete virtuale (VNN), a uno o più indirizzi IP virtuali (VIP) e a un numero di porta TCP. Per altre informazioni, vedere Connessione a un listener di un gruppo di disponibilità Always On.

Se un gruppo di disponibilità ha solo due repliche di disponibilità e non è configurato per consentire l'accesso in lettura alla replica secondaria, i client possono connettersi alla replica primaria usando una stringa di connessione del mirroring del database. Questo approccio può essere utile temporaneamente dopo la migrazione di un database dal mirroring del database a Gruppi di disponibilità Always On. Prima di aggiungere repliche secondarie, è necessario creare un listener del gruppo di disponibilità per il gruppo di disponibilità e aggiornare le applicazioni in modo da usare il nome di rete del listener.

Nota

SQL Server 2025 (17.x) introduce il supporto TDS 8.0, che consente di applicare la crittografia TLS 1.3 rigorosa per le connessioni alle repliche e al listener del gruppo di disponibilità AlwaysOn.

Requisiti di configurazione:

  • Nuovi gruppi di disponibilità: creare il gruppo di disponibilità (AG) con Encrypt=Strict nella clausola CLUSTER_CONNECTION_OPTIONS ed effettuare il failover per applicare le impostazioni.
  • Gruppi di disponibilità esistenti: Alterare il AG con la clausola CLUSTER_CONNECTION_OPTIONS per impostare Encrypt=Strict e effettuare il failover per applicare le impostazioni.
  • Forza crittografia stretta: impostare questa opzione su Sì in SQL Server Configuration Manager per ogni replica e riavviare le repliche di SQL Server.
  • Requisiti del certificato: quando Encrypt=Strict è impostato, TrustServerCertificate verrà ignorato.

Per iniziare, vedere Connettersi con la crittografia rigorosa.

Repliche secondarie attive

I gruppi di disponibilità "Always On" supportano le repliche secondarie attive. Le capacità secondarie attive includono il supporto per:

  • Esecuzione di operazioni di backup sulle repliche secondarie

    Le repliche secondarie supportano l'esecuzione di backup del log e di backup di sola copia di un database completo, file o filegroup. È possibile configurare il gruppo di disponibilità per specificare una preferenza per la destinazione dei backup. È importante comprendere che SQL Server non applica la preferenza, quindi non ha alcun effetto sui backup ad hoc. L'interpretazione di questa preferenza dipende dalla logica, se presente, che usate nello script nei job di backup per ciascun database di un determinato gruppo di disponibilità. Per una replica di disponibilità singola, è possibile specificare la priorità di esecuzione dei backup in questa replica rispetto alle altre repliche dello stesso gruppo di disponibilità. Per maggiori informazioni, vedere Spostamento dei backup supportati alle repliche secondarie di un gruppo di disponibilità.

  • Accesso in sola lettura a una o più repliche secondarie (repliche secondarie leggibili)

    È possibile configurare qualsiasi replica di disponibilità secondaria per consentire solo l'accesso in sola lettura ai database locali, anche se alcune operazioni non sono completamente supportate. Questa configurazione impedisce i tentativi di connessione in lettura/scrittura alla replica secondaria. È anche possibile impedire carichi di lavoro di sola lettura nella replica primaria consentendo solo l'accesso in lettura/scrittura. Questa configurazione impedisce l'esecuzione di connessioni di sola lettura alla replica primaria. Per ulteriori informazioni, vedere Spostare il carico di lavoro di sola lettura su una replica secondaria di un gruppo di disponibilità Always On.

    Se un gruppo di disponibilità dispone attualmente di un listener del gruppo di disponibilità e di una o più repliche secondarie leggibili, SQL Server può instradare le richieste di connessione con finalità di lettura a una di esse (routing di sola lettura). Per altre informazioni, vedere Connessione a un listener di un gruppo di disponibilità Always On.

Periodo di timeout della sessione

Il periodo di timeout della sessione è una proprietà della replica di disponibilità che determina per quanto tempo una connessione con un'altra replica di disponibilità può rimanere inattiva prima che la connessione venga chiusa. Le repliche primarie e secondarie effettuano vicendevolmente il ping per segnalare che ancora sono attive. La ricezione di un ping dall'altra replica durante il periodo di timeout indica che la connessione è ancora aperta e che le istanze del server sono in comunicazione. Alla ricezione di un ping, la replica di disponibilità reimposta il contatore del timeout della sessione per quella connessione.

Il periodo di timeout della sessione impedisce alla replica di attendere indefinitamente la ricezione di un ping dall'altra replica. Se non viene ricevuto alcun ping dall'altra replica entro il periodo di timeout della sessione, si verifica il timeout della replica. La connessione si chiude e la replica di timeout entra nello stato DISCONNECTED. Anche se la replica disconnessa è configurata per la modalità con commit sincrono, le transazioni non attendono che quella replica venga riconnessa e risincronizzata.

Il periodo di timeout della sessione predefinito per ogni replica di disponibilità è di 10 secondi. È possibile configurare questo valore, con un minimo di 5 secondi. In genere, mantenere il periodo di timeout a 10 secondi o superiore. Con un valore inferiore a 10 secondi, può verificarsi un sovraccarico del sistema, con generazione di falsi errori.

Nota

Nel ruolo di risoluzione, il periodo di timeout della sessione non si applica perché il ping non viene eseguito.

Correzione di pagina automatica

Ogni replica di disponibilità tenta di recuperare automaticamente delle pagine danneggiate su un database locale risolvendo determinati tipi di errore che impediscono la lettura di una pagina di dati. Se una replica secondaria non legge una pagina, la replica richiede alla replica primaria una copia aggiornata della pagina. Se la replica primaria non legge una pagina, la replica trasmette una richiesta per una copia aggiornata a tutte le repliche secondarie e ottiene la pagina dalla prima replica secondaria che risponderà. Se la richiesta viene soddisfatta, la pagina illeggibile viene sostituita dalla copia e l'errore viene risolto.

Per altre informazioni, vedere Correzione automatica della pagina (Gruppi di disponibilità/Mirroring del database).

Interoperabilità e coesistenza con altre funzionalità del motore di database

I gruppi di disponibilità AlwaysOn funzionano con le funzionalità o i componenti seguenti di SQL Server:

Passaggio successivo

Introduzione ai gruppi di disponibilità Always On

  • Last updated on