Condividi tramite

Panoramica del servizio di riproduzione dei log con Istanza gestita SQL di Azure

Si applica a:Istanza gestita di SQL di Azure SQL

Questo articolo offre una panoramica del Log Replay Service (LRS), che è possibile utilizzare per eseguire la migrazione di database da SQL Server a Istanza gestita di Azure SQL. LRS è un servizio cloud gratuito disponibile per Azure SQL Managed Instance ed è basato sulla tecnologia di log shipping di SQL Server.

Nota

È ora possibile eseguire la migrazione dell'istanza di SQL Server abilitata da Azure Arc a Istanza gestita di SQL di Azure direttamente tramite il portale di Azure. Per altre informazioni, vedere Eseguire la migrazione a Istanza gestita di SQL di Azure.

Poiché LRS (archiviazione con ridondanza locale) ripristina i file di backup standard di SQL Server, è possibile utilizzarlo per eseguire la migrazione da SQL Server ospitato ovunque (sia in locale che su qualsiasi cloud) all'istanza gestita di Azure SQL.

Per avviare la migrazione con Log Replay Service, vedere Eseguire la migrazione di database da SQL Server 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

Azure Database Migration Service, l'estensione di migrazione SQL di Azure per Azure Data Studio e LRS usano la stessa tecnologia di migrazione e le stesse API sottostanti. LRS consente inoltre complesse migrazioni personalizzate e architetture ibride tra istanze di SQL Server locali e distribuzioni di istanze gestite 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 dell'archiviazione con ridondanza locale (LRS) nei casi seguenti:

  • È necessario un maggiore controllo per il progetto di migrazione del database.
  • Non c'è margine di tolleranza per i tempi di inattività durante la transizione della migrazione.
  • Non è possibile installare il file eseguibile del Servizio Migrazione del database nell'ambiente.
  • Il file eseguibile del Servizio di Migrazione del Database non ha accesso ai backup del database.
  • Non è possibile installare l'estensione di migrazione sql di Azure all'ambiente oppure non è possibile accedere ai backup del database.
  • Non si ha accesso al sistema operativo host o ai 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 nel tuo ambiente.
  • I backup vengono archiviati direttamente negli account Archiviazione BLOB di Azure tramite l'opzione TO URL.
  • È necessario usare i backup differenziali.

Dato che LRS funziona utilizzando i file di backup standard di SQL Server, supporta le migrazioni da qualsiasi origine. Sono state testate le seguenti origini:

  • SQL Server in sede
  • 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)
  • Servizio di database relazionale 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

  • LRS è l'unico metodo per ripristinare i backup differenziali nelle istanze gestite di SQL. Non è possibile ripristinare manualmente i backup differenziali nelle istanze gestite o impostare manualmente la NORECOVERY modalità tramite T-SQL.

Funzionamento di LRS

La creazione di una soluzione personalizzata per la migrazione dei database nel cloud con archiviazione con ridondanza locale (LRS) 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. LRS supporta backup completi, dei registri e differenziali. Successivamente, si utilizza il servizio cloud LRS per ripristinare i file di backup dall'account di archiviazione BLOB di Azure all'istanza gestita SQL. L'account di archiviazione BLOB funge da archivio intermedio per i file di backup tra SQL Server e istanza gestita di SQL.

LRS monitora il tuo account di Archiviazione BLOB per 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. LRS ripristina i database in modalità NORECOVERY, quindi non possono essere usati per carichi di lavoro di lettura o scrittura fino al termine 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 altre informazioni, vedere Eseguire la migrazione di database da SQL Server tramite il Servizio di riproduzione log.

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 l'intera catena di backup è stata generata in anticipo e quando non si prevede di aggiungere più 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 termina automaticamente quando viene ripristinato l'ultimo file di backup specificato. Il database migrato diventa 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 analizza periodicamente la cartella di Azure Blob Storage e ripristina eventuali nuovi file di backup log o differenziali che trova.

Quando sei pronto per la commutazione, ferma il carico di lavoro nell'istanza di SQL Server, genera l'ultimo file di backup e poi caricalo. Verificare che l'ultimo file di backup venga ripristinato controllando che l'ultimo backup del log tail venga mostrato come ripristinato su SQL Managed Instance. Avviare quindi il cutover manuale. Il passaggio finale di migrazione fa sì che il database sia online e pronto per l'accesso di lettura e scrittura nell'Istanza SQL gestita.

Dopo che LRS è stato arrestato, automaticamente tramite autocomplete o manualmente tramite cutover, non è possibile riprendere il processo di ripristino per un database che hai portato online su SQL Managed Instance. 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

L'immagine in questa sezione mostra un flusso di lavoro di migrazione tipico mentre la tabella descrive i passaggi.

Usare la modalità di completamento automatico solo quando tutti i file della catena di backup sono disponibili in anticipo. È consigliabile usare questa modalità per i carichi di lavoro passivi che non richiedono 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à è consigliabile per i carichi di lavoro attivi che richiedono il recupero dei dati.

Diagramma che illustra i passaggi di orchestrazione del servizio Riproduzione Log per Istanza SQL gestita.

Operazione 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 Blob Storage 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. Avviare il servizio con PowerShell (start-azsqlinstancedatabaselogreplay) o con l'Azure CLI (az_sql_midb_log_replay_start cmdlets). Scegliere tra il completamento automatico o la modalità di migrazione continua.

Avviare separatamente LRS (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 di Archiviazione Blob e inizia a ripristinarli in un'istanza SQL gestita.

Quando si avvia LRS in modalità autocomplete, vengono ripristinati tutti i backup tramite l'ultimo file di backup specificato. È necessario caricare tutti i file di backup in anticipo e non è possibile aggiungere nuovi file di backup mentre è in corso la migrazione. Questa modalità è consigliata per i carichi di lavoro passivi che non richiedono il recupero dei dati.

Quando avvii LRS in modalità continua, vengono ripristinati tutti i backup inizialmente caricati e si controllano i nuovi file che carichi nella cartella. Il servizio applica continuamente i log in base alla catena di numerazione del log (LSN) fino a quando non viene arrestato manualmente. Questa modalità è consigliabile per i carichi di lavoro attivi che richiedono il recupero dei dati.
2.1. Monitorare i progressi dell’operazione. Monitorare lo stato dell'operazione di ripristino in corso con PowerShell (get-azsqlinstancedatabaselogreplay) o l'Azure CLI (az_sql_midb_log_replay_show cmdlet). 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 il LRS per un database. È necessario riavviare il processo di migrazione dall'inizio.
3. Migrare al cloud quando si è pronti. Se si avvia LRS in modalità di completamento automatico, la migrazione termina automaticamente dopo il ripristino dell'ultimo file di backup specificato.

Se avvii LRS in modalità continua, arresta l'applicazione e il workload. Eseguire l'ultimo backup della parte finale del log e caricarlo nel deployment Azure Blob Storage. Assicurarsi che l'ultimo backup della parte finale del log venga ripristinato nell'istanza gestita di SQL. Completare il cutover avviando un'operazione LRS con PowerShell (complete) o con l'Azure CLI 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.

Reindirizzare la stringa di connessione dell'applicazione dall'istanza di SQL Server all'Istanza SQL gestita. È 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, l'Istanza gestita di SQL con il livello di servizio Business Critical può richiedere significativamente più tempo rispetto a Generico per essere disponibile, poiché è 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.

Eseguire la migrazione di database di grandi dimensioni

Se si esegue la migrazione di database di grandi dimensioni di diversi terabyte, prendere in considerazione i punti seguenti:

  • 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 possono interrompere e prolungare 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 di sistema sospendono e riprendono automaticamente per le istanze gestite di SQL per utilizzo generico e riavviano per le istanze gestite di SQL business critical . Questi aggiornamenti influiscono 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

Iniziare la migrazione avviando LRS. È possibile avviare il servizio in modalità di completamento automatico o continua. Per informazioni specifiche, vedere Migrare database da SQL Server usando il servizio Log Replay.

  • Modalità di completamento automatico. Quando si usa la modalità di completamento automatico, la migrazione termina automaticamente quando viene ripristinato l'ultimo dei file di backup specificati. 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 che hai richiesto il passaggio manuale.

    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.

    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, l'attività LRS viene annullata automaticamente.

Nota

Quando si esegue la migrazione di più database, ogni database deve trovarsi nella propria cartella. Avviare LRS separatamente per ogni database, puntando al percorso URI completo del contenitore di 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 LRS.

Contenuto correlato

  • Last updated on