Aggiornamento delle istanze di replica dei gruppi di disponibilità AlwaysOnUpgrading Always On Availability Group Replica Instances

QUESTO ARGOMENTO SI APPLICA A: SìSQL ServernonDatabase SQL di AzurenonAzure SQL Data Warehouse non Parallel Data WarehouseTHIS TOPIC APPLIES TO: yesSQL ServernoAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

Quando si aggiorna un'istanza di SQL ServerSQL Server che ospita un gruppo di disponibilità AlwaysOn a una nuova versione di SQL Server 2017SQL Server 2017, a un nuovo Service Pack o aggiornamento cumulativo di SQL ServerSQL Server oppure quando la si installa su 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).When upgrading a SQL ServerSQL Server instance that hosts an Always On Availability Group (AG) to a new SQL Server 2017SQL Server 2017 version, to a new SQL ServerSQL Server service pack or cumulative update, or when installing to a new Windows service pack or cumulative update, you can reduce downtime for the primary replica to only a single manual failover by performing a rolling upgrade (or two manual failovers if failing back to the original primary). Durante il processo di aggiornamento, non sarà disponibile una replica secondaria per il failover o le operazioni di sola lettura e, dopo l'aggiornamento, a seconda del volume di attività nel nodo della replica primaria, l'aggiornamento della replica secondaria al nodo della replica primaria potrebbe richiedere un po' di tempo (è dunque prevedibile un traffico di rete elevato).During the upgrade process, a secondary replica will not be available for failover or for read-only operations, and after the upgrade, it may take some time for the secondary replica to catch up with the primary replica node depending upon the volume of activity on the primary replica node (so expect high network traffic). Occorre sapere anche che dopo il failover iniziale in una replica secondaria che esegue una versione più recente di SQL Server, i database di tale gruppo di disponibilità saranno sottoposti a un processo di aggiornamento affinché la versione adottata sia la più recente.Also be aware that after the initial failover to a secondary replica running a newer version of SQL Server, the databases in that Availability Group will run through an upgrade process to bring them to the latest version. Durante questa operazione le repliche non saranno leggibili per nessuno di questi database.During this time there will be no readable replicas for any of these databases. Il tempo di inattività dopo il failover iniziale dipenderà dal numero di database contenuti nel gruppo di disponibilità.Downtime after the initial failover will depend on the number of databases in the Availability Group. Se si prevede di eseguire il failback sulla replica primaria originale, questo passaggio non sarà ripetuto durante il failback.If you plan on failing back to the original primary, this step will not be repeated when you fail back.

Nota

Questo articolo si limita a illustrare l'aggiornamento di SQL Server.This article limits the discussion to the upgrade of SQL Server itself. Non viene descritto l'aggiornamento del sistema operativo che contiene WSFC (Windows Server Failover Cluster).It does not cover upgrading the operating system containing the Windows Server Failover Cluster (WSFC). L'aggiornamento del sistema operativo Windows che ospita il cluster di failover non è supportato per i sistemi operativi precedenti a Windows Server 2012 R2.Upgrading the Windows operating system hosting the failover cluster is not supported for operating systems before Windows Server 2012 R2. Per aggiornare un nodo del cluster in esecuzione in Windows Server 2012 R2, vedere Aggiornamento in sequenza del sistema operativo del cluster.To upgrade a cluster node running on Windows Server 2012 R2, see Cluster Operating System Rolling Upgrade.

PrerequisitesPrerequisites

Prima di iniziare, esaminare le informazioni seguenti:Before you begin, review the following important information:

Nota

L'uso di più versioni delle istanze di SQL Server nello stesso gruppo di disponibilità è supportato solo nel contesto di un aggiornamento in sequenza che aggiorna le repliche nelle posizioni originali.Mixing versions of SQL Server instances in the same AG is not supported outside of a rolling upgrade, which upgrades the replicas in place. Una versione successiva di un'istanza di SQL Server non può essere aggiunta come nuova replica a un gruppo di disponibilità esistente.A higher version of a SQL Server instance cannot be added as a new replica to an existing AG. Ad esempio non è possibile aggiungere una replica SQL Server 2017 a un gruppo di disponibilità SQL Server 2016 esistente.For example, a SQL Server 2017 replica cannot be added to an existing SQL Server 2016 AG. Per eseguire la migrazione a una nuova versione dell'istanza di SQL Server che usa gruppi di disponibilità, l'unico metodo supportato è un gruppo di disponibilità distribuito in SQL Server 2016 Enterprise Edition o versioni successive.To migrate to a new version of the SQL Server instance using AGs, the only supported method is a distributed AG, which is in SQL Server 2016 Enterprise Edition or later.

Informazioni di base sull'aggiornamento in sequenza per i gruppi di disponibilità AlwaysOnRolling Upgrade Basics for Always On AGs

Per ridurre al minimo i tempi di inattività e la perdita di dati per i gruppi di disponibilità, osservare le linee guida seguenti quando si eseguono gli aggiornamenti dei server:Observe the following guidelines when performing server upgrades or updates in order to minimize downtime and data loss for your AGs:

  • Prima di avviare l'aggiornamento in sequenza:Before starting the rolling upgrade,

    • Eseguire un failover manuale di prova su almeno una delle istanze di replica con commit sincronoPerform a practice manual failover on at least one of your synchronous-commit replica instances

    • Proteggere i dati eseguendo un backup completo di ogni database di disponibilitàProtect your data by performing a full database backup on every availability database

    • Eseguire il comando DBCC CHECKDB su ogni database di disponibilitàRun DBCC CHECKDB on every availability database

  • Aggiornare sempre prima le istanze di replica secondaria remota, quindi quelle di replica secondaria locale e, infine, l'istanza di replica primaria.Always upgrade the remote secondary replica instances first, then local secondary replica instances next, and the primary replica instance last.

  • Non è possibile eseguire backup su un database in corso di aggiornamento.Backups cannot occur on a database that is in the process of being upgraded. Prima di eseguire l'aggiornamento delle repliche secondarie, configurare la preferenza per i backup automatici in modo che vengano eseguiti solo sulla replica primaria.Prior to upgrading the secondary replicas, configure the automated backup preference to run backups only on the primary replica. Durante un aggiornamento di versione, le repliche non sono né leggibili né disponibili per i backup.During a version upgrade, no replicas are readable or available for backups. Durante un aggiornamento non di versione, è possibile configurare l'esecuzione di backup automatici sulle repliche secondarie prima di aggiornare la replica primaria.During a non-version upgrade, you can configure automated backups to run on secondary replicas prior to upgrading the primary replica.

  • 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.During a version upgrade, readable secondaries cannot be read after an upgrade of the readable secondary and before either the primary replica is failed over to an upgraded secondary or the primary replica is upgraded.

  • Per evitare failover accidentali del gruppo di disponibilità durante il processo di aggiornamento, rimuovere il failover da tutte le repliche con commit sincrono prima di iniziare.To prevent the AG from unintended failovers during the upgrade process, remove availability failover from all synchronous-commit replicas before you begin.

  • Non aggiornare l'istanza di replica primaria prima di aver eseguito il failover del gruppo di disponibilità su un'istanza aggiornata con una replica secondaria.Do not upgrade the primary replica instance before failing over the AG to an upgraded instance with a secondary replica first. In caso contrario, le applicazioni client potrebbero subire tempi di inattività prolungati durante l'aggiornamento sull'istanza di replica primaria.Otherwise, client applications may suffer extended downtime during the upgrade on the primary replica instance.

  • Eseguire sempre il failover del gruppo di disponibilità su un'istanza di replica secondaria con commit sincrono.Always fail over the AG to a synchronous-commit secondary replica instance. Se si esegue il failover su un'istanza di replica secondaria con commit asincrono, i database saranno soggetti alla perdita di dati e lo spostamento dei dati viene automaticamente sospeso finché non viene ripreso manualmente.If you fail over to an asynchronous-commit secondary replica instance, the databases is vulnerable to data loss, and data movement is automatically suspended until you manually resume data movement.

  • Non aggiornare l'istanza di replica primaria prima di aver aggiornato tutte le altre istanze di replica secondaria.Do not upgrade the primary replica instance before upgrading or updating any other secondary replica instance. Non è più possibile recapitare log tramite una replica primaria aggiornata alle repliche secondarie la cui istanza di SQL Server 2017SQL Server 2017 non è ancora stata aggiornata alla stessa versione.An upgraded primary replica can no longer ship logs to any secondary replica whose SQL Server 2017SQL Server 2017 instance that has not yet been upgraded to the same version. 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.When data movement to a secondary replica is suspended, no automatic failover can occur for that replica, and your availability databases are vulnerable to data loss.

  • Prima di eseguire il failover di un gruppo di disponibilità, verificare che lo stato di sincronizzazione della destinazione di failover sia SINCRONIZZATO.Before failing over an AG, verify that the synchronization state of the failover target is SYNCHRONIZED.

Processo di aggiornamento in sequenzaRolling Upgrade Process

Il processo effettivo dipende da fattori quali la topologia di distribuzione dei gruppi di disponibilità e la modalità di commit di ogni replica.In practice, the exact process depends on factors such as the deployment topology of your AGs and the commit mode of each replica. Nello scenario più semplice, l'aggiornamento in sequenza è articolato in un processo a più fasi che nella sua forma essenziale prevede i passaggi seguenti:But in the simplest scenario, a rolling upgrade is a multi-stage process that in its simplest form involves the following steps:

Aggiornamento del gruppo di disponibilità in uno scenario HADRAG Upgrade in HADR Scenario

  1. Rimuovere il failover automatico in tutte le repliche con commit sincronoRemove automatic failover on all synchronous-commit replicas

  2. Aggiornare tutte le istanze di replica secondaria remota in cui vengono eseguite repliche secondarie con commit asincronoUpgrade all remote secondary replica instances running asynchronous-commit secondary replicas

  3. Aggiornare tutte le istanze di replica secondaria locale in cui non è attualmente in esecuzione la replica primariaUpgrade the all local replica secondary instances that are not currently running the primary replica

  4. Eseguire manualmente il failover del gruppo di disponibilità su una replica secondaria locale con commit sincronoManually fail over the AG to a local synchronous-commit secondary replica

  5. Aggiornare l'istanza di replica locale in cui, in precedenza, era ospitata la replica primariaUpgrade or update the local replica instance that formerly hosted the primary replica

  6. Configurare i partner di failover automatico nel modo desideratoConfigure automatic failover partners as desired

    Se necessario, è possibile eseguire un ulteriore failover manuale per ripristinare la configurazione originale del gruppo di disponibilità.If necessary, you can perform an extra manual failover to return the AG to its original configuration.

Gruppo di disponibilità con una replica secondaria remotaAG with One Remote Secondary Replica

Se è stato distribuito un gruppo di disponibilità solo a fini di ripristino di emergenza potrebbe essere necessario eseguirne il failover su una replica secondaria con commit asincrono.If you have deployed an AG only for disaster recovery, you may need to fail over the AG to an asynchronous-commit secondary replica. Questo tipo di configurazione è illustrato nella figura seguente:Such configuration is illustrated by the following figure:

Aggiornamento del gruppo di disponibilità in uno scenario DRAG Upgrade in DR Scenario

In questo caso è necessario eseguire il failover del gruppo di disponibilità su una replica secondaria con commit asincrono durante l'aggiornamento in sequenza.In this situation, you must fail over the AG to the asynchronous-commit secondary replica during the rolling upgrade. Per evitare perdite di dati, modificare la modalità di commit impostando il commit sincrono e attendere che venga completata la sincronizzazione della replica secondaria prima di eseguire il failover del gruppo di disponibilità.To prevent data loss, change the commit mode to synchronous commit and wait for the secondary replica to be synchronized before you fail over the AG. Il processo di aggiornamento in sequenza può quindi avvenire come segue:Therefore, the rolling upgrade process may look as follows:

  1. Aggiornare l'istanza di replica secondaria sul sito remotoUpgrade the secondary replica instance on the remote site

  2. Impostare la modalità di commit sincronoChange the commit mode to synchronous commit

  3. Attendere che lo stato di sincronizzazione sia SINCRONIZZATOWait until synchronization state is SYNCHRONIZED

  4. Eseguire il failover del gruppo di disponibilità sulla replica secondaria nel sito remotoFail over the AG to the secondary replica on the remote site

  5. Aggiornare l'istanza di replica (sito primario) localeUpgrade or update the local (primary site) replica instance

  6. Eseguire di nuovo il failover del gruppo di disponibilità sul sito primarioFail over the AG back to the primary site

  7. Impostare la modalità di commit asincronoChange the commit mode to asynchronous commit

    Poiché la modalità di commit sincrono non è consigliata per la sincronizzazione dei dati con un sito remoto, tramite le applicazioni client potrebbe essere rilevato un aumento immediato della latenza del database in seguito alla modifica dell'impostazione.Since the synchronous-commit mode is not a recommended setting for data synchronization to a remote site, client applications may notice an immediate increase in database latency after the setting change. L'esecuzione di un failover causa inoltre la rimozione di tutti i messaggi di log non riconosciuti.Moreover, performing a failover causes all unacknowledged log messages to be discarded. Il numero di messaggi di log rimossi può essere notevole a causa dell'elevata latenza di rete tra i due siti determinando un numero elevato di errori delle transazioni nei client.The number discarded log messages can be significant due to the high network latency between the two sites, causing clients to experience a high volume of transactional failure. È possibile ridurre l'impatto sulle applicazioni client con le azioni seguenti:You can minimize impact to client applications by doing the following actions:

  • Scegliere con attenzione una finestra di manutenzione nei periodi di minore traffico clientCarefully select a maintenance window during low client traffic

  • Durante l'aggiornamento di SQL Server 2017SQL Server 2017 nel sito primario, impostare di nuovo la modalità di commit asincrono, quindi ripristinare il commit sincrono una volta pronti a effettuare nuovamente il failover sul sito primarioWhile upgrading or updating SQL Server 2017SQL Server 2017 on the primary site, change the availability mode back to asynchronous commit, then revert to synchronous commit when you are ready to fail over to the primary site again

Gruppo di disponibilità con nodi di istanze del cluster di failoverAG with Failover Cluster Instance Nodes

Se in un gruppo di disponibilità sono contenuti nodi di istanze del cluster di failover, è consigliabile aggiornare i nodi inattivi prima di quelli attivi.If an AG contains failover cluster instance (FCI) nodes, you should upgrade the inactive nodes before you upgrade the active nodes. 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.The following figure illustrates a common AG scenario with FCIs for local high availability and asynchronous commit between the FCIs for remote disaster recovery, and the upgrade sequence.

Aggiornamento del gruppo di disponibilità con istanze del cluster di failoverAG Upgrade with FCIs

  1. Aggiornare REMOTE2Upgrade or update REMOTE2

  2. Effettuare il failover dell'istanza FCI2 a REMOTE2Fail over FCI2 to REMOTE2

  3. Aggiornare REMOTE1Upgrade or update REMOTE1

  4. Aggiornare PRIMARY2Upgrade or update PRIMARY2

  5. Effettuare il failover dell'istanza FCI1 a PRIMARY2Fail over FCI1 to PRIMARY2

  6. Aggiornare PRIMARY1Upgrade or update PRIMARY1

Aggiornare le istanze di SQL Server con più gruppi di disponibilitàUpgrade Update SQL Server Instances with Multiple AGs

Se si eseguono più gruppi di disponibilità con repliche primarie su nodi server distinti (configurazione Attiva/Attiva), il percorso di aggiornamento prevede altri passaggi di failover per preservare la disponibilità elevata durante il processo.If you are running multiple AGs with primary replicas on separate server nodes (an Active/Active configuration), the upgrade path involves more failover steps to preserve high availability in the process. Si supponga di avere tre gruppi di disponibilità in tre nodi server con tutte le repliche in modalità commit sincrono come illustrato nella tabella seguente:Suppose you are running three AGs on three server nodes with all replicas in synchronous commit mode as shown in the following table:

Gruppo di disponibilitàAG Nodo1Node1 Nodo2Node2 Nodo3Node3
AG1AG1 PrimariaPrimary
AG2AG2 PrimariaPrimary
AG3AG3 PrimariaPrimary

In determinate situazioni potrebbe essere opportuno eseguire un aggiornamento in sequenza con bilanciamento del carico articolato come segue:It may be appropriate in your situation to perform a load-balanced rolling upgrade in the following sequence:

  1. Effettuare il failover di AG2 a Nodo3 (per liberare Nodo2)Fail over AG2 to Node3 (to free up Node2)

  2. Aggiornare Nodo2Upgrade or update Node2

  3. Effettuare il failover di AG1 a Nodo2 (per liberare Nodo1)Fail over AG1 to Node2 (to free up Node1)

  4. Aggiornare Nodo1Upgrade or update Node1

  5. Effettuare il failover di AG2 e AG3 a Nodo1 (per liberare Nodo3)Fail over both AG2 and AG3 to Node1 (to free up Node3)

  6. Aggiornare Nodo3Upgrade or update Node3

  7. Effettuare il failover di AG3 a Nodo3Fail over AG3 to Node3

    Questa sequenza di aggiornamento implica un tempo di inattività medio inferiore alla durata di due failover per gruppo di disponibilità.This upgrade sequence has an average downtime of fewer than two failovers per AG. La configurazione risultante è illustrata nella tabella seguente.The resulting configuration is shown in the following table.

Gruppo di disponibilitàAG Nodo1Node1 Nodo2Node2 Nodo3Node3
AG1AG1 PrimariaPrimary
AG2AG2 PrimariaPrimary
AG3AG3 PrimariaPrimary

Il percorso di aggiornamento e i tempi di inattività per le applicazioni client possono variare a seconda della specifica implementazione in uso.Based on your specific implementation, your upgrade path may vary, and the downtime that client applications experience may vary as well.

Nota

In molti casi, dopo aver completato l'aggiornamento in sequenza, sarà possibile eseguire il failback sulla replica primaria originale.In many cases, after the rolling upgrade is completed, you will fail back to the original primary replica.

Passaggi speciali per Change Data Capture o la replicaSpecial steps for change data capture or replication

A seconda dell'aggiornamento che si sta applicando, possono essere necessari passaggi aggiuntivi per i database di replica del gruppo di disponibilità abilitati per Change Data Capture o la replica.Depending on the update being applied, additional steps may be required for AG replica databases that are enabled for change data capture or replication. Fare riferimento alle note sulla versione relative all'aggiornamento per stabilire se i passaggi seguenti sono necessari:Refer to the release notes for the update to determine if the following steps are required:

  1. Aggiornare ogni replica secondaria.Upgrade each secondary replica.

  2. Al termine dell'aggiornamento di tutte le repliche secondarie, eseguire il failover del gruppo di disponibilità su un'istanza aggiornata.After all secondary replicas have been upgraded, fail over the AG to an upgraded instance.

  3. Eseguire l'istruzione Transact-SQL seguente sull'istanza che ospita la replica primaria:Run the following Transact-SQL on the instance that hosts the primary replica:

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

    Nota

    L'esecuzione di questo comando potrebbe richiedere alcuni minuti.This command may take several minutes to run.

  4. Aggiornare l'istanza che era in origine la replica primaria.Upgrade the instance that was originally the primary replica.

Per informazioni di carattere generale, vedere l'articolo sulla possibilità che la funzionalità CDC non funzioni dopo che è stato applicato l'aggiornamento cumulativo più recente.For background information, see CDC functionality may break after upgrading to the latest CU.

Vedere ancheSee Also

Eseguire l'aggiornamento a SQL Server 2016 usando l'Installazione guidata (programma di installazione)Upgrade to SQL Server 2016 Using the Installation Wizard (Setup)

Installazione di SQL Server 2016 dal prompt dei comandiInstall SQL Server 2016 from the Command Prompt