Aggiornamento delle istanze con mirroring

Si applica a:SQL Server

Attenzione

Questa funzionalità verrà rimossa in una versione futura di SQL Server. Evitare di usare questa funzionalità in un nuovo progetto di sviluppo e prevedere interventi di modifica nelle applicazioni in cui è attualmente implementata. Per la disponibilità elevata, usare invece gruppi di disponibilità AlwaysOn.

Importante

Il mirroring del database in SQL Server è una tecnologia distinta rispetto al mirroring del database di Microsoft Fabric. Il mirroring su Fabric offre prestazioni analitiche migliori, la possibilità di unificare il patrimonio di dati con OneLake in Fabric e di aprire l'accesso ai dati in formato Delta Parquet.

Con il mirroring in Microsoft Fabric, è possibile replicare continuamente il patrimonio di dati esistente direttamente in OneLake in Fabric, inclusi i dati di SQL Server 2016+, database SQL di Azure, Istanza gestita di SQL di Azure, Cosmos DB, Oracle, Snowflake e altro ancora.

Quando si aggiorna un'istanza con mirroring di SQL Server a una nuova versione, a un nuovo Service Pack o aggiornamento cumulativo di SQL Server oppure a un nuovo Service Pack o aggiornamento cumulativo di Windows, è possibile ridurre i tempi di inattività per ogni database con mirroring a un singolo failover manuale eseguendo un aggiornamento in sequenza o due failover manuali in caso di failback all'istanza primaria originale. L'aggiornamento in sequenza è un processo in più fasi che, nella forma più semplice, implica l'aggiornamento dell'istanza di SQL Server che in quel momento funge da server mirror in una sessione di mirroring, seguito dal failover manuale del database con mirroring, dall'aggiornamento della prima istanza principale di SQL Server e dalla ripresa del mirroring. Nella pratica, il processo esatto dipende dalla modalità operativa e dal numero/layout della sessione di mirroring in esecuzione nelle istanze SQL Server da aggiornare.

Per informazioni sull'utilizzo del mirroring del database con il log shipping durante una migrazione, scaricare il white paper Database Mirroring and Log Shipping.

Prerequisiti

Prima di iniziare, esaminare le informazioni seguenti:

Prima di avviare un aggiornamento in sequenza, si consiglia di effettuare le operazioni seguenti:

  1. Eseguite un failover manuale di prova su almeno una delle sessioni di mirroring:

    Nota

    Per informazioni sul funzionamento del failover manuale, vedere Cambio di ruolo durante una sessione di mirroring del database (SQL Server).

  2. Proteggi i tuoi dati:

    1. Eseguire un backup completo di ogni database principale:

      Creare un backup completo del database (SQL Server).

    2. Eseguire il comando DBCC CHECKDB in ogni database principale.

Fasi di un aggiornamento in sequenza

I passaggi specifici di un aggiornamento in sequenza dipendono dalla modalità operativa della configurazione del mirroring. Tuttavia, le fasi di base sono identiche.

Nota

Per altre informazioni sulle modalità di funzionamento, vedere Modalità di funzionamento del mirroring del database.

Nel diagramma di flusso della figura seguente vengono illustrate le fasi di base di un aggiornamento in sequenza per ogni modalità operativa. Le procedure corrispondenti vengono descritte dopo l'illustrazione.

Diagramma di flusso che illustra la procedura di un aggiornamento in sequenza

Importante

Un'istanza del server potrebbe svolgere diversi ruoli di mirroring (server principale, server di mirroring o server witness) in sessioni di mirroring concorrenti. In questo caso, è necessario adattare di conseguenza il processo di aggiornamento in sequenza di base. Per altre informazioni, vedere Cambio di ruolo durante una sessione di mirroring del database (SQL Server).

Nota

In molti casi, dopo aver completato l'aggiornamento in sequenza, sarà possibile eseguire il failback al server principale originale.

Per modificare la modalità di una sessione dalla modalità a elevate prestazioni alla modalità a protezione elevata

  1. Se una sessione di mirroring è in esecuzione in modalità a prestazioni elevate, prima di eseguire un aggiornamento progressivo, modificare la modalità operativa in protezione elevata senza failover automatico.

    Importante

    Se il server mirror è geograficamente distante dal server principale, un aggiornamento in sequenza potrebbe non essere appropriato.

Per rimuovere un witness da una sessione

  1. Se una sessione di mirroring prevede un server witness, si consiglia di rimuoverlo prima di eseguire un aggiornamento progressivo. In caso contrario, quando l'istanza del server mirror viene aggiornata, la disponibilità del database dipende dall'istanza del server di controllo che resta connessa all'istanza del server principale. Dopo avere rimosso un server di controllo del mirroring, è possibile aggiornarlo in qualsiasi momento durante il processo di aggiornamento in sequenza senza rischiare alcun tempo di inattività del database.

Per eseguire l'aggiornamento progressivo

  1. Per ridurre al minimo i tempi di inattività, si consiglia di applicare la seguente procedura: avviare l'aggiornamento in sequenza aggiornando qualsiasi server partner di mirroring che è attualmente il server mirror in tutte le sue sessioni di mirroring. In questa fase potrebbe essere necessario aggiornare più istanze del server.

    Nota

    Un witness può essere aggiornato in qualsiasi momento del processo di aggiornamento progressivo. Ad esempio, se un'istanza del server è un server mirror nella Sessione 1 e un server di controllo del mirroring nella Sessione 2, è possibile aggiornare ora l'istanza del server.

    L'istanza del server da aggiornare per prima dipende dalla configurazione corrente delle sessioni di mirroring, ovvero:

    • Se un'istanza server è già il server mirror in tutte le sue sessioni di mirroring, aggiornare l'istanza server alla nuova versione.

    • Se tutte le istanze del server sono attualmente il server principale in almeno una sessione di mirroring, selezionare un'istanza del server da aggiornare per prima. Quindi, effettuare manualmente il failover di ciascuno dei database principali e aggiornare quell'istanza del server.

    Dopo aver eseguito l'aggiornamento, un'istanza del server reintegra automaticamente ciascuna delle sue sessioni di mirroring.

  2. Attendere la sincronizzazione di ciascuna sessione di mirroring la cui istanza del server mirror è stata appena aggiornata. Quindi, connettersi all'istanza del server principale ed eseguire manualmente il failover della sessione. Con il failover, l'istanza del server aggiornata diventa il server principale per la sessione e il server principale precedente diventa il server mirror.

    L'obiettivo di questo passaggio è consentire a un'altra istanza del server di diventare il server mirror in tutte le sessione di mirroring in cui è un server partner.

    Restrizioni dopo l'esecuzione del failover in un'istanza server aggiornata.

    Dopo il failover da un'istanza del server precedente a un'istanza aggiornata del server SQL Server, la sessione del database viene sospesa. Non può essere ripristinata finché l'altro server partner non sarà stato aggiornato. Tuttavia, il server principale continua ad accettare connessioni e a consentire l'accesso ai dati e le modifiche sul database principale.

    Nota

    L'avvio di una nuova sessione di mirroring richiede che tutte le istanze server eseguano la stessa versione di SQL Server.

  3. Dopo aver eseguito il failover, è consigliabile eseguire il comando DBCC CHECKDB sul database principale.

  4. Aggiornate ciascuna istanza del server che ora è il server mirror in tutte le sessioni di mirroring in cui funge da partner. In questa fase potrebbe essere necessario aggiornare più server.

    Importante

    In una configurazione di mirroring complessa, alcune istanze del server potrebbero essere ancora il server principale originale in una o più sessioni di mirroring. Ripetere i passaggi da 2 a 4 per tali istanze del server finché tutte le istanze coinvolte non sono state aggiornate.

  5. Riprendi la sessione di mirroring.

    Nota

    Il failover automatico non funzionerà finché il witness non sarà stato aggiornato e aggiunto nuovamente alla sessione di mirroring.

  6. Aggiornare eventuali istanze server rimanenti che fungono da witness in tutte le relative sessioni di mirroring. Dopo che un server di controllo del mirroring aggiornato rientra in una sessione di mirroring, il failover automatico torna a essere possibile. In questa fase potrebbe essere necessario aggiornare più server.

Per ripristinare una sessione alla modalità a elevate prestazioni

  1. Facoltativamente, tornare alla modalità a elevate prestazioni utilizzando uno dei metodi seguenti:

    • In SQL Server Management Studio: modificare l'opzione Modalità operativa e impostarla su Prestazioni elevate (asincrona) usando la pagina Mirroring della finestra di dialogo Proprietà database.

    • In Transact-SQL: usare ALTER DATABASE per impostare la sicurezza delle transazioni su OFF.

Per aggiungere di nuovo un server di controllo in una sessione di mirroring

  1. Facoltativamente, nella modalità con protezione elevata, ripristinare il server di controllo per ogni sessione di mirroring.

    Per restituire un witness

Vedi anche

Eseguire l'aggiornamento a SQL Server 2016 usando l'Installazione guidata (programma di installazione)
Installare SQL Server 2016 dal prompt dei comandi
ALTER DATABASE Mirroring di database (Transact-SQL)
BACKUP (Transact-SQL)
Visualizzare lo stato di un database con mirroring (SQL Server Management Studio)
Mirroring del database (SQL Server)
Cambio di ruolo durante una sessione di mirroring del database (SQL Server)
Forzare il servizio in una sessione di mirroring del database (Transact-SQL)
Avvia Monitoraggio del mirroring del database (SQL Server Management Studio)
Modalità operative del mirroring del database