Condividi tramite

Panoramica dei gruppi di disponibilità AlwaysOn (SQL Server)

Questo argomento presenta i concetti relativi ai gruppi di disponibilità AlwaysOn fondamentali per la configurazione e la gestione di uno o più gruppi di disponibilità in SQL Server 2014. Per un riepilogo dei vantaggi offerti dai gruppi di disponibilità e una panoramica della terminologia dei gruppi di disponibilità AlwaysOn, vedere Gruppi di disponibilità AlwaysOn (SQL Server).

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 insieme di database primari e da uno a otto insiemi di database secondari corrispondenti. I database secondari non sono backup. Continuare a eseguire regolarmente il backup dei database e dei relativi log delle transazioni.

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 altre informazioni, vedere Repliche secondarie attive: Backup in repliche secondarie (gruppi di disponibilità AlwaysOn).

Ogni set di database di disponibilità è ospitato da una replica di disponibilità. Esistono due tipi di repliche di disponibilità: una singola replica primaria. che ospita i database primari e una o otto repliche secondarie, ognuna delle quali ospita un set di database secondari e funge da potenziali destinazioni di failover per il gruppo di disponibilità. Il failover di un gruppo di disponibilità avviene al livello di una replica di disponibilità. Una replica di disponibilità offre ridondanza solo a livello di database per il set di database in un gruppo di disponibilità. I failover non sono causati da problemi del database, come quando un database diventa inaffidabile per la perdita di un file di dati o il danneggiamento di un log delle transazioni.

La replica primaria rende disponibili i database primari per le connessioni in lettura e scrittura dei client Inoltre, in un processo noto come sincronizzazione dei dati, che si verifica a livello di database. La replica primaria invia i record di log delle transazioni di ogni database primario a ogni database secondario. 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.

La distribuzione di gruppi di disponibilità AlwaysOn richiede un cluster WSFC (Windows Server Failover Clustering). Ogni replica di disponibilità di un determinato gruppo di disponibilità deve risiedere in 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.

Il gruppo di risorse WSFC viene creato per ogni gruppo di disponibilità che viene creato. Il cluster WSFC monitora questo gruppo di risorse per valutare l'integrità della replica primaria. Il quorum per i gruppi di disponibilità AlwaysOn si basa su tutti i nodi del cluster WSFC indipendentemente dal fatto che un determinato nodo del cluster ospiti repliche di disponibilità. A differenza del mirroring del database, non esiste alcun ruolo di controllo nei gruppi di disponibilità AlwaysOn.

Annotazioni

Per informazioni sulla relazione dei componenti AlwaysOn di SQL Server con il cluster WSFC, vedere Windows Server Failover Clustering (WSFC) 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, tra cui una replica primaria e due repliche secondarie con commit sincrono.

Gruppo di disponibilità con cinque repliche

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 finché i backup del nuovo database primario non sono ripristinati sull'istanza del server che ospita la replica secondaria (tramite RESTORE WITH NORECOVERY). Il nuovo database secondario si trova nello stato RESTORE fino a quando non viene aggiunto al gruppo di disponibilità. Per altre informazioni, vedere Avviare lo spostamento dati in un database secondario AlwaysOn (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 "replica di database" viene usato nei nomi delle viste a gestione dinamica AlwaysOn 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à, le repliche di disponibilità devono essere ospitate da istanze separate di SQL Server che risiedono in nodi diversi di un cluster WSFC. Ognuna di queste istanze del server deve essere abilitata per AlwaysOn.

In un'istanza specifica può essere ospitata solo una replica di disponibilità per ogni gruppo di disponibilità. Tuttavia, ogni istanza può essere usata per numerosi 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, ereditato dai database di disponibilità della replica in questione. 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.

Annotazioni

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 loro ruolo rimane impostato su RESOLVING finché il ruolo della replica di disponibilità non viene definito. 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à

La modalità di disponibilità è una proprietà di ogni replica di disponibilità. La modalità di disponibilità determina se la replica primaria attende a impegnare le transazioni in un database fino a quando una determinata replica secondaria non ha scritto i record del log delle transazioni su disco (assicurando la durabilità del log). I gruppi di disponibilità AlwaysOn supportano due modalità di disponibilità, la modalità commit asincrono e la modalità commit sincrono.

  • Modalità commit asincrono

    Una replica che usa questa modalità di disponibilità è nota comereplica con commit asincrono. Nella modalità commit asincrono, la replica primaria esegue il commit delle transazioni senza attendere la conferma della finalizzazione del log da una replica secondaria con commit asincrono. 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. Nella modalità commit sincrono, prima di eseguire il commit delle transazioni, una replica primaria con commit sincrono attende il riconoscimento da parte di una replica secondaria con commit sincrono di aver completato l'irrigidimento 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.

Per altre informazioni, vedere Modalità di disponibilità (gruppi di disponibilità AlwaysOn).

Tipi di failover

Nel contesto di una sessione tra la replica primaria e una replica secondaria, i ruoli primari e secondari sono potenzialmente intercambiabili in un processo noto come failover. Durante un failover la replica secondaria di destinazione passa al ruolo primario, diventando la nuova replica primaria. La nuova replica primaria porta i relativi database online come database primari, consentendo alle applicazioni client di connettersi ad essi. Se la replica primaria precedente è disponibile, assume il ruolo secondario, diventando una replica secondaria. I database primari precedenti diventano database secondari e la sincronizzazione dati viene ripresa.

Sono disponibili tre tipi di failover: automatico, manuale e forzato (con possibile perdita di dati). La forma o le forme di failover supportate da una determinata replica secondaria dipendono dalla modalità di disponibilità della stessa e, per la modalità commit sincrono, dalla modalità di failover della replica primaria e della replica secondaria di destinazione.

  • La modalità di commit sincrono supporta due forme di failover: failover manuale pianificato e failover automatico, a condizione che la replica secondaria di destinazione sia attualmente sincronizzata con avt1. Il supporto per queste forme di failover dipende dall'impostazione della proprietà della modalità di failover sui partner di failover. Se la modalità di failover è impostata su "manuale" sulla replica primaria o su quella secondaria, per la replica secondaria è supportato solo il failover manuale. Se la modalità di failover è impostata su "automatico" sia sulla replica primaria sia sulle repliche secondarie, sulla replica secondaria sono supportate entrambe le forme di failover, manuale e automatico.

    • Failover manuale pianificato (senza perdita di dati)

      Si verifica un failover manuale quando un amministratore di database esegue un comando di failover causando il passaggio di una replica secondaria sincronizzata al ruolo primario (con protezione dei dati garantita) e della replica primaria al ruolo secondario. Un failover manuale richiede che sia la replica primaria sia la replica secondaria di destinazione siano eseguite nella 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 che causa il passaggio di una replica secondaria sincronizzata 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 siano in esecuzione in modalità di commit sincrona con la modalità di failover impostata su "automatico". Inoltre, la replica secondaria deve essere già sincronizzata, avere il quorum WSFC e soddisfare le condizioni specificate dalla politica di failover flessibile del gruppo di disponibilità.

      Importante

      Le istanze del cluster di failover di SQL Server non supportano il failover automatico da gruppi di disponibilità, pertanto le replica di disponibilità ospitate da un'istanza del cluster di failover possono essere configurate solo per il failover manuale.

    Annotazioni

    Si noti che se si esegue un comando di failover forzato in una replica secondaria sincronizzata, la replica secondaria si comporta come per un failover manuale pianificato.

  • 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 è considerato una forma di failover manuale, in quanto può essere avviato solo 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 altre informazioni, vedere Failover e modalità di failover (gruppi di disponibilità AlwaysOn).

Connessioni client

È 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 Listener del gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server).

Suggerimento

Se un gruppo di disponibilità possiede 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 ai gruppi di disponibilità AlwaysOn. Prima di aggiungere altre repliche secondarie, sarà necessario creare un listener per il gruppo di disponibilità e aggiornare le applicazioni in modo da utilizzare il nome di rete del listener.

Repliche secondarie attive

I gruppi di disponibilità Always On supportano 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 la preferenza non viene applicata da SQL Server, quindi non ha alcun impatto sui backup ad hoc. L'interpretazione di questa preferenza dipende dalla logica, se presente, che si scrive negli script nei processi di backend per ognuno dei database in un gruppo di disponibilità specificato. 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 altre informazioni, vedere Repliche secondarie attive: Backup in repliche secondarie (gruppi di disponibilità AlwaysOn).

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

    Qualsiasi replica di disponibilità può essere configurata per consentire l'accesso in sola lettura ai database locali durante l'esecuzione del ruolo secondario, anche se alcune operazioni non sono completamente supportate. Inoltre, se si vuole impedire l'esecuzione di carichi di lavoro di sola lettura nella replica primaria, è possibile configurare le repliche in modo da consentire solo l'accesso in lettura/scrittura durante l'esecuzione nel ruolo primario. Per altre informazioni, vedere Repliche secondarie attive: repliche secondarie leggibili (gruppi di disponibilità AlwaysOn).

    Se un gruppo di disponibilità possiede attualmente un listener del gruppo di disponibilità e 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 Listener del gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server).

Periodo Session-Timeout

Il periodo di timeout della sessione è una proprietà della replica disponibile che determina quanto tempo la connessione con un'altra replica disponibile può rimanere inattiva prima che la connessione venga chiusa. Le repliche primarie e secondarie si inviano un ping tra loro per indicare che sono ancora 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 comunicano. 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 viene chiusa e per la replica scaduta viene impostato lo stato DISCONNECTED. Anche se una replica disconnessa è configurata per la modalità commit sincrono, le transazioni non attenderanno la riconnessione e la risincronizzazione di tale replica.

Il periodo di timeout della sessione predefinito per ogni replica di disponibilità è di 10 secondi. Questo valore è configurabile dall'utente (minimo 5 secondi). È consigliabile usare generalmente un periodo di timeout di almeno 10 secondi. Con un valore inferiore a 10 secondi, può verificarsi un sovraccarico del sistema, con generazione di falsi errori.

Annotazioni

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

Riparazione automatica della pagina

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 riesce a leggere una pagina, la replica richiede una nuova copia della pagina dalla replica primaria. Se la replica primaria non è in grado di leggere una pagina, la replica primaria trasmette una richiesta di una copia fresca a tutte le repliche secondarie e ottiene la pagina dal primo a rispondere. Se la richiesta viene soddisfatta, la pagina illeggibile viene sostituita dalla copia e l'errore viene risolto.

Per altre informazioni, vedere Ripristino automatico della pagina (per i gruppi di disponibilità e il mirroring del database).

Attività correlate

Contenuto correlato

Vedere anche

Modalità di Disponibilità (Gruppi di Disponibilità AlwaysOn)Failover e Modalità di Failover (Gruppi di Disponibilità AlwaysOn)Panoramica delle Istruzioni Transact-SQL per i Gruppi di Disponibilità AlwaysOn (SQL Server)Panoramica dei Cmdlet di PowerShell per i Gruppi di Disponibilità AlwaysOn (SQL Server)Supporto dell'Alta Disponibilità per database OLTP In-MemoryPrerequisiti, Restrizioni e Consigli per i Gruppi di Disponibilità AlwaysOn (SQL Server)Creazione e Configurazione di Gruppi di Disponibilità (SQL Server)Secondari Attivi: Repliche Secondarie Leggibili (Gruppi di Disponibilità AlwaysOn)Secondari Attivi: Backup su Repliche Secondarie (Gruppi di Disponibilità AlwaysOn)Listener del Gruppo di Disponibilità, Connettività Client e Failover dell'Applicazione (SQL Server)

  • Last updated on