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

  • Articolo

Si applica a:Istanza gestita di SQL di Azure

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.

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

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.

Sono supportate le origini seguenti:

  • 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)

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 con PowerShell (get-azsqlinstancedatabaselogreplay) o l'interfaccia della riga di comando di Azure (cmdlet az_sql_midb_log_replay_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).

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, è necessario avviare separatamente LRS per ogni database che punta al percorso URI completo del contenitore di archiviazione BLOB di Azure e alla singola cartella del database.

Limitazioni di LRS

Tenere presente le limitazioni seguenti dell’archiviazione con ridondanza locale:

  • Solo i file di database .bak, .log e .diff sono supportati dall’archiviazione con ridondanza locale. I file Dacpac e bacpac non sono supportati.
  • Durante il processo di migrazione, i database di cui viene eseguita la migrazione non possono essere usati per l'accesso in sola lettura in Istanza gestita di SQL.
  • È necessario configurare una finestra di manutenzione per consentire la pianificazione degli aggiornamenti di sistema in un giorno e un'ora specifici. Pianificare l'esecuzione e completare le migrazioni all'esterno della finestra di manutenzione pianificata.
  • Backup del database eseguiti senza CHECKSUM richiedono più tempo per il ripristino rispetto ai backup del database con CHECKSUM abilitato.
  • Il token di firma di accesso condiviso usato dall'archiviazione con ridondanza locale deve essere generato per l'intero contenitore Archiviazione BLOB di Azure e deve disporre solo delle autorizzazioni Lettura ed Elenco. Ad esempio, se si concedono autorizzazioni lettura, elenco e scrittura, l'archiviazione con ridondanza locale non sarà in grado di avviare a causa del permesso di scrittura aggiuntiva.
  • L'uso di token di firma di accesso condiviso creati con autorizzazioni impostate tramite la definizione di criteri di accesso archiviati non è supportato. Seguire le istruzioni in questo articolo per specificare manualmente le autorizzazioni Lettura ed Elenco per il token di firma di accesso condiviso.
  • Inserire i file di backup per i vari database in una cartella separata nell’account di Archiviazione BLOB di Azure in una struttura di file flat. L'annidamento delle cartelle all'interno delle cartelle di database non è supportato.
  • Se si usa la modalità di completamento automatico, l'intera catena di backup deve essere disponibile in anticipo nell'account di Archiviazione BLOB. Non è possibile aggiungere nuovi file di backup in modalità completamento automatico. Usare la modalità continua se è necessario aggiungere nuovi file di backup durante la migrazione.
  • È necessario avviare separatamente l'archiviazione con ridondanza locale per ogni database che punta al percorso URI completo che contiene una singola cartella del database.
  • Il percorso dell'URI di backup, il nome del contenitore o i nomi delle cartelle non devono contenere backup o backups perché si tratta di parole chiave riservate.
  • Quando si avviano più ripristini di Log Replay in parallelo e la destinazione è lo stesso contenitore di archiviazione, assicurarsi che venga fornito lo stesso token di firma di accesso condiviso valido per ogni operazione di ripristino.
  • L’archiviazione con ridondanza locale può supportare fino a 100 processi di ripristino simultanei per singola istanza gestita.
  • Un singolo processo di archiviazione con ridondanza locale può essere eseguito per un massimo di 30 giorni, dopo il quale verrà annullato automaticamente.
  • Anche se è possibile usare un account Archiviazione di Azure dietro un firewall, è necessaria una configurazione aggiuntiva e l'account di archiviazione e l'istanza gestita devono trovarsi nella stessa area o in due aree abbinate. Per altre informazioni, vedere Configurare il firewall.
  • Il numero massimo di database che è possibile ripristinare in parallelo è 200 per sottoscrizione singola. In alcuni casi, è possibile aumentare questo limite aprendo un ticket di supporto.

Suggerimento

Se è necessario che un database sia accessibile in sola lettura durante la migrazione, con un intervallo di tempo molto più lungo per l'esecuzione della migrazione e con tempi di inattività minimi, è consigliabile usare la funzionalità di collegamento Istanza gestita di SQL di Azure come soluzione di migrazione consigliata.

Passaggi successivi