Aggiornare le repliche del gruppo di disponibilità

Si applica a:SQL Server

Quando si aggiorna un'istanza di SQL Server che ospita un gruppo di disponibilità Always On a una nuova versione di SQL Server, a un nuovo Service Pack o aggiornamento cumulativo di SQL Server oppure quando la si installa in un nuovo Service Pack o aggiornamento cumulativo di Windows, è possibile ridurre i tempi di inattività per la replica primaria a un singolo failover manuale eseguendo un aggiornamento in sequenza (o a due failover manuali in caso di failback sulla replica primaria originale).

Durante il processo di aggiornamento, una replica secondaria non sarà disponibile per il failover o per le operazioni di sola lettura e, dopo l'aggiornamento, potrebbe essere necessario del tempo per consentire alla replica secondaria di recuperare il nodo della replica primaria a seconda del volume di attività nel nodo di replica primaria (quindi si prevede un traffico di rete elevato).

Occorre sapere anche che, dopo il failover iniziale a una replica secondaria che esegue una versione più recente di SQL Server, i database in quell'AG verranno sottoposti a un processo di aggiornamento per portarli alla versione più recente. Durante questa operazione le repliche non saranno leggibili per nessuno di questi database. Il tempo di inattività dopo il failover iniziale dipende dal numero di database nel AG (gruppo di disponibilità). Se si intende effettuare il failback al primario originale, questo passaggio non sarà ripetuto durante il failback.

Prerequisiti

Prima di iniziare, esaminare le informazioni seguenti:

• Aggiornamenti di versione ed edizione supportati: verificare che sia possibile eseguire l'aggiornamento all’ultima versione di SQL Server 2016 dalla versione in uso del sistema operativo Windows e di SQL Server. Ad esempio, se si esegue l'aggiornamento direttamente da un'istanza di SQL Server 2005, viene aggiornato il livello di compatibilità del database.

• Scegliere un metodo di aggiornamento del motore di database: per il corretto ordine di aggiornamento, selezionare il metodo e la procedura di aggiornamento appropriati in base alla verifica degli aggiornamenti di versione ed edizione supportati e anche agli altri componenti installati nell'ambiente.

• Pianificare e testare il piano di aggiornamento del motore di database: esaminare le note sulla versione e i problemi di aggiornamento noti, l'elenco di controllo di preupgradazione e sviluppare e testare il piano di aggiornamento.

• Requisiti hardware e software per l'installazione di SQL Server: esaminare i requisiti software per l'installazione di SQL Server. Se è necessario software aggiuntivo, installarlo in ogni nodo prima di iniziare il processo di aggiornamento per ridurre al minimo eventuali tempi di inattività.

• Verificare se Change Data Capture o la replica vengono usati per i database del gruppo di disponibilità: se un database all'interno del gruppo di disponibilità è abilitato per Change Data Capture (CDC), seguire queste istruzioni.

Introduzione agli aggiornamenti progressivi per i gruppi di disponibilità

Per ridurre al minimo i tempi di inattività e la perdita di dati per i gruppi di disponibilità (AG), seguire le seguenti linee guida quando si eseguono gli aggiornamenti dei server:

• Prima di iniziare l'aggiornamento in sequenza:

  • Eseguire un failover manuale di prova su almeno una delle istanze di replica con commit sincrono.

  • Proteggi i tuoi dati eseguendo un backup completo del database in ogni database di disponibilità.

  • Eseguire DBCC CHECKDB in ogni database di disponibilità.

• Aggiornare sempre prima le istanze di replica secondaria remota, quindi quelle di replica secondaria locale e, infine, l'istanza di replica primaria.

• Non è possibile eseguire backup su un database in corso di aggiornamento. Prima di eseguire l'aggiornamento delle repliche secondarie, configurare la preferenza per i backup automatici in modo che vengano eseguiti solo sulla replica primaria. Durante un aggiornamento di versione, le repliche non sono né leggibili né disponibili per i backup. Durante un aggiornamento nonversione, è possibile configurare backup automatici da eseguire nelle repliche secondarie prima di aggiornare la replica primaria.

• Durante un aggiornamento di versione, non è possibile leggere repliche secondarie leggibili dopo il relativo aggiornamento e prima che venga eseguito il failover della replica primaria su una replica secondaria aggiornata o che venga aggiornata la replica primaria.

• Per evitare failover involontari nel gruppo di disponibilità durante il processo di aggiornamento, rimuovere il failover di disponibilità da tutte le repliche configurate per il commit sincrono prima di iniziare.

• Non aggiornare l'istanza di replica primaria prima di eseguire il failover del gruppo di disponibilità (AG) su un'istanza aggiornata con una replica secondaria. In caso contrario, le applicazioni client potrebbero subire tempi di inattività prolungati durante l'aggiornamento nell'istanza di replica primaria.

• Eseguire sempre il failover del gruppo di disponibilità su un'istanza di replica secondaria con commit sincrono. Se si esegue il failover su un'istanza di replica secondaria con commit asincrono, i database sono soggetti alla perdita di dati e lo spostamento dei dati viene automaticamente sospeso fino a quando non viene ripreso manualmente.

• Non aggiornare l'istanza di replica primaria prima di aver aggiornato tutte le altre istanze di replica secondaria. Non è più possibile recapitare log tramite una replica primaria aggiornata alle repliche secondarie la cui istanza di SQL Server non è ancora stata aggiornata alla stessa versione. Se viene sospeso lo spostamento dei dati in una replica secondaria, il failover automatico per quest'ultima non può essere eseguito e nei database di disponibilità possono verificarsi perdite di dati. Questo vale anche durante un aggiornamento in sequenza in cui si esegue manualmente il failover da un database primario precedente a un nuovo database primario. Di conseguenza, dopo aver aggiornato il database primario precedente, potrebbe essere necessario riprendere la sincronizzazione.

• Prima di eseguire il failover di un gruppo di disponibilità, verificare che lo stato di sincronizzazione della destinazione di failover sia SYNCHRONIZED.

  Avviso

  L'installazione di una nuova istanza o di una nuova versione di SQL Server in un server con una versione precedente di SQL Server installata potrebbe causare inavvertitamente un'interruzione per qualsiasi gruppo di disponibilità ospitato dalla versione precedente di SQL Server. Ciò è dovuto al fatto che durante l'installazione dell'istanza o della versione di SQL Server, viene aggiornato il modulo a disponibilità elevata di SQL Server (RHS.EXE). Ciò comporta un'interruzione temporanea dei gruppi di disponibilità esistenti nel ruolo primario del server. Pertanto, è consigliabile eseguire una delle operazioni seguenti quando si installa una versione più recente di SQL Server in un sistema che ospita già una versione precedente di SQL Server con un gruppo di disponibilità:

  • Installare la nuova versione di SQL Server durante una finestra di manutenzione.

  • Eseguire il failover del gruppo di disponibilità sulla replica secondaria in modo che non sia primario durante l'installazione della nuova istanza di SQL Server.

Processo di aggiornamento in sequenza

Il processo effettivo dipende da fattori quali la topologia di distribuzione dei Availability Group (AG) e la modalità di commit della replica. Nello scenario più semplice, tuttavia, un aggiornamento in sequenza è un processo a più fasi che nel suo formato più semplice prevede i passaggi seguenti:

1. Rimuovere il failover automatico da tutte le repliche sincrone
2. Aggiornare tutte le istanze di replica secondaria con commit asincrono.
3. Aggiornare tutte le istanze di replica secondaria con commit sincrono remoti.
4. Aggiornare tutte le istanze di replica secondaria con commit sincrono locali.
5. Eseguire manualmente il failover del gruppo di disponibilità (AG) verso una replica secondaria locale a commit sincrono appena aggiornata.
6. Aggiornare l'istanza di replica locale in cui era ospitata, in precedenza, la replica primaria.
7. Configurare i partner di failover automatico in base alle proprie preferenze.

Se necessario, puoi eseguire un ulteriore failover manuale per riportare l'AG alla sua configurazione originale.

L'aggiornamento di una replica con commit sincrono e la modalità offline non ritarderà le transazioni nel database primario. Dopo che la replica secondaria è stata disconnessa, le transazioni vengono convalidate sulla replica primaria senza aspettare che i log vengano consolidati sulla replica secondaria. Se REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT è impostato su 1 o 2, la replica primaria potrebbe non essere disponibile per le operazioni di lettura/scrittura quando un numero corrispondente di repliche secondarie di sincronizzazione non sono disponibili durante il processo di aggiornamento.

Quando si esegue un aggiornamento sul posto di una replica secondaria a una versione più recente di SQL Server, il database all'interno del gruppo di disponibilità rimane nello stato Synchronizing/In recovery o Synchronized/In Recovery fino a quando non viene eseguito manualmente il failover del gruppo di disponibilità, che termina il ripristino e aggiorna il database. Una replica primaria aggiornata non può più spedire i log a qualsiasi replica secondaria di versione precedente e lo spostamento dei dati si arresta, non può verificarsi alcun failover automatico per tale replica e i database di disponibilità sono vulnerabili alla perdita di dati. Dopo aver aggiornato il database primario precedente, potrebbe essere necessario riprendere la sincronizzazione. Si consiglia di aggiornare tutte le repliche secondarie prima di eseguire il failover a una replica con la nuova versione. In questo modo, è possibile eseguire un failover dopo l'aggiornamento del database al nuovo formato.

Gruppo di disponibilità con una replica secondaria remota

Se è stato distribuito un gruppo di disponibilità solo per il ripristino di emergenza, potrebbe essere necessario eseguire il failover del gruppo di disponibilità in una replica secondaria con commit asincrono. La figura seguente illustra una configurazione di questo tipo:

In questo caso è necessario eseguire il failover del gruppo di disponibilità su una replica secondaria con commit asincrono durante l'aggiornamento in sequenza. Per evitare la perdita di dati, cambiare la modalità di commit in sincrona e attendere che la replica secondaria venga sincronizzata prima di eseguire il failover dell'AG. Di conseguenza, il processo di aggiornamento in sequenza potrebbe essere simile al seguente:

1. Aggiornare l'istanza di replica secondaria nel sito remoto.
2. Modificare la modalità commit in commit sincrono.
3. Attendere che lo stato di sincronizzazione sia SYNCHRONIZED.
4. Eseguire il failover dell'AG sulla replica secondaria nel sito remoto.
5. Migliorare o aggiornare l'istanza di replica locale (sito primario).
6. Effettuare il failover del gruppo di disponibilità sul sito primario.
7. Modificare la modalità commit in commit asincrono.

Poiché la modalità commit sincrono non è un'impostazione consigliata per la sincronizzazione dei dati in un sito remoto, le applicazioni client potrebbero notare un aumento immediato della latenza del database dopo la modifica dell'impostazione. L'esecuzione di un failover causa inoltre la rimozione di tutti i messaggi di log non riconosciuti. Il numero di messaggi di log scartati può essere significativo a causa dell'elevata latenza di rete tra i due siti, causando ai client di sperimentare un alto volume di fallimenti delle transazioni. È possibile ridurre l’effetto sulle applicazioni client con le azioni seguenti:

• Selezionare attentamente una finestra di manutenzione durante il traffico client basso.

• Durante l'aggiornamento o l'aggiornamento di SQL Server nel sito primario, tornare alla modalità di disponibilità in commit asincrono, quindi ripristinare il commit sincrono quando si è pronti a eseguire di nuovo il failover nel sito primario.

Gruppo di disponibilità con nodi di istanze del cluster di failover

Se in un gruppo di disponibilità sono contenuti nodi di istanze del cluster di failover (FCI), è consigliabile aggiornare i nodi inattivi prima di quelli attivi. Nella figura seguente è illustrato uno scenario comune di gruppi di disponibilità con istanze del cluster di failover per la disponibilità elevata locale e il commit asincrono tra le istanze stesse ai fini del ripristino di emergenza remoto ed è indicata la relativa sequenza di aggiornamento.

1. Esegui un upgrade o un aggiornamento REMOTE2
2. Esegui il failover di FCI2 a REMOTE2
3. Esegui un upgrade o un aggiornamento REMOTE1
4. Esegui un upgrade o un aggiornamento PRIMARY2
5. Esegui il failover di FCI1 su PRIMARY2
6. Esegui un upgrade o un aggiornamento PRIMARY1

Aggiornare o aggiornare le istanze di SQL Server con più AG (gruppi di disponibilità)

Se si eseguono più gruppi di disponibilità con repliche primarie in nodi server separati (una configurazione attiva/attiva), il percorso di aggiornamento prevede più passaggi di failover per mantenere la disponibilità elevata nel processo. Si supponga di eseguire tre gruppi di disponibilità in tre nodi del server con tutte le repliche in modalità commit sincrono, come illustrato nella tabella seguente:

Potrebbe essere opportuno eseguire un aggiornamento in sequenza con bilanciamento del carico nella sequenza seguente:

1. Effettuare il failover di AG2 a Node3 (per liberare Node2)
2. Esegui un upgrade o un aggiornamento Node2
3. Effettuare il failover di AG1 a Node2 (per liberare Node1)
4. Esegui un upgrade o un aggiornamento Node1
5. Eseguire il failover di AG2 e AG3 su Node1 (per liberare Node3)
6. Esegui un upgrade o un aggiornamento Node3
7. Eseguire il failover di AG3 in Node3

Questa sequenza di aggiornamento implica un tempo di inattività medio inferiore a due failover per gruppo di disponibilità. La configurazione risultante è illustrata nella tabella seguente.

In base all'implementazione specifica, il percorso di aggiornamento può variare e il tempo di inattività che le applicazioni client potrebbero variare.

Aggiornamento in sequenza di un gruppo di disponibilità distribuito

Per eseguire un aggiornamento in sequenza di un gruppo di disponibilità distribuito, aggiornare prima tutte le repliche secondarie. Eseguire quindi il failover del server d'inoltro e aggiornare l'ultima istanza rimanente del secondo gruppo di disponibilità. Dopo l'aggiornamento di tutte le altre repliche, eseguire il failover del database primario globale e aggiornare l'ultima istanza rimanente del primo gruppo di disponibilità. Un diagramma dettagliato con i passaggi viene fornito in una sezione successiva.

In base all'implementazione specifica, il percorso di aggiornamento può variare e il tempo di inattività che le applicazioni client potrebbero variare.

Procedura generica per l'aggiornamento di un gruppo di disponibilità distribuito

1. Eseguire il backup di tutti i database, inclusi i database di sistema e quelli che partecipano al gruppo di disponibilità.
2. Eseguire l'aggiornamento e riavviare tutte le repliche secondarie del secondo gruppo di disponibilità (downstream).
3. Eseguire l'aggiornamento e riavviare tutte le repliche secondarie del primo gruppo di disponibilità (upstream).
4. Eseguire il failover del trasmettitore primario a una replica secondaria aggiornata del gruppo di disponibilità secondario.
5. Attendere la sincronizzazione dei dati. I database devono risultare sincronizzati in tutte le repliche con commit sincrono e l'istanza primaria globale deve essere sincronizzata con l'istanza di inoltro.
6. Eseguire l'aggiornamento e riavviare l'ultima istanza rimanente del gruppo di disponibilità secondario.
7. Esegui il failover dell'istanza primaria globale a un'istanza secondaria aggiornata del primo gruppo di disponibilità.
8. Aggiornare l'ultima istanza ancora rimasta del gruppo di disponibilità primario.
9. Riavviare il server appena aggiornato.
10. (Facoltativo) Eseguire il failback di entrambi i gruppi di disponibilità alle repliche primarie originali.

Diagramma di esempio per l'aggiornamento in sequenza di un gruppo di disponibilità distribuito

Procedura per aggiornare le istanze in questo diagramma:

1. Eseguire il backup di tutti i database, inclusi i database di sistema e quelli che fanno parte del gruppo di disponibilità.
2. Aggiornare NODE4\SQLAG (replica secondaria di AG2) e riavviare il server.
3. Aggiornare NODE2\SQLAG (replica secondaria di AG1) e riavviare il server.
4. Eseguire il failover di AG2 da NODE3\SQLAG a NODE4\SQLAG.
5. Aggiornare NODE3\SQLAG e riavviare il server.
6. Eseguire il failover di AG1 da NODE1\SQLAG a NODE2\SQLAG.
7. Aggiornare NODE1\SQLAG e riavviare il server.
8. (Facoltativo) Eseguire il failback alle repliche primarie originali.
   1. Eseguire il failover di AG2 da NODE4\SQLAG a NODE3\SQLAG.
   2. Eseguire il failover di AG1 da NODE2\SQLAG a NODE1\SQLAG.

Se in ogni gruppo di disponibilità esiste una terza replica, è necessario aggiornarla prima NODE3\SQLAG e NODE1\SQLAG.

Passaggi speciali per la cattura delle modifiche dei dati o replica

A seconda dell'aggiornamento applicato, potrebbero essere necessari passaggi aggiuntivi per i database di replica del gruppo di disponibilità abilitati per Change Data Capture o la replica. Fare riferimento alle note sulla versione relative all'aggiornamento per stabilire se i passaggi seguenti sono necessari:

1. Aggiornare ogni replica secondaria.

2. Una volta completato l'aggiornamento di tutte le repliche secondarie, eseguire il failover del gruppo di disponibilità su un'istanza aggiornata.

3. Eseguire l'istruzione Transact-SQL seguente sull'istanza che ospita la replica primaria:

   EXECUTE [master].[sys].[sp_vupgrade_replication];
   

   Nota

   L'esecuzione di questo comando potrebbe richiedere alcuni minuti. Ignorare questo passaggio se si usa SQL Server 2019 CU1 o versione successiva. Per altre informazioni, vedere KB4530283.

4. Aggiornare l'istanza che era originariamente la replica primaria.

Per informazioni di base, vedere La funzionalità CDC potrebbe interrompersi dopo l'aggiornamento alla versione più recente del cu.

Contenuti correlati

• Aggiornare SQL Server usando l'Installazione guidata (programma di installazione)
• Installare e configurare SQL Server su Windows dal prompt dei comandi