Panoramica di Log Replay Service con Istanza gestita di SQL di Azure

  • Articolo

Si applica a: Istanza gestita di SQL di Azure SQL

Questo articolo offre una panoramica del servizio Registrazione archiviazione con ridondanza locale che è possibile usare per eseguire la migrazione di database da SQL Server a Istanza gestita di SQL di Azure. Log Replay Service (LRS) è un servizio cloud gratuito abilitato per l'Istanza gestita di SQL di Azure basato sulla tecnologia di log shipping di SQL Server.

Poiché l'archiviazione con ridondanza locale ripristina i file di backup standard di SQL Server, è possibile usarlo per eseguire la migrazione da SQL Server ospitato ovunque (in locale o su qualsiasi cloud) a Istanza gestita di SQL di Azure.

Per avviare la migrazione con archiviazione con ridondanza locale, vedere Eseguire la migrazione dei database usando il servizio di riproduzione log.

Importante

Prima di eseguire la migrazione dei database al livello di servizio Business Critical , prendere in considerazione queste limitazioni, che non si applicano al livello di servizio Per utilizzo generico.

Quando usare Log Replay Service

Servizio Migrazione del database di Azure, l'estensione di migrazione SQL di Azure per Azure Data Studio e l'archiviazione con ridondanza locale usano la stessa tecnologia di migrazione e le stesse API sottostanti. Log Replay Service consente inoltre migrazioni personalizzate complesse e architetture ibride tra distribuzioni locali dell'istanza di SQL Server locale e l'Istanza gestita di SQL.

Quando non è possibile usare il Servizio Migrazione del database di Azure o l’estenzione Azure SQL per la migrazione, è possibile usare LRS direttamente con PowerShell, i cmdlet dell'interfaccia della riga di comando di Azure o le API per compilare e orchestrare manualmente le migrazioni di database all'Istanza gestita di SQL.

Prendere in considerazione l'uso di LRS nei casi seguenti, quando:

  • È necessario un maggiore controllo per il progetto di migrazione del database.
  • Non c'è tolleranza per i tempi di inattività durante il cutover della migrazione.
  • Il file eseguibile Servizio Migrazione del database non può essere installato nell'ambiente.
  • Il file eseguibile Servizio Migrazione del database non ha accesso ai backup del database.
  • L'estensione di migrazione Azure SQL non può essere installata nell'ambiente o non può accedere ai backup del database.
  • Non è disponibile alcun accesso al sistema operativo host o non sono previsti privilegi di amministratore.
  • Non è possibile aprire le porte di rete dall'ambiente ad Azure.
  • I problemi di limitazione della rete o di blocco del proxy sono presenti nell'ambiente in uso.
  • I backup vengono archiviati direttamente negli account Archiviazione BLOB di Azure tramite l'opzione TO URL.
  • È necessario usare i backup differenziali.

Poiché l'archiviazione con ridondanza locale funziona ripristinando i file di backup standard di SQL Server, deve supportare le migrazioni da qualsiasi origine. Sono state testate le seguenti origini:

  • SQL Server in locale/box
  • SQL Server in macchine virtuali
  • Amazon EC2 (Elastic Compute Cloud)
  • Amazon RDS (Relational Database Service) per SQL Server
  • Google Compute Engine
  • Cloud SQL per SQL Server - GCP (Google Cloud Platform)
  • Servizi Desktop remoto Alibaba Cloud per SQL Server

Se si verificano problemi imprevisti durante la migrazione da un'origine non elencata, aprire un ticket di supporto per richiedere assistenza.

Nota

  • È consigliabile automatizzare la migrazione dei database da SQL Server a Istanza gestita di SQL di Azure usando l'estensione di migrazione Azure SQL per Azure Data Studio. Prendere in considerazione l'uso di LRS per orchestrare le migrazioni quando l'estensione di migrazione Azure SQL non supporta completamente gli scenari.
  • LRS è l'unico metodo per ripristinare i backup differenziali nelle istanze gestite. Non è possibile ripristinare manualmente i backup differenziali nell'istanza gestita, né impostare manualmente la modalità NORECOVERY usando T-SQL.

Funzionamento di LRS

La creazione di una soluzione personalizzata per la migrazione dei database nel cloud con archiviazione con ridondanza locale richiede diversi passaggi di orchestrazione, come illustrato nel diagramma e nella tabella più avanti in questa sezione.

La migrazione consiste nell'esecuzione di backup di database in SQL Server e nella copia dei file di backup in Archiviazione BLOB di Azure. Sono supportati backup completi, di log e differenziali. Quando si utilizza il servizio cloud LRS per ripristinare i file di backup dall’account di Archiviazione BLOB di Azure all'Istanza gestita di SQL. L'archiviazione BLOB funge da archivio intermedio per i file di backup tra SQL Server e l'Istanza gestita di SQL.

LRS monitora l'account di archiviazione BLOB per rilevare eventuali nuovi backup differenziali o di log aggiunti dopo il ripristino del backup completo. LRS ripristina quindi automaticamente questi nuovi file. È possibile usare il servizio per monitorare l'avanzamento del ripristino dei file di backup nell'Istanza gestita di SQL e, se necessario, interrompere il processo.

LRS non richiede una convenzione di denominazione specifica per i file di backup. Analizza tutti i file presenti nell'account Archiviazione BLOB di Azure e costruisce la catena di backup leggendo solo le intestazioni dei file. I database si trovano in uno stato di ripristino durante il processo di migrazione. I database vengono ripristinati in modalità NORECOVERY, quindi non possono essere usati per carichi di lavoro di lettura o scrittura fino al completamento del processo di migrazione.

Se si esegue la migrazione di diversi database, è necessario:

  • Inserire i file di backup per ogni database in una cartella separata nell’account di archiviazione BLOB in una struttura di file flat. Ad esempio, usare cartelle di database separate: blobcontainer/database1/files, blobcontainer/database2/files e così via.
  • Non usare cartelle annidate all'interno di cartelle di database perché questa struttura non è supportata. Ad esempio, non usare sottocartelle come blobcontainer/database1/subfolder/files.
  • Avviare LRS separatamente per ogni database.
  • Specificare percorsi URI diversi per cartelle di database separate nell’account di archiviazione BLOB di Azure.

L'abilitazione di CHECKSUM per i backup non è necessaria, ma è comunque consigliabile. Il ripristino dei database senza CHECKSUM richiede più tempo, perché Istanza gestita di SQL esegue un controllo di integrità sui backup ripristinati senza abilitare CHECKSUM.

Per ulteriori informazioni, vedere Eseguire la migrazione di database da SQL Server all'Istanza gestita di SQL di Azure con Log Replay Service.

Attenzione

L'esecuzione di backup in SQL Server con CHECKSUM abilitato è altamente consigliata perché esiste un rischio per ripristinare un database danneggiato in Azure senza di esso.

Completamento automatico e migrazione in modalità continua

È possibile avviare LRS in modalità di completamento automatico o continua.

Usare la modalità di completamento automatico quando si dispone dell'intera catena di backup generata in anticipo e quando non si prevede di aggiungere altri file dopo l'avvio della migrazione. Questa modalità di migrazione è consigliata per i carichi di lavoro passivi che non richiedono il recupero dei dati. Caricare tutti i file di backup nell'account Archiviazione BLOB e avviare la migrazione in modalità completamento automatico. La migrazione verrà completata automaticamente quando è stato ripristinato l'ultimo file di backup specificato. Il database migrato diventerà disponibile per l'accesso in lettura/scrittura in Istanza gestita di SQL.

Se si prevede di continuare ad aggiungere nuovi file di backup mentre è in corso la migrazione, usare la modalità continua. Questa modalità è consigliabile per i carichi di lavoro attivi che richiedono il recupero dei dati. Caricare la catena di backup attualmente disponibile nell'account di archiviazione BLOB, avviare la migrazione in modalità continua e continuare ad aggiungere nuovi file di backup dal carico di lavoro in base alle esigenze. Il sistema analizzerà periodicamente la cartella Archiviazione BLOB di Azure e ripristinerà eventuali nuovi file di backup di log o differenziali trovati.

Quando si è pronti per il cutover, arrestare il carico di lavoro nell'istanza di SQL Server, generare l'ultimo file di backup e quindi caricarlo. Verificare che l'ultimo file di backup sia stato ripristinato verificando che il backup finale della parte finale del log venga visualizzato come ripristinato in Istanza gestita di SQL. Avviare quindi il cutover manuale. Il passaggio finale di cutover rende il database online e disponibile per l'accesso in lettura e scrittura nell'Istanza gestita di SQL.

Dopo l'arresto di LRS, o automaticamente tramite completamento automatico o manualmente tramite cutover, non è possibile riprendere il processo di ripristino per un database portato online in Istanza gestita di SQL. Ad esempio, al termine della migrazione, non è più possibile ripristinare più backup differenziali per un database online. Per ripristinare altri file di backup al termine della migrazione, è necessario eliminare il database dall'istanza gestita e riavviare la migrazione dall'inizio.

Flusso di lavoro della migrazione

Un flusso di lavoro di migrazione tipico è illustrato nell'immagine seguente e i passaggi sono descritti nella tabella.

Utilizzare la modalità di completamento automatico solo quando tutti i file della catena di backup sono disponibili in anticipo. Consigliamo questa modalità per i carichi di lavoro passivi per i quali non è necessario il recupero dei dati.

Utilizzare la modalità di migrazione continua quando non si dispone dell'intera catena di backup in anticipo e quando si prevede di aggiungere nuovi file di backup dopo che la migrazione è in corso. Questa modalità è consigliata per i carichi di lavoro attivi per i quali è necessario il recupero dei dati.

Diagramma che illustra i passaggi di orchestrazione del servizio di riproduzione log per un'Istanza gestita di SQL.

Operation Dettagli
1. Copiare i backup del database dall'istanza di SQL Server all'account di Archiviazione BLOB. Copiare backup completi, differenziali e di log dall'istanza di SQL Server al contenitore Archiviazione BLOB usando AzCopy o Azure Storage Explorer.

Usare qualsiasi nome di file. LRS non richiede una convenzione di denominazione specifica per i file.

Usare una cartella separata per ogni database durante la migrazione di diversi database.
2. Avviare LRS nel cloud. È possibile avviare il servizio con PowerShell (start-azsqlinstancedatabaselogreplay) o l'interfaccia della riga di comando di Azure (cmdlet az_sql_midb_log_replay_start). Scegliere tra il completamento automatico o la modalità di migrazione continua.

Avviare separatamente l'archiviazione con ridondanza locale per ogni database che punta a una cartella di backup nell'account Archiviazione BLOB.

Dopo l'avvio del servizio, esegue i backup dal contenitore BLOB Archiviazione e inizia a ripristinarli in Istanza gestita di SQL.

Quando viene avviato in modalità di completamento automatico, LRS ripristina tutti i backup fino all'ultimo file di backup specificato. Tutti i file di backup devono essere caricati in anticipo e non è possibile aggiungere nuovi file di backup mentre la migrazione è in corso. Questa modalità è consigliata per i carichi di lavoro passivi per i quali non è necessario il recupero dei dati.

Quando LRS viene avviato in modalità continua, ripristina tutti i backup caricati inizialmente e quindi controlla tutti i nuovi file caricati nella cartella. Il servizio applica continuamente i log in base alla catena LSN (Numero di sequenza del file di log) fino a quando non viene arrestato manualmente. Questa modalità è consigliata per i carichi di lavoro attivi per i quali è necessario il recupero dei dati.
2.1. Monitorare i progressi dell’operazione. È possibile monitorare lo stato dell'operazione di ripristino in corso con PowerShell (get-azsqlinstancedatabaselogreplay) o l'interfaccia della riga di comando di Azure (cmdlet az_sql_midb_log_replay_show). Per tenere traccia di altri dettagli su una richiesta non riuscita, usare il comando PowerShell Get-AzSqlInstanceOperation o usare il comando dell'interfaccia della riga di comando di Azure az sql mi op show.
2.2. Arrestare l'operazione se necessario (facoltativo). Se è necessario arrestare il processo di migrazione, usare PowerShell (stop-azsqlinstancedatabaselogreplay) o l'interfaccia della riga di comando di Azure (az_sql_midb_log_replay_stop).

L'arresto dell'operazione elimina il database che si sta ripristinando in Istanza gestita di SQL. Dopo aver arrestato un'operazione, non è possibile riprendere l'archiviazione con ridondanza locale per un database. È necessario riavviare il processo di migrazione dall'inizio.
3. Passare al cloud quando si è pronti. Se l'archiviazione con ridondanza locale è stata avviata in modalità di completamento automatico, la migrazione termina automaticamente dopo il ripristino dell'ultimo file di backup specificato.

Se LRS è stato avviato in modalità continua, arrestare l'applicazione e il carico di lavoro. Eseguire l'ultimo backup della parte finale del log e caricarlo nella distribuzione Archiviazione BLOB di Azure. Assicurarsi che l'ultimo backup della parte finale del log sia stato ripristinato nell'istanza gestita. Completare il cutover avviando un'operazione di complete archiviazione con ridondanza locale con PowerShell (complete-azsqlinstancedatabaselogreplay) o l'interfaccia della riga di comando di Azure az_sql_midb_log_replay_complete. Questa operazione arresta LRS e porta online il database per i carichi di lavoro di lettura/scrittura in Istanza gestita di SQL.

Ripristinare la stringa di connessione dell'applicazione dall'istanza di SQL Server a Istanza gestita di SQL. È necessario orchestrare manualmente questo passaggio, tramite una modifica manuale della stringa di connessione all’interno dell’applicazione oppure automaticamente (ad esempio se l'applicazione può leggere il stringa di connessione da una proprietà o da un database).

Importante

Dopo il cutover, Istanza gestita di SQL con il livello di servizio Business Critical può richiedere molto più tempo rispetto a Utilizzo generico perché è necessario eseguire il seeding di tre repliche secondarie per il gruppo di disponibilità. La durata dell'operazione dipende dalle dimensioni dei dati. Per altre informazioni, vedere Durata delle operazioni di gestione.

Migrazione di database di grandi dimensioni

Se si esegue la migrazione di database di grandi dimensioni di diversi terabyte, tenere presente quanto segue:

  • Un singolo processo LRS può essere eseguito per un massimo di 30 giorni. Alla scadenza di questo periodo, il processo viene annullato automaticamente.
  • Per i processi a esecuzione prolungata, gli aggiornamenti del sistema si interromperanno e prolungheranno i processi di migrazione. È consigliabile usare una finestra di manutenzione per pianificare gli aggiornamenti del sistema pianificati. Pianificare la migrazione in base alla finestra di manutenzione pianificata.
  • I processi di migrazione interrotti dagli aggiornamenti del sistema vengono sospesi e ripresi automaticamente per le istanze gestite per utilizzo generico e vengono riavviati per le istanze gestite di Business Critical . Questi aggiornamenti avranno effetto sull'intervallo di tempo della migrazione.
  • Per aumentare la velocità di caricamento dei file di backup di SQL Server nell'account di Archiviazione BLOB, se l'infrastruttura ha una larghezza di banda di rete sufficiente, è consigliabile usare la parallelizzazione con più thread.

Avviare la migrazione

Per avviare la migrazione, avviare l'archiviazione con ridondanza locale. È possibile avviare il servizio in modalità di completamento automatico o continua. Per informazioni specifiche, vedere Eseguire la migrazione con LRS.

  • Modalità di completamento automatico. Quando si usa la modalità di completamento automatico, la migrazione termina automaticamente quando l'ultimo dei file di backup specificati è stato ripristinato. Questa opzione:

    • Richiede che l'intera catena di backup sia disponibile in anticipo e caricata nell'account Archiviazione BLOB di Azure.
    • Non consente l'aggiunta di nuovi file di backup mentre è in corso la migrazione.
    • Richiede il comando start per specificare il nome file dell'ultimo file di backup.

    Consigliamo questa modalità di completamento automatico per i carichi di lavoro passivi per i quali non è necessario il recupero dei dati.

  • Modalità continua. Quando si usa la modalità continua, il servizio analizza continuamente la cartella Archiviazione BLOB di Azure e ripristina tutti i nuovi file di backup aggiunti durante la migrazione.

    La migrazione viene completata solo dopo la richiesta del cutover manuale.

    È necessario utilizzare la migrazione in modalità continua quando non si dispone dell'intera catena di backup in anticipo e quando si prevede di aggiungere nuovi file di backup mentre la migrazione è in corso.

    Consigliamo di utilizzare la modalità continua per i carichi di lavoro attivi per i quali è necessario il recupero dei dati.

Pianificare il completamento di un singolo processo di migrazione LRS entro un massimo di 30 giorni. Alla scadenza di questo periodo, il processo di LRS viene annullato automaticamente.

Nota

Quando si esegue la migrazione di più database, ogni database deve trovarsi nella propria cartella. L'archiviazione con ridondanza locale deve essere avviata separatamente per ogni database, che punta al percorso URI completo del contenitore Archiviazione BLOB di Azure e alla singola cartella del database. Le cartelle annidate all'interno delle cartelle di database non sono supportate.

Limitazioni di LRS

Per informazioni, esaminare le limitazioni quando si usa l'archiviazione con ridondanza locale.

Passaggi successivi