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

QUESTO ARGOMENTO SI APPLICA A:sìSQL Server (a partire dalla versione 2016)noDatabase SQL di AzurenoAzure SQL Data WarehousenoParallel Data WarehouseTHIS TOPIC APPLIES TO: yesSQL Server (starting with 2016)noAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

Quando si aggiorna un gruppo di disponibilità AlwaysOn di SQL ServerSQL Server a una nuova versione di SQL Server 2017SQL Server 2017 , a un nuovo Service Pack o aggiornamento cumulativo di SQL ServerSQL Serveroppure quando 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 alla replica primaria originale).When upgrading a SQL ServerSQL Server Always On Availability Group to a new SQL Server 2017SQL Server 2017 version, to a new SQL ServerSQL Serverservice 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 per le operazioni di sola lettura e, dopo l'aggiornamento, la replica secondaria potrebbe richiedere del tempo per l'aggiornamento al nodo della replica primaria in base al volume di attività nel nodo (è 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).

Nota

In questo argomento viene illustrata esclusivamente la modalità di aggiornamento di SQL Server.This topic limits the discussion to the upgrade of SQL Server itself. Non viene descritto l'aggiornamento del sistema operativo che contiene il cluster Windows Server Failover Clustering (WSFC).It does not cover upgrading the operating system containing the Windows Server Failover Clusting (WSFC) cluster. 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 su Windows Server 2012 R2, vedere Aggiornamento in sequenza del sistema operativo del clusterTo upgrade a cluster node running on Windows Server 2012 R2, see Cluster Operating System Rolling Upgrade

PrerequisitiPrerequisites

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

  • Supported Version and Edition Upgrades: verificare che sia possibile eseguire l'aggiornamento a SQL Server 2016 dalla versione del sistema operativo Windows e di SQL Server.Supported Version and Edition Upgrades: Verify that you can upgrade to SQL Server 2016 from your version of the Windows operating system and version of SQL Server. Ad esempio, non è possibile eseguire l'aggiornamento diretto da un'istanza di SQL Server 2005 a SQL Server 2017SQL Server 2017.For example, you cannot upgrade directly from a SQL Server 2005 instance to SQL Server 2017SQL Server 2017.

  • Choose a Database Engine Upgrade Method: selezionare il metodo e la procedura di aggiornamento appropriati in base alla verifica degli aggiornamenti della versione e dell'edizione supportate e anche agli altri componenti installati nell'ambiente interessato per aggiornare i componenti nell'ordine corretto.Choose a Database Engine Upgrade Method: Select the appropriate upgrade method and steps based on your review of supported version and edition upgrades and also based on other components installed in your environment to upgrade components in the correct order.

  • Pianificare e testare il piano di aggiornamento del motore di database: esaminare le note sulla versione, i problemi di aggiornamento noti e l'elenco di controllo pre-aggiornamento e sviluppare e testare il piano di aggiornamento.Plan and Test the Database Engine Upgrade Plan: Review the release notes and known upgrade issues, the pre-upgrade checklist, and develop and test the upgrade plan.

  • Hardware and Software Requirements for Installing SQL Server 2016: esaminare i requisiti software per l'installazione di SQL Server 2017SQL Server 2017.Hardware and Software Requirements for Installing SQL Server 2016: Review the software requirements for installing SQL Server 2017SQL Server 2017. Se è necessario software aggiuntivo, installarlo in ogni nodo prima di iniziare il processo di aggiornamento per ridurre al minimo eventuali tempi di inattività.If additional software is required, install it on each node before you begin the upgrade process to minimize any downtime.

Procedure consigliate relative all'aggiornamento in sequenza per i gruppi di disponibilità AlwaysOnRolling Upgrade Best Practices for Always On Availability Groups

Quando si eseguono aggiornamenti dei server, è opportuno attenersi alle procedure consigliate illustrate di seguito allo scopo di ridurre al minimo i tempi di inattività e la perdita di dati per i gruppi di disponibilità:The following best practices should be observed when performing server upgrades or updates in order to minimize downtime and data loss for your availability groups:

  • 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 will be 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, prima di iniziare rimuovere il failover da tutte le repliche con commit sincrono.To prevent the availability group 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 availability group 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 availability group to a synchronous-commit secondary replica instance. Se si esegue il failover su un'istanza di replica secondaria con commit asincrono, si verificheranno perdite di dati nei database e lo spostamento dei dati verrà automaticamente sospeso finché non verrà ripreso manualmente.If you fail over to an asynchronous-commit secondary replica instance, the databases will suffer 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 effettuare il failover di un gruppo di disponibilità, verificare che lo stato di sincronizzazione della destinazione di failover risulti essere SINCRONIZZATO.Before failing over an availability group, 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 will depend on factors such as the deployment topology of your availability groups 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à nello scenario di ripristino di emergenza a disponibilità elevataAvailability Group 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 availability group 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 availability group to its original configuration.

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

Se è stato distribuito un gruppo di disponibilità solo a fini di ripristino di emergenza, potrebbe essere necessario effettuarne il failover a una replica secondaria con commit asincrono.If you have deployed an availability group only for disaster recovery, you may need to fail over the availability group 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à nello scenario di ripristino di emergenzaAvailability Group 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 availability group 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 effettuare 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 availability group. 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à su una replica secondaria sul sito remotoFail over the availability group 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 availability group 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. Inoltre, l'esecuzione di un failover causerà la rimozione di tutti i messaggi di log non riconosciuti.Moreover, performing a failover will cause all unacknowledged log messages to be discarded. La quantità di messaggi di log rimossi può essere notevole a causa dell'elevata latenza di rete tra i due siti, il che determina un numero elevato di errori delle transazioni con i client.The amount of discarded log messages can be quite large due to the high network latency between the two sites, causing clients to experience a high volume of transactional failure. È possibile ridurre l'impatto per le applicazioni client nel modo seguente:You can minimize impact to client applications by doing the following:

  • 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 failoverAvailability Group 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 availability group 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 figure below illustrates a common availability group 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 failoverAvailability Group 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 Availability Groups

Se si eseguono più gruppi di disponibilità con repliche primarie su nodi server distinti (configurazione Attiva/Attiva), il percorso di aggiornamento prevede più passaggi di failover allo scopo di preservare la disponibilità elevata durante il processo.If you are running multiple availability groups 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 disporre di tre gruppi di disponibilità in tre nodi server come illustrato nella tabella seguente e che tutte le repliche secondarie vengano eseguite in modalità di commit sincrono.Suppose you are running three availability groups on three server nodes as shown in the following table, and all secondary replicas are running in synchronous-commit mode.

Gruppo di disponibilitàAvailability Group 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 ciascun gruppo di disponibilità.This upgrade sequence has an average downtime of less than two failovers per availability group. La configurazione risultante è illustrata nella tabella seguente.The resulting configuration is shown in the table below.

Gruppo di disponibilitàAvailability Group 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 alla replica primaria originale.In many cases, after the rolling upgrade is completed, you will failback to the original primary replica.

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