Aggiornare i database replicati o applicare patch

Si applica a:SQL Server - solo Windows

SQL Server supporta l'aggiornamento di database replicati da versioni precedenti di SQL Server; non è necessario arrestare l'attività in altri nodi durante l'aggiornamento di un nodo.

Prerequisiti

Verificare che vengano osservate le regole relative alle versioni supportate in una topologia:

• Un server di distribuzione può essere qualsiasi versione purché sia maggiore o uguale alla versione del server di pubblicazione( in molti casi il server di distribuzione è la stessa istanza del server di pubblicazione).

• La versione del server di pubblicazione è indifferente, purché inferiore o uguale alla versione del server di distribuzione.

• La versione del Sottoscrittore dipende dal tipo di pubblicazione:

  • La versione di un Sottoscrittore per una pubblicazione transazionale può essere una versione qualsiasi all'interno di un intervallo di due versioni, in base alla versione del server di pubblicazione. Ad esempio: un server di pubblicazione SQL Server 2012 (11.x) può avere sottoscrittori SQL Server 2014 (12.x) e SQL Server 2016 (13.x). Un server di pubblicazione SQL Server 2016 (13.x) può avere sottoscrittori SQL Server 2014 (12.x) e SQL Server 2012 (11.x).

  • Un Sottoscrittore di una pubblicazione di tipo unione può essere di tutte le versioni uguali o inferiori alla versione del Publisher, a condizione che sia supportato in base al ciclo di supporto delle versioni.

Percorsi di aggiornamento

Il percorso di aggiornamento a SQL Server cambia a seconda del modello di distribuzione. SQL Server offre due percorsi di aggiornamento generali:

• Affiancato: distribuisce un ambiente parallelo e sposta nel nuovo ambiente i database insieme agli oggetti associati a livello di istanza, ad esempio gli account di accesso, i processi e così via.

• Aggiornamento sul posto: consente al supporto di installazione di SQL Server di aggiornare l'installazione di SQL Server esistente sostituendo i bit di SQL Server e aggiornando gli oggetti di database. Per gli ambienti che eseguono gruppi di disponibilità o istanze del cluster di failover, un aggiornamento in loco viene combinato con un aggiornamento graduale per ridurre al minimo i tempi di inattività.

Un approccio comune per gli aggiornamenti affiancati delle topologie di replica consiste nello spostare le coppie publisher-subscriber parzialmente nel nuovo ambiente affiancato, anziché spostare l'intera topologia. Questo approccio in più fasi consente di controllare i tempi di inattività e di ridurre al minimo l'impatto in una certa misura per l'azienda dipendente dalla replica.

La maggior parte di questo articolo ha come ambito l'aggiornamento della versione di SQL Server. Il processo di aggiornamento sul posto, tuttavia, deve essere usato anche per l'applicazione di patch a SQL Server con un Service Pack o un aggiornamento cumulativo.

Osservazioni

L'aggiornamento di una topologia di replica è un processo che si compone di più passaggi. È consigliabile provare ad aggiornare una replica della topologia di replica in un ambiente di test prima di eseguire l'aggiornamento nell'ambiente di produzione reale. Ciò consente di risolvere qualsiasi documentazione operativa necessaria per gestire l'aggiornamento senza incorrere in tempi di inattività costosi e lunghi durante il processo di aggiornamento effettivo. È possibile ridurre in modo significativo il tempo di inattività con l'uso di Availability Groups (AGs) e/o Failover Cluster Instances (FCIs) per i propri ambienti di produzione, mentre si aggiorna la topologia di replica. È inoltre consigliabile eseguire backup di tutti i database, tra cui msdb, master, i database di distribuzione e i database utente che partecipano alla replica prima di tentare l'aggiornamento.

Quando si dispone di un database di distribuzione in un'istanza del cluster di failover, assicurarsi che tutti i nodi partecipanti usino la stessa compilazione. Non è consigliabile configurare in cui un nodo è una versione di SQL Server precedente a SQL Server 2016 (13.x) SP2-CU3 o SQL Server 2017 (14.x) CU6 e l'altro nodo è una versione di SQL Server successiva a SQL Server 2016 (13.x) SP2-CU3 o SQL Server 2017 (14.x) CU6. A partire da SQL Server 2016 (13.x) SP2-CU3 e SQL Server 2017 (14.x) CU6, è stato aggiunto il supporto per utilizzare un database di distribuzione all'interno di un gruppo di disponibilità e per i nuovi oggetti (tabelle, stored procedure) nei database di distribuzione. Se il database di distribuzione si trova in un'istanza del cluster di failover e si esegue una migrazione in più fasi (e non è possibile aggiornare tutti i nodi alla stessa versione di SQL Server), per l'intervallo di tempo di migrazione ristretto è consigliabile eseguire attività di account, quali aggiunta di un nuovo sottoscrittore, sottoscrizione, server di pubblicazione o pubblicazione nel nodo con la versione successiva di SQL Server.

Matrice di replica

Matrice di compatibilità della replica transazionale e snapshot

Autore	Database di distribuzione	Sottoscrittore
Istanza gestita di SQL di AzureAUTD	Istanza gestita di SQL di Azure AUTD	Azure SQL Database Istanza gestita di SQL di AzureAUTD Istanza gestita di SQL di Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x)
Istanza gestita di SQL di Azure2022	Istanza gestita di SQL di AzureAUTD Istanza gestita di SQL di Azure2022	Azure SQL Database Istanza gestita di SQL di AzureAUTD Istanza gestita di SQL di Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x)
SQL Server 2022 (16.x)	SQL Server 2022 (16.x)	Azure SQL Database Istanza gestita di SQL di AzureAUTD Istanza gestita di SQL di Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x)
SQL Server 2019 (15.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x)	Azure SQL Database Istanza gestita di SQL di AzureAUTD Istanza gestita di SQL di Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x)
SQL Server 2017 (14.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x)	Istanza gestita di SQL di Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x)
SQL Server 2016 (13.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x)	SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x)
SQL Server 2014 (12.x)	Istanza SQL gestita di Azure AUTD Istanza gestita di SQL di Azure2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x)	SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2012 (11.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x)	SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)	SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)

²⁰²² Si applica a Istanza gestita di SQL di Azure configurata con i criteri di aggiornamento di SQL Server 2022 . AUTD si applica all'istanza gestita di SQL di Azure configurata con i criteri di aggiornamentoup-to-date.

Matrice di compatibilità della replica di tipo merge

Autore	Database di distribuzione	Sottoscrittore
SQL Server 2022 (16.x)	SQL Server 2022 (16.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2019 (15.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x)	SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2017 (14.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x)	SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2016 (13.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x)	SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2014 (12.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x)	SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2012 (11.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x)	SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)
SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)	SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)	SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x)

Considerazioni sull'aggiornamento

Eseguire l'agente di lettura log per la replica transazionale prima dell'aggiornamento

Prima di aggiornare SQL Server, è necessario assicurarsi che tutte le transazioni di cui è stato eseguito il commit dalle tabelle pubblicate siano state elaborate dall'agente di lettura log. Per assicurarsi che tutte le transazioni vengano elaborate, seguire questa procedura per ogni database che contiene pubblicazioni transazionali:

1. Verificare che l'agente di lettura log sia in esecuzione per il database. Per impostazione predefinita, l'agente viene eseguito in modo continuativo.

2. Arrestare l'attività dell'utente nelle tabelle pubblicate.

3. Concedere tempo all'agente di lettura log per copiare transazioni nel database di distribuzione, quindi arrestare l'agente.

4. Eseguire sp_replcmds per verificare che tutte le transazioni siano state elaborate. Il set di risultati restituito da questa procedura deve essere vuoto.

5. Eseguire sp_replflush per chiudere la connessione da sp_replcmds

6. Eseguire l'aggiornamento del server alla versione più recente di SQL Server.

7. Riavviare SQL Server Agent e l'agente di lettura log se non vengono avviati automaticamente dopo l'aggiornamento.

Eseguire agenti per la replica di merge dopo l'aggiornamento

Al termine dell'aggiornamento, eseguire l'agente snapshot per ogni pubblicazione di tipo merge e l'agente di merge per ogni sottoscrizione in modo da aggiornare i metadati della replica. Non è necessario applicare il nuovo snapshot, perché non è necessario reinizializzare le sottoscrizioni. I metadati delle sottoscrizioni vengono aggiornati alla prima esecuzione dell'agente di merge successiva all'aggiornamento. Ciò significa che il database di sottoscrizione può rimanere online e attivo durante l'aggiornamento del server di pubblicazione.

La replica di tipo merge archivia i metadati di pubblicazione e sottoscrizione in diverse tabelle di sistema nei database di pubblicazione e sottoscrizione. L'esecuzione dell'agente snapshot aggiorna i metadati delle pubblicazioni e l'esecuzione dell'agente di merge aggiorna i metadati delle sottoscrizioni. È necessario solo generare un'istantanea della pubblicazione. Se una pubblicazione di tipo merge utilizza filtri con parametri, ogni partizione includerà uno snapshot. Non è necessario aggiornare questi snapshot partizionati.

Eseguire gli agenti da SQL Server Management Studio, da Monitoraggio replica o dalla riga di comando. Per altre informazioni sull'esecuzione dell'agente di snapshot, vedere gli articoli seguenti:

• Creazione e applicazione dello snapshot iniziale
• Avviare e arrestare un agente di replica (SQL Server Management Studio)
• Creazione e applicazione dello snapshot iniziale
• Replication Agent Executables Concepts

Per altre informazioni sull'esecuzione dell'agente di merge, vedere gli articoli seguenti:

• Sincronizzare una sottoscrizione pull
• Sincronizzare una sottoscrizione push

Al termine dell'aggiornamento di SQL Server in una topologia in cui viene usata una replica di tipo merge, modificare il livello di compatibilità di tutte le pubblicazioni se si desidera usare le nuove funzionalità.

Eseguire l'aggiornamento alle edizioni Standard, Workgroup o Express

Prima di eseguire l'aggiornamento da un'edizione di SQL Server a un'altra, verificare che la funzionalità attualmente in uso sia supportata nell'edizione a cui si sta eseguendo l'aggiornamento. Per altre informazioni, vedere la sezione sulla replica in Edizioni e funzionalità supportate di SQL Server 2022.

Procedura di aggiornamento della topologia di replica

Questi passaggi illustrano l'ordine in cui i server di una topologia di replica devono essere aggiornati. La stessa procedura si applica alle repliche transazionali e di tipo merge. Tuttavia, questi passaggi non riguardano la replica peer-to-peer, le sottoscrizioni ad aggiornamento in coda, né le sottoscrizioni ad aggiornamento immediato.

Aggiornamento sul posto

1. Aggiornare il database di distribuzione.
2. Aggiornare il server di pubblicazione e il sottoscrittore. Questi componenti possono essere aggiornati in qualsiasi ordine.

Nota

Per SQL Server 2008 (10.0.x) e SQL Server 2008 R2 (10.50.x), l'aggiornamento del server di pubblicazione e del sottoscrittore deve essere eseguito contemporaneamente per allinearsi alla matrice della topologia di replica. I server di pubblicazione o i sottoscrittori di SQL Server 2008 (10.0.x) e SQL Server 2008 R2 (10.50.x) non possono avere un server di pubblicazione o sottoscrittore di SQL Server 2016 (13.x) (o versione successiva). Se l'aggiornamento contemporaneamente non è possibile, usare un aggiornamento intermedio per aggiornare le istanze di SQL Server a SQL Server 2014 (12.x) e quindi aggiornarle nuovamente a SQL Server 2016 (13.x) (o versione successiva).

Aggiornamento affiancato

1. Aggiornare il database di distribuzione.
2. Riconfigurare Riconfigurare distribuzione nella nuova istanza di SQL Server.
3. Aggiornare il server di pubblicazione.
4. Aggiornare il sottoscrittore.
5. Riconfigurare tutte le coppie di server di pubblicazione/sottoscrittore, compresa la reinizializzazione del sottoscrittore.

Passaggi per la migrazione side-by-side del server di distribuzione a Windows Server

Un aggiornamento affiancato è l'unico percorso di aggiornamento disponibile per le istanze SQL Server che fanno parte di un cluster di failover. I passaggi seguenti possono essere eseguiti in un'istanza autonoma di SQL Server o in un'istanza del cluster di failover.

1. Configurare una nuova istanza di SQL Server (autonoma o FCI), con edizione e versione come server di distribuzione su Windows Server, utilizzando un cluster Windows diverso e un diverso nome per il cluster FCI di SQL Server o un diverso nome host autonomo. È necessario mantenere la struttura di directory uguale al server di distribuzione precedente per assicurarsi che gli agenti di replica eseguibili, cartelle di replica e percorsi di file di database si trovino nello stesso percorso del nuovo ambiente. In questo modo si riducono i passaggi successivi alla migrazione/aggiornamento necessari.

2. Verificare che la replica sia sincronizzata, quindi arrestare tutti gli agenti di replica.

3. Arrestare l'istanza del server di distribuzione di SQL Server corrente. Se si tratta di un'istanza autonoma, arrestare il server. Se si tratta di un'istanza del cluster di failover di SQL Server, portare offline l'intero ruolo di SQL Server nella gestione cluster, incluso il nome di rete.

4. Rimuovere le voci dell'oggetto computer DNS e Active Directory per l'ambiente precedente (istanza del server di distribuzione corrente).

5. Modificare il nome host del nuovo server in modo che corrisponda a quelle del vecchio server.

   1. Se si tratta di un'istanza di SQL Server FCI, rinominare la nuova istanza di SQL Server FCI con lo stesso nome del server virtuale della vecchia istanza.

6. Copiare i file di database dall'istanza precedente usando il reindirizzamento, la copia di archiviazione o la copia di file SAN.

7. Portare online la nuova istanza di SQL Server.

8. Riavviare tutti gli agenti di replica e verificare che vengano eseguiti correttamente.

9. Verificare che la replica funzioni come previsto.

10. Usare i supporti di installazione di SQL Server per eseguire un aggiornamento sul posto dell'istanza di SQL Server e portarla alla nuova versione di SQL Server.

Nota

Per ridurre i tempi di inattività, è consigliabile eseguire il migrazione side-by-side del server di distribuzione come un'attività e l'aggiornamento sul posto a SQL Server come un'altra attività. In questo modo è possibile adottare un approccio in più fasi, ridurre i rischi e ridurre al minimo i tempi di inattività.

Sincronizzazione Web per la replica di tipo merge

L'opzione di sincronizzazione Web per la replica di tipo merge richiede di copiare il listener di replica di SQL Server (replisapi.dll) nella directory virtuale nel server Internet Information Services (IIS) usato per la sincronizzazione. Quando si configura la sincronizzazione Web, la Procedura guidata Configurazione sincronizzazione Web copia il file nella directory virtuale. Se si aggiornano i componenti di SQL Server installati nel server IIS, è necessario copiare manualmente replisapi.dll dalla directory COM alla directory virtuale nel server IIS. Per altre informazioni sulla configurazione della sincronizzazione Web, vedere Configurazione della sincronizzazione Web.

Ripristinare un database replicato da una versione precedente

Per verificare che in seguito al ripristino del backup di un database replicato vengano mantenute le impostazioni di replica di una versione precedente, eseguire il ripristino in un server e un database con gli stessi nomi del server e del database utilizzati per la creazione della copia di backup.

Contenuto correlato

• Replica di SQL Server
• Domande frequenti sull'amministrazione della replica
• Compatibilità con le versioni precedenti per la replica
• aggiornamenti di versione ed edizione supportati (SQL Server 2022)
• Eseguire l'aggiornamento di SQL Server
• Upgrading a Replication Topology to SQL Server 2016 (Aggiornamento di una topologia di replica a SQL Server 2016)