Disponibilità elevata e protezione dei dati per le configurazioni dei gruppi di disponibilità

Si applica a:SQL Server - Linux

Questo articolo presenta le configurazioni di distribuzione supportate per i gruppi di disponibilità Always On di SQL Server sui server Linux. Un gruppo di disponibilità offre il supporto per disponibilità elevata e protezione dei dati. Il rilevamento automatico degli errori, il failover automatico e la riconnessione trasparente dopo il failover assicurano una disponibilità elevata. Le repliche sincronizzate garantiscono la protezione dei dati.

In un cluster WSFC (Windows Server Failover Cluster), una configurazione comune per la disponibilità elevata usa due repliche sincrone e un terzo server o una condivisione file per il quorum. Il server di controllo della condivisione file convalida la configurazione del gruppo di disponibilità, ad esempio lo stato della sincronizzazione e il ruolo della replica. Questa configurazione garantisce che la replica secondaria selezionata come destinazione del failover sia aggiornata con le modifiche più recenti ai dati e alla configurazione del gruppo di disponibilità.

Il cluster WSFC sincronizza i metadati di configurazione per l'arbitraggio del failover tra le repliche del gruppo di disponibilità e il server di controllo della condivisione file. Quando un gruppo di disponibilità non si trova in un cluster WSFC, le istanze di SQL Server archiviano i metadati di configurazione nel database master.

Ad esempio, un gruppo di disponibilità in un cluster Linux ha l'impostazione CLUSTER_TYPE = EXTERNAL. Non è disponibile alcun cluster WSFC per l'arbitraggio del failover. In questo caso, i metadati di configurazione vengono gestiti dalle istanze di SQL Server. Poiché in questo cluster non è presente alcun server di controllo, per archiviare i metadati dello stato di configurazione è necessaria una terza istanza di SQL Server. Tutte e tre le istanze di SQL Server forniscono insieme l'archiviazione dei metadati distribuita per il cluster.

Il modulo di gestione cluster può eseguire una query sulle istanze di SQL Server nel gruppo di disponibilità e orchestrare il failover per mantenere la disponibilità elevata. In un cluster Linux, il modulo di gestione cluster è Pacemaker.

SQL Server 2017 CU 1 consente la disponibilità elevata per un gruppo di disponibilità con CLUSTER_TYPE = EXTERNAL per due repliche sincrone e una replica di sola configurazione. La replica di sola configurazione può essere ospitata in qualsiasi edizione di SQL Server 2017 CU 1 o di una versione successiva, inclusa l'edizione SQL Server Express. La replica di sola configurazione gestisce le informazioni di configurazione relative al gruppo di disponibilità nel database master, ma non contiene i database utente nel gruppo di disponibilità.

Effetti della configurazione sulle impostazioni predefinite delle risorse

In SQL Server 2017 è stata introdotta l'impostazione REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT per le risorse cluster. Questa impostazione consente di assicurarsi che nel numero specificato di repliche secondarie i dati delle transazioni vengano scritti nel log prima che la replica primaria esegua il commit di ogni transazione. Quando si usa un modulo di gestione cluster esterno, questa impostazione ha effetto sia sulla disponibilità elevata che sulla protezione dei dati. Il valore predefinito per l'impostazione dipende dall'architettura nel momento in cui viene creata la risorsa cluster. Quando si installa l'agente delle risorse SQL Server, mssql-server-ha, e si crea una risorsa cluster per il gruppo di disponibilità, il modulo di gestione cluster rileva la configurazione del gruppo di disponibilità e imposta REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT di conseguenza.

Se supportato dalla configurazione, il parametro REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT dell'agente delle risorse è impostato sul valore che fornisce disponibilità elevata e protezione dei dati. Per altre informazioni, vedere Informazioni sull'agente delle risorse SQL Server per Pacemaker.

Le sezioni seguenti illustrano il comportamento predefinito per la risorsa cluster.

Scegliere un modello di progettazione del gruppo di disponibilità per soddisfare specifici requisiti aziendali in termini di disponibilità elevata, protezione dei dati e scalabilità in lettura.

Le configurazioni seguenti descrivono i modelli di progettazione del gruppo di disponibilità e le funzionalità di ogni modello. Questi modelli di progettazione si applicano ai gruppi di disponibilità con CLUSTER_TYPE = EXTERNAL per le soluzioni a disponibilità elevata.

• Tre repliche sincrone
• Due repliche sincrone
• Due repliche sincrone e una replica di sola configurazione

Tre repliche sincrone

Questa configurazione è costituita da tre repliche sincrone. Per impostazione predefinita, fornisce disponibilità elevata e protezione dei dati. Può anche fornire scalabilità in lettura.

Un gruppo di disponibilità con tre repliche sincrone può fornire scalabilità in lettura, disponibilità elevata e protezione dei dati. La tabella seguente descrive il comportamento della disponibilità.

Comportamento della disponibilità	Scalabilità in lettura	Disponibilità elevata e protezione dei dati	Protezione dei dati
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0	1 1	2
Interruzione primaria	Failover automatico. Potrebbe verificarsi la perdita di dati. La nuova replica primaria è L/S.	Failover automatico. La nuova replica primaria è L/S.	Failover automatico. La nuova replica primaria non è disponibile per le transazioni di aggiornamento utente finché la replica primaria precedente non viene ripristinata e aggiunta al gruppo di disponibilità come replica secondaria.
Interruzione di una replica secondaria	La replica primaria è L/S.	La replica primaria è L/S.	La replica primaria non è disponibile per le transazioni di aggiornamento utente finché la replica secondaria non riuscita non viene ripristinata e aggiunta al gruppo di disponibilità.

¹ Impostazione predefinita

Due repliche sincrone

Questa configurazione consente la protezione dei dati. Come per le altre configurazioni del gruppo di disponibilità, è possibile abilitare la scalabilità in lettura. La configurazione con due repliche sincrone non fornisce disponibilità elevata automatica. Una configurazione di questo tipo è applicabile solo a SQL Server 2017 RTM e non è più supportata con le versioni successive (CU1 e superiori) di SQL Server 2017.

Un gruppo di disponibilità con due repliche sincrone fornisce scalabilità in lettura e protezione dei dati. La tabella seguente descrive il comportamento della disponibilità.

Comportamento della disponibilità	Scalabilità in lettura	Protezione dei dati
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0 1	1
Interruzione primaria	Failover automatico. Potrebbe verificarsi la perdita di dati. La nuova replica primaria è L/S.	Failover automatico. La nuova replica primaria non è disponibile per le transazioni di aggiornamento utente finché la replica primaria precedente non viene ripristinata e aggiunta al gruppo di disponibilità come replica secondaria.
Interruzione di una replica secondaria	La replica primaria è L/S, con esecuzione esposta alla perdita di dati.	La replica primaria non è disponibile per le transazioni di aggiornamento utente finché la replica secondaria non viene ripristinata.

¹ Impostazione predefinita

Due repliche sincrone e una replica di sola configurazione

Un gruppo di disponibilità con due (o più) repliche sincrone e una replica di sola configurazione fornisce protezione dei dati e potrebbe anche offrire disponibilità elevata. Nel diagramma seguente è illustrata questa architettura:

1. Replica sincrona dei dati utente nella replica secondaria. Sono inclusi anche i metadati di configurazione del gruppo di disponibilità.
2. Replica sincrona dei metadati di configurazione del gruppo di disponibilità. Non sono inclusi i dati utente.

Nel diagramma del gruppo di disponibilità, una replica primaria inserisce tramite push i dati di configurazione sia nella replica secondaria sia in quella di sola configurazione. La replica secondaria riceve anche i dati utente. La replica di sola configurazione non riceve i dati utente. La replica secondaria è in modalità di disponibilità sincrona. La replica di sola configurazione non contiene i database del gruppo di disponibilità, ma solo i metadati relativi al gruppo di disponibilità. I dati di configurazione nella replica di sola configurazione vengono sottoposti a commit in modo sincrono.

Nota

Un gruppo di disponibilità con replica di sola configurazione rappresenta una novità per SQL Server 2017 CU 1. In tutte le istanze di SQL Server nel gruppo di disponibilità deve essere installato SQL Server 2017 CU 1 o versione successiva.

Il valore predefinito per REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT è 0. La tabella seguente descrive il comportamento della disponibilità.

Comportamento della disponibilità	Disponibilità elevata e protezione dei dati	Protezione dei dati
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0 1	1
Interruzione primaria	Failover automatico. La nuova replica primaria è L/S. Potrebbe verificarsi la perdita di dati.	Failover automatico. La nuova replica primaria non è disponibile per le transazioni di aggiornamento utente.
Interruzione di una replica secondaria	La replica primaria è L/S, con esecuzione esposta alla perdita di dati (se si verifica un errore sulla replica primaria e questa non può essere ripristinata). Nessun failover automatico se si verifica un errore anche sulla replica primaria.	La replica primaria non è disponibile per le transazioni di aggiornamento utente. Nessuna replica in cui eseguire il failover se si verifica un errore anche sulla replica primaria.
Interruzione della replica di sola configurazione	La replica primaria è L/S. Nessun failover automatico se si verifica un errore anche sulla replica primaria.	La replica primaria è L/S. Nessun failover automatico se si verifica un errore anche sulla replica primaria.
Interruzione di replica secondaria sincrona + replica di sola configurazione	La replica primaria non è disponibile per le transazioni di aggiornamento utente. Nessun failover automatico.	La replica primaria non è disponibile per le transazioni di aggiornamento utente. Nessuna replica in cui eseguire il failover se si verifica un errore anche sulla replica primaria.

¹ Impostazione predefinita

Nota

L'istanza di SQL Server che ospita la replica di sola configurazione può ospitare anche altri database. Può anche partecipare come database di sola configurazione per più gruppi di disponibilità.

Requisiti

• In tutte le repliche presenti in un gruppo di disponibilità con una replica di sola configurazione deve essere installato SQL Server 2017 CU 1 o versione successiva.
• Una replica di sola configurazione può essere ospitata in qualsiasi edizione di SQL Server, inclusa l'edizione SQL Server Express.
• Il gruppo di disponibilità richiede almeno una replica secondaria, oltre a quella primaria.
• Le repliche di sola configurazione non vengono incluse nel conteggio del numero massimo di repliche per ogni istanza di SQL Server. In SQL Server Standard Edition sono consentite al massimo tre repliche, mentre in SQL Server Enterprise Edition ne consentite al massimo nove.

Considerazioni

• Non sono consentite più repliche di sola configurazione per un singolo gruppo di disponibilità.
• Una replica di sola configurazione non può essere una replica primaria.
• Non è possibile modificare la modalità di disponibilità di una replica di sola configurazione. Per passare da una replica di sola configurazione a una replica secondaria sincrona o asincrona, rimuovere la replica di sola configurazione e aggiungere una replica secondaria con la modalità di disponibilità richiesta.
• Una replica di sola configurazione è sincrona con i metadati del gruppo di disponibilità. Non sono presenti dati utente.
• Un gruppo di disponibilità con una replica primaria e una replica di sola configurazione, ma nessuna replica secondaria, non è valido.
• Non è possibile creare un gruppo di disponibilità in un'istanza dell'edizione SQL Server Express.

Informazioni sull'agente delle risorse SQL Server per Pacemaker

SQL Server 2017 (14.x) ha introdotto sequence_number a sys.availability_groups per mostrare se una replica contrassegnata come SYNCHRONOUS_COMMIT fosse aggiornata. sequence_number è un valore BIGINT a incremento progressivo costante che rappresenta il livello di aggiornamento della replica del gruppo di disponibilità locale in relazione al resto delle repliche del gruppo di disponibilità. L'esecuzione di failover, l'aggiunta o la rimozione di repliche e altre operazioni relative ai gruppi di disponibilità comporta l'aggiornamento di questo numero. Il numero viene aggiornato nella replica primaria e quindi inviato alle repliche secondarie. Una replica secondaria aggiornata ha lo stesso sequence_number della replica primaria.

Quando Pacemaker decide di alzare di livello una replica e impostarla come primaria, invia prima di tutto una notifica a tutte le repliche per estrarre il numero di sequenza e archiviarlo (questa operazione viene chiamata notifica precedente all'innalzamento di livello). Successivamente, quando Pacemaker cerca effettivamente di alzare di livello una replica impostandola come primaria, l'operazione viene eseguita solo se il numero di sequenza della replica è il più alto di tutti i numeri di sequenza di tutte le repliche. In caso contrario, la replica rifiuta l'operazione. In questo modo, solo la replica con il numero di sequenza più alto può essere alzata di livello e impostata come primaria e non si verifica alcuna perdita dei dati.

La promozione funziona solo se almeno una replica disponibile per l'innalzamento di livello ha lo stesso numero di sequenza della replica primaria precedente. Il comportamento predefinito prevede che l'agente delle risorse Pacemaker imposti automaticamente REQUIRED_COPIES_TO_COMMIT in modo che almeno una replica secondaria di commit sincrona sia aggiornata e disponibile a essere la destinazione di un failover automatico. Con ogni azione di monitoraggio, il valore di REQUIRED_COPIES_TO_COMMIT viene calcolato (e aggiornato se necessario) come ('numero di repliche di commit sincrone' / 2). Quindi, in fase di failover, l'agente di risorsa richiede (repliche total number of replicas - required_copies_to_commit) di rispondere alla notifica pre-innalzamento per poter alzare una di queste al livello primario. La replica con il valore di sequence_number più elevato verrà alzata di livello come replica primaria.

Ad esempio, si consideri il caso di un gruppo di disponibilità con tre repliche sincrone: una replica primaria e due repliche secondarie con commit sincrono.

• REQUIRED_COPIES_TO_COMMIT è pari a 3 / 2 = 1

• Il numero di repliche richiesto per rispondere all'azione di pre-innalzamento è 3 - 1 = 2. Pertanto, perché il failover sia attivato, due repliche devono essere innalzate. Nel caso di interruzione primaria, se una delle repliche secondarie non risponde e solo una delle repliche secondarie risponde all'azione di pre-promozione, l'agente della risorsa non può garantire che la replica secondaria che ha risposto abbia il sequence_number più elevato, e non viene attivato un failover.

Un utente può scegliere di sostituire il comportamento predefinito e configurare la risorsa del gruppo di disponibilità per non impostare REQUIRED_COPIES_TO_COMMIT automaticamente, come indicato in precedenza.

Importante

Quando REQUIRED_COPIES_TO_COMMIT è 0 esiste il rischio di perdita dei dati. In caso di interruzione della replica primaria, l'agente della risorsa non attiverà automaticamente un failover. L'utente deve decidere se vuole attendere il recupero della replica primaria o eseguire il failover manualmente.

Per impostare REQUIRED_COPIES_TO_COMMIT su 0, eseguire:

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

Il comando equivalente se si usa crm (in SLES) è:

sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0

Per ripristinare il valore calcolato predefinito, eseguire:

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Nota

L'aggiornamento delle proprietà della risorsa produce l'arresto e il riavvio di tutte le repliche. Ciò significa che la replica primaria verrà temporaneamente abbassata al livello secondario, quindi promossa nuovamente, con una conseguente indisponibilità di scrittura temporanea. Il nuovo valore per REQUIRED_COPIES_TO_COMMIT verrà impostato solo dopo il riavvio delle repliche, pertanto non sarà istantaneo all'esecuzione del comando pcs.

Bilanciamento della disponibilità elevata e della protezione dei dati

Il comportamento predefinito precedente si applica anche in caso di due repliche sincrone (primaria + secondaria). Pacemaker imposta REQUIRED_COPIES_TO_COMMIT = 1 come valore predefinito per garantire che la replica secondaria sia sempre aggiornata per la massima protezione dei dati.

Avviso

Ciò comporta un maggiore rischio di indisponibilità della replica primaria a causa di interruzioni pianificate o meno della replica secondaria. L'utente può scegliere di modificare il comportamento predefinito dell'agente della risorsa ed eseguire l'override di REQUIRED_COPIES_TO_COMMIT su 0:

sudo pcs resource update <ag1> required_copies_to_commit=0

Dopo che è stato sottoposto a override, l'agente della risorsa usa la nuova impostazione per REQUIRED_COPIES_TO_COMMIT e arrestare il calcolo. Gli utenti devono aggiornarlo manualmente di conseguenza (ad esempio, se aumentano il numero di repliche).

Nelle tabelle seguenti vengono descritti i risultati di un'interruzione del servizio per le repliche primarie o secondarie in diverse configurazioni di risorse del gruppo di disponibilità:

Gruppo di disponibilità - due repliche sincrone

Configurazione	Interruzione primaria	Interruzione di una replica secondaria
REQUIRED_COPIES_TO_COMMIT = 0	L'utente deve eseguire un FAILOVER manuale. Potrebbe verificarsi la perdita di dati. La nuova replica primaria è L/S	La replica primaria è L/S, con esecuzione esposta alla perdita di dati.
REQUIRED_COPIES_TO_COMMIT = 11	Problemi automatici del cluster FAILOVER Nessuna perdita di dati. La nuova replica primaria rifiuta tutte le connessioni fino a quando verrà recuperata la replica primaria precedente e sarà unita al gruppo di disponibilità come replica secondaria.	La replica primaria rifiuta tutte le connessioni fino al recupero della replica secondaria.

¹ Comportamento predefinito dell'agente delle risorse SQL Server per Pacemaker.

Gruppo di disponibilità - tre repliche sincrone

Configurazione	Interruzione primaria	Interruzione di una replica secondaria
REQUIRED_COPIES_TO_COMMIT = 0	L'utente deve eseguire un FAILOVER manuale. Potrebbe verificarsi la perdita di dati. La nuova replica primaria è L/S	La replica primaria è L/S
REQUIRED_COPIES_TO_COMMIT = 11	Il cluster genera FAILOVER automaticamente . Nessuna perdita di dati. La nuova replica primaria è L/S	La replica primaria è L/S

¹ Comportamento predefinito dell'agente delle risorse SQL Server per Pacemaker.

Contenuto correlato

• Gruppi di disponibilità in Linux