Condividi tramite

Eseguire la migrazione di database da SQL Server con Log Replay Service - Istanza gestita di SQL di Azure

  • Articolo

Si applica a:Istanza gestita di SQL di Azure SQL

Questo articolo illustra come eseguire la migrazione dei database a Istanza gestita di SQL di Azure usando il Log Replay Service (LRS). LRS è un servizio cloud gratuito disponibile per l'Istanza gestita di SQL di Azure, basato sulla tecnologia di log shipping di SQL Server.

Sono supportate le seguenti fonti:

  • SQL Server in macchine virtuali
  • Amazon EC2 (Elastic Compute Cloud)
  • Amazon RDS (Servizio di Database Relazionale) per SQL Server
  • Google Compute Engine
  • Cloud SQL per SQL Server - Google Cloud Platform (GCP)

Prerequisiti

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.
  • Non è possibile usare i database che vengono ripristinati tramite LRS (archiviazione con ridondanza locale) fino al termine del processo di migrazione.
  • LRS non supporta l'accesso in sola lettura ai database durante la migrazione.
  • Una volta terminata, la migrazione è definitiva e non può essere ripresa con backup differenziali aggiuntivi.

Prima di iniziare, considera i requisiti in questa sezione per l'istanza di SQL Server e Azure. Esaminare attentamente le sezioni limitazioni e procedure consigliate per garantire una migrazione corretta.

SQL Server

Assicurarsi di soddisfare i requisiti seguenti per il server di SQL:

  • Versioni di SQL Server dal 2008 al 2022.
  • Il database di SQL Server utilizza il modello di recupero completo (obbligatorio).
  • Backup completo dei database (uno o più file).
  • Backup differenziale (uno o più file).
  • Backup del log (non suddiviso per file del log delle transazioni).
  • Per le versioni SQL Server da 2008 a 2016, eseguire un backup in locale e caricarlo manualmente nell'account Archiviazione BLOB di Azure.
  • Per SQL Server 2016 e versioni successive, è possibile eseguire il backup direttamente nell'account Archiviazione BLOB di Azure.
  • CHECKSUM Anche se l'abilitazione per i backup non è necessaria, è consigliabile evitare involontariamente la migrazione di un database danneggiato e per operazioni di ripristino più veloci.

Azzurro

Assicurarsi di soddisfare i requisiti seguenti per Azure:

  • PowerShell Az.SQL modulo versione 4.0.0 o successiva (installato o accessibile tramite Azure Cloud Shell).
  • Versione 2.42.0 o successive dell’Interfaccia della riga di comando di Azure (installata).
  • Contenitore di Azure Blob Storage provisionato.
  • Token di sicurezza della firma di accesso condiviso con autorizzazioni Read e List generate per il contenitore Archiviazione Blob o un'identità gestita che può accedere al contenitore. La concessione di più autorizzazioni rispetto a Read e List causerà il fallimento di LRS.
  • Inserire i file di backup per un singolo database all'interno di una cartella separata in un account di archiviazione usando una struttura di file flat (obbligatoria). L'inserimento di cartelle nelle cartelle di database non è supportato.

Autorizzazioni RBAC di Azure

L'esecuzione di LRS tramite i client forniti richiede uno dei seguenti ruoli di controllo degli accessi basati sui ruoli di Azure:

  • Ruolo di Contributore per SQL Managed Instance
  • Ruolo con l'autorizzazione seguente: Microsoft.Sql/managedInstances/databases/*

Procedure consigliate

Quando si utilizza LRS, prendere in considerazione le seguenti procedure consigliate:

  • Eseguire Data Migration Assistant per verificare che i database siano pronti per la migrazione a Istanza gestita di SQL.
  • Suddividere i backup completi e differenziali in più file, anziché usare un singolo file.
  • Abilitare la compressione dei backup per favorire la velocità di trasferimento in rete.
  • Usare Cloud Shell per eseguire script di PowerShell o CLI, perché verrà sempre aggiornato per usare i cmdlet rilasciati più recenti.
  • Configurare una finestra di manutenzione in modo che gli aggiornamenti di sistema vengano pianificati in un giorno e un'ora specifici al di fuori della finestra di migrazione per evitare ritardi o interruzioni della migrazione.
  • Pianificare di completare un unico processo di migrazione a storage a ridondanza locale entro un massimo di 30 giorni. Alla scadenza di questo periodo di tempo, il lavoro LRS viene annullato automaticamente.
  • Per evitare involontariamente la migrazione di un database danneggiato e per un ripristino più rapido del database, abilitare CHECKSUM quando si eseguono i backup. Sebbene SQL Managed Instance esegua un controllo di integrità di base sui backup senza CHECKSUM, non è garantito che tutte le forme di danneggiamento vengano intercettate. L'esecuzione di backup con CHECKSUM è l'unico modo per garantire che il backup ripristinato in Istanza gestita di SQL non sia danneggiato. Il controllo di integrità di base sui backup senza CHECKSUM aumenta il tempo necessario per ripristinare un database.
  • Quando si esegue la migrazione al livello di servizio Business Critical , tenere conto di un ritardo prolungato nella disponibilità del database dopo il cutover, mentre il seeding dei database viene eseguito nelle repliche secondarie. Per database di grandi dimensioni con requisiti di tempo di inattività minimi, è consigliabile eseguire prima la migrazione al livello di servizio Utilizzo generico e quindi eseguire l'aggiornamento al livello di servizio Business Critical, oppure utilizzare il collegamento Istanza gestita per migrare i dati.
  • Il caricamento di migliaia di file di database da ripristinare può causare tempi di migrazione eccessivi e persino errori. Consolidare i database in un minor numero di file per velocizzare il processo di migrazione e garantirne il successo.
  • Per ridurre al minimo il tempo di cutover e ridurre il rischio di errore, assicurarsi che l'ultimo backup sia il più piccolo possibile.

Configurare una finestra di manutenzione

Gli aggiornamenti di sistema in Istanza gestita di SQL avranno la precedenza sulle migrazioni di database in corso.

La migrazione è interessata in modo diverso in base al livello di servizio:

  • Nel livello di servizio utilizzo generale, tutte le migrazioni LRS in sospeso vengono sospese e riprese solo dopo che l'aggiornamento è stato applicato. Questo comportamento del sistema potrebbe prolungare il tempo di migrazione, soprattutto per database di grandi dimensioni.
  • Nel livello di servizio Business Critical, tutte le migrazioni con ridondanza locale in sospeso vengono annullate e riavviate automaticamente dopo l'applicazione dell'aggiornamento. Questo comportamento del sistema potrebbe prolungare il tempo di migrazione, soprattutto per database di grandi dimensioni.

Per ottenere un tempo prevedibile per le migrazioni di database, è consigliabile configurare una finestra di manutenzione per pianificare gli aggiornamenti di sistema per un giorno e un'ora specifici ed eseguire e completare i processi di migrazione all'esterno dell'intervallo di tempo di manutenzione designato. Ad esempio, per una migrazione che inizia il lunedì, configurare la finestra di manutenzione personalizzata domenica per consentire il massimo tempo per completare la migrazione.

La configurazione di una finestra di manutenzione non è necessaria, ma è consigliabile per database di grandi dimensioni.

Nota

Anche se una finestra di manutenzione controlla la prevedibilità degli aggiornamenti pianificati , non garantisce che i failover non pianificati o gli aggiornamenti delle patch di sicurezza non si verifichino. Un failover non pianificato o una patch di sicurezza (che ha la precedenza su tutti gli altri aggiornamenti) può comunque interrompere la migrazione.

Eseguire la migrazione di più database

Se si esegue la migrazione di più database usando lo stesso contenitore Archivio BLOB di Azure, è necessario inserire i file di backup per database diversi in cartelle separate all'interno del contenitore. Tutti i file di backup per un database singolo devono essere inseriti in una struttura di file flat all'interno di una cartella di database e le cartelle non possono essere annidate. L'annidamento delle cartelle all'interno delle cartelle di database non è supportato.

Ecco un esempio di struttura di cartelle all'interno di un contenitore di Archiviazione BLOB di Azure, una struttura necessaria per eseguire la migrazione di più database utilizzando l'archiviazione con ridondanza locale (LRS).

-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>

-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>

-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure. 
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>

Creare un account di archiviazione

Si usa un account Archiviazione BLOB di Azure come risorsa di archiviazione intermedia per i file di backup tra l'istanza di SQL Server e la distribuzione Istanza gestita di SQL. Per creare un nuovo account di archiviazione e un contenitore BLOB all'interno dell'account di archiviazione:

  1. Creare un account di archiviazione.
  2. Crea un contenitore BLOB nell'account di archiviazione.

Configurare l'archiviazione di Azure dietro un firewall

L'uso dell'archiviazione BLOB di Azure protetto da un firewall è supportato, ma richiede una configurazione aggiuntiva. Per abilitare l'accesso in lettura/scrittura a Azure Storage con Azure Firewall attivato, è necessario aggiungere la subnet della SQL Managed Instance alle regole del firewall della rete virtuale per l'account di archiviazione usando la delega della MI subnet e l'endpoint del servizio Storage. L'account di archiviazione e l'istanza gestita devono trovarsi nella stessa area o in due aree abbinate.

Se l'archiviazione di Azure si trova dietro un firewall, è possibile che venga visualizzato il messaggio seguente nel log degli errori dell'istanza gestita di SQL:

Audit: Storage access denied user fault. Creating an email notification:

Viene generata un’email che informa che il controllo per l'istanza gestita di SQL non riesce a scrivere log di controllo nell'account di archiviazione. Se viene visualizzato questo errore o si riceve questo messaggio di posta elettronica, seguire la procedura descritta in questa sezione per configurare il firewall.

Per configurare il firewall, effettuare le operazioni seguenti:

  1. Passare all'istanza gestita nel portale di Azure e selezionare la subnet per aprire la pagina Subnet.

    Screenshot della pagina di panoramica dell'istanza gestita SQL nel portale di Azure, con la subnet selezionata.

  2. Nella pagina Subnet selezionare il nome della subnet per aprire la pagina di configurazione della subnet.

    Screenshot della pagina Subnet dell'istanza gestita SQL nel portale di Azure, con la subnet selezionata.

  3. In Delega subnet scegliere Microsoft.Sql/managedInstances dal menu a discesa Delega subnet a un servizio. Aspettare circa un'ora affinché le autorizzazioni si propaghino e quindi, in Endpoint di servizio, selezionare Microsoft.Storage dall'elenco a discesa Servizi.

    Screenshot della pagina di configurazione della subnet dell'Istanza gestita di SQL nel portale di Azure.

  4. Passare quindi all'account di archiviazione nel portale di Azure, selezionare Rete in Sicurezza e rete e quindi scegliere la scheda Firewall e reti virtuali.

  5. Nella scheda Firewall e reti virtuali per l'account di archiviazione scegliere +Aggiungi rete virtuale esistente per aprire la pagina Aggiungi reti.

    Screenshot della pagina della Rete dell'account di archiviazione nel portale di Azure, con l'opzione Aggiungi rete virtuale esistente selezionata.

  6. Selezionare la sottoscrizione appropriata, la rete virtuale e la subnet dell'istanza gestita dai menu a discesa e quindi selezionare Aggiungi per aggiungere la rete virtuale dell'istanza gestita di SQL all'account di archiviazione.

Autenticarsi nel proprio account Blob Storage

Usare un token SAS o un'identità gestita per accedere al servizio di Archiviazione BLOB di Azure.

Avviso

Non è possibile usare sia un token di firma di accesso condiviso che un'identità gestita in parallelo nello stesso account di archiviazione. Puoi usare o un token SAS o un'identità gestita, ma non entrambi.

Generare un token di autenticazione SAS per l’archiviazione BLOB con ridondanza locale (LRS)

Accedi al tuo account di Archiviazione BLOB di Azure utilizzando un token SAS.

È possibile usare un account Azure Blob Storage come risorsa di archiviazione intermedia per i file di backup tra l'istanza di SQL Server e la distribuzione SQL Istanza Gestita. Generare un token di autenticazione SAS per LRS con autorizzazioni di sola lettura e elenco. Il token consente a LRS (Local-Redundancy Storage) di accedere al tuo account di archiviazione Blob e utilizza i file di backup per ripristinarli nella tua istanza gestita.

Per generare il token, seguire questi passaggi:

  1. Aprire Storage Explorer nel portale di Azure.

  2. Espandi contenitori BLOB.

  3. Fare clic con il pulsante destro del mouse sul contenitore BLOB e quindi selezionare Ottieni firma di accesso condiviso.

    Screenshot che mostra le selezioni per la generazione di un token di autenticazione della firma di accesso condiviso (SAS).

  4. Selezionare l'intervallo di tempo per la scadenza del token. Assicurarsi che il token sia valido durante la migrazione.

  5. Selezionare il fuso orario per il token: UTC o l'ora locale.

    Importante

    Il fuso orario del token e dell'istanza gestita potrebbero non corrispondere. Assicurarsi che il token di firma di accesso condiviso abbia la validità temporale appropriata, considerando i fusi orari. Per tenere conto delle differenze del fuso orario, impostare il valore FROM di validità ben prima dell'avvio della finestra di migrazione e il valore TO dopo il completamento della migrazione.

  6. Selezionare solamente le autorizzazioni Lettura ed Elenco.

    Importante

    Non selezionare altre autorizzazioni. Se lo fai, l'archiviazione con ridondanza locale (LRS) non si avvierà. Questo requisito di sicurezza è previsto dalla progettazione.

  7. Seleziona Crea.

    Screenshot che mostra le opzioni per la scadenza del token SAS, il fuso orario, le autorizzazioni e il pulsante Crea.

L'autenticazione SAS viene generata con la validità temporale specificata. È necessaria la versione URI del token, come illustrato nello screenshot seguente:

Screenshot che mostra un esempio della versione URI di un token di firma di accesso condiviso.

Nota

L'uso di token di firma di accesso condiviso creati con autorizzazioni impostate attraverso la definizione di un criterio di accesso archiviato non è attualmente supportato. Seguire le istruzioni riportate in questa procedura per specificare manualmente le autorizzazioni Read e List per il token SAS.

Copiare i parametri dal token SAS

Accedi al tuo account di archiviazione Blob di Azure utilizzando un token SAS o un'identità gestita.

Prima di usare il token di firma di accesso condiviso per avviare l'archiviazione con ridondanza locale, è necessario comprenderne la struttura. L'URI del token di firma di accesso condiviso generato è costituito da due parti, separate da un punto interrogativo (?), come illustrato in questo esempio:

URI di esempio per un token di firma di accesso condiviso generato per il servizio di riproduzione log.

La prima parte, a partire da https:// fino al punto interrogativo (?), viene usata per il parametro StorageContainerURI fornito come input per l'archiviazione con ridondanza locale. Fornisce a LRS informazioni sulla cartella in cui sono archiviati i file di backup del database.

La seconda parte, da dopo il punto interrogativo (?) fino alla fine della stringa, è il parametro StorageContainerSasToken. Questa parte è il token di autenticazione firmato effettivo, valido durante l'ora specificata. Questa parte non deve necessariamente iniziare con sp= come illustrato nell'esempio. Lo scenario potrebbe essere diverso.

Copiare i parametri come indicato di seguito:

  1. Copiare la prima parte del token, da https:// fino a al punto interrogativo (?), ma senza includerlo. Usarlo come parametro StorageContainerUri in PowerShell o nell'interfaccia della riga di comando di Azure quando si avvia LRS.

    Screenshot che mostra dove copiare la prima parte del token.

  2. Copiare la seconda parte del token, da dopo il punto interrogativo (?) fino alla fine della stringa. Usarlo come parametro StorageContainerSasToken in PowerShell o nell'interfaccia della riga di comando di Azure quando si avvia LRS.

    Screenshot che mostra dove copiare la seconda parte del token.

Nota

Non includere il punto interrogativo (?) quando si copia una delle parti del token.

Convalidare l'accesso all'archiviazione dell'istanza gestita

Conferma che l'istanza gestita possa accedere all'account di Archiviazione Blob.

Prima di tutto, caricare qualsiasi backup del database, ad esempio full_0_0.bak, nel contenitore Archiviazione BLOB di Azure.

Connettersi quindi all'istanza gestita ed eseguire una query di test di esempio per determinare se l'istanza gestita è in grado di accedere al backup nel contenitore.

Se si usa un token di firma di accesso condiviso per eseguire l'autenticazione nell'account di archiviazione, sostituire <sastoken> con il token di firma di accesso condiviso ed eseguire la query seguente nell'istanza:

CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE' 
, SECRET = '<sastoken>' 

RESTORE HEADERONLY 
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak'

Caricare i backup nell'account di archiviazione BLOB

Quando il contenitore BLOB è pronto e si è verificato che l'istanza gestita può accedere al contenitore, è possibile iniziare a caricare i backup nell'account Archiviazione BLOB. È possibile:

  • Copiare backup nel tuo account di archiviazione Blob.
  • Eseguire i backup da SQL Server direttamente all'account di archiviazione BLOB usando il comando BACKUP TO URL, se l'ambiente lo consente (a partire da SQL Server versioni 2012 SP1 CU2 e SQL Server 2014).

Copia i backup esistenti nel tuo account Blob Storage

Se si usa una versione precedente di SQL Server o se l'ambiente non supporta il backup direttamente in un URL, eseguire i backup nell'istanza di SQL Server come si farebbe normalmente e quindi copiarli nell'account di Archiviazione BLOB.

Eseguire il backup in un'istanza di SQL Server

Imposta i database che vuoi migrare al modello di recupero completo per consentire i backup del log.

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master
ALTER DATABASE SampleDB
SET RECOVERY FULL
GO

Per eseguire manualmente backup completi, differenziali e del log del database nell'archiviazione locale, usare gli script T-SQL di esempio seguenti. CHECKSUM non è necessario, ma è consigliabile impedire la migrazione di un database danneggiato e per tempi di ripristino più rapidi.

Nell'esempio seguente viene eseguito un backup completo del database nel disco locale:

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

L'esempio seguente esegue un backup differenziale sul disco locale:

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

Nell'esempio seguente viene eseguito un backup del log delle transazioni nel disco locale:

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO

Copia i backup nel tuo account di Archiviazione Blob

Dopo che i backup sono pronti e si desidera avviare la migrazione dei database a un'istanza gestita usando LRS (Archiviazione con Ridondanza Locale), è possibile utilizzare i seguenti approcci per copiare i backup esistenti nel proprio account di archiviazione Blob:

Nota

Per eseguire la migrazione di più database usando lo stesso contenitore di Archiviazione BLOB di Azure, inserire tutti i file di backup per un singolo database in una cartella separata all'interno del contenitore. Usare la struttura di file flat per ogni cartella di database. L'annidamento delle cartelle all'interno delle cartelle di database non è supportato.

Esegui i backup direttamente nel tuo account di archiviazione Blob

Se si usa una versione supportata di SQL Server (a partire da SQL Server 2012 SP1 CU2 e SQL Server 2014) e i criteri di rete e aziendali lo consentono, è possibile eseguire backup da SQL Server direttamente all'account di Archiviazione BLOB usando l'opzione NATIVA SQL Server BACKUP TO URL. Se è possibile usare BACKUP TO URL, non è necessario eseguire backup nell'archiviazione locale e caricarli nell'account di Archiviazione BLOB.

Quando si eseguono backup nativi direttamente nell'account di Archiviazione BLOB, è necessario eseguire l'autenticazione nell'account di archiviazione.

Usare il comando seguente per creare una credenziale che importi il token SAS nell'istanza SQL Server.

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',  
SECRET = '<SAS_TOKEN>';

Per istruzioni dettagliate sull'uso dei token SAS, consultare il tutorial Usare Archiviazione BLOB di Azure con SQL Server.

Dopo aver creato le credenziali per autenticare l'istanza di SQL Server con archiviazione BLOV, è possibile usare il comando BACKUP TO URL per eseguire i backup direttamente nell'account di archiviazione. CHECKSUM è consigliato, ma non obbligatorio.

Il seguente esempio esegue un backup completo del database su un URL.

-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

Nell'esempio seguente viene eseguito un backup differenziale del database in un URL:

-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'  
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

Nell'esempio seguente viene eseguito un backup del log delle transazioni in un URL:

-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'  
WITH COMPRESSION, CHECKSUM

Accedere ad Azure e selezionare una sottoscrizione

Usare il seguente cmdlet di PowerShell per accedere ad Azure:

Login-AzAccount

Selezionare la sottoscrizione in cui risiede l'istanza gestita usando il cmdlet di PowerShell seguente:

Select-AzSubscription -SubscriptionId <subscription ID>

Avviare la migrazione

Iniziare la migrazione avviando LRS. È possibile avviare il servizio in modalità di completamento automatico o continua.

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 di Archiviazione BLOB. Non consente l'aggiunta di nuovi file di backup durante la migrazione. Questa opzione richiede il comando start per specificare il nome file dell'ultimo file di backup. Consigliamo questa modalità per i carichi di lavoro passivi per i quali non è necessario il recupero dei dati.

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 l'arrivo della richiesta di passaggio 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. Questa modalità è consigliata per i carichi di lavoro attivi per i quali è necessario il recupero dei dati.

Pianificare di completare un unico processo di migrazione a storage a ridondanza locale entro un massimo di 30 giorni. Al termine di questo intervallo di tempo, il lavoro LRS viene annullato automaticamente.

Nota

Quando si esegue la migrazione di più database, ogni database deve trovarsi nella propria cartella. Il servizio LRS deve essere avviato separatamente per ogni database, puntando al percorso URI completo del contenitore di Azure Blob Storage e alla cartella specifica del database. Le cartelle annidate all'interno delle cartelle di database non sono supportate.

Avvia LRS in modalità completamento automatico

Assicurarsi che l'intera catena di backup sia stata caricata nel tuo account Azure Blob Storage. Questa opzione non consente l'aggiunta di nuovi file di backup mentre è in corso la migrazione.

Per avviare LRS in modalità di completamento automatico, usare i comandi di PowerShell o dell'interfaccia della riga di comando di Azure. Specificare il nome del file di backup usando il parametro -LastBackupName. Al termine del ripristino dell'ultimo file di backup specificato, il servizio avvia automaticamente un cutover.

Ripristina il database dall'account di archiviazione attraverso il token SAS o un'identità gestita.

Importante

  • Assicurarsi che l'intera catena di backup sia stata caricata nell'account Archiviazione BLOB di Azure prima di avviare la migrazione in modalità di completamento automatico. Questa modalità non consente l'aggiunta di nuovi file di backup mentre è in corso la migrazione.
  • Assicurarsi di aver specificato correttamente l'ultimo file di backup e che non siano stati caricati altri file dopo di esso. Se il sistema rileva più file di backup oltre l'ultimo file di backup specificato, la migrazione avrà esito negativo.

L'esempio di PowerShell seguente avvia l'archiviazione LRS in modalità di completamento automatico usando un token SAS:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

L'esempio seguente della CLI di Azure avvia LRS in modalità di completamento automatico usando un token SAS:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Avvia LRS in modalità continua

Assicurati di aver caricato il backup iniziale nel tuo account Azure Blob Storage.

Importante

Dopo aver avviato LRS in modalità continua, potrai aggiungere nuovi backup di log e differenziali all’account di archiviazione fino al passaggio manuale. Dopo aver avviato il cutover manuale, non è possibile aggiungere o ripristinare altri file differenziali.

L'esempio di PowerShell seguente avvia LRS in modalità continua usando un token di firma di accesso condiviso:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

L'esempio seguente dell'interfaccia della riga di comando di Azure avvia l'archiviazione con ridondanza locale in modalità continua:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Creare uno script per il processo di migrazione

I client PowerShell e Azure CLI che avviano LRS in modalità continua sono sincroni. In questa modalità PowerShell e l'interfaccia della riga di comando di Azure attendono che la risposta dell'API segnali l'esito positivo o negativo prima di avviare il processo.

Durante questa attesa, il comando non restituisce il controllo al prompt dei comandi. Se stai impostando l'esperienza di migrazione e hai bisogno che il comando di avvio LRS restituisca immediatamente il controllo per proseguire con il resto dello script, puoi eseguire PowerShell come processo in background con lo switch -AsJob. Ad esempio:

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

Quando si avvia un processo in background, un oggetto processo viene immediatamente restituito, anche se il completamento del processo richiede un tempo prolungato. Puoi continuare a lavorare nella sessione senza interruzioni mentre il processo è in esecuzione. Per informazioni dettagliate sull'esecuzione di PowerShell come processo in background, vedere la documentazione Processo di avvio di PowerShell.

Analogamente, per avviare un comando dell'interfaccia della riga di comando di Azure in Linux come processo in background, usare la e commerciale (&) alla fine del comando di avvio dell'archiviazione con ridondanza locale:

az sql midb log-replay start <required parameters> &

Monitorare il progresso della migrazione

Az.SQL 4.0.0 e versioni successive fornisce un report dettagliato sullo stato di avanzamento. Esamina Dettagli ripristino del database gestito - Get per vedere un esempio di output.

Per monitorare lo stato di avanzamento della migrazione in corso tramite PowerShell, usare il comando seguente:

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Per monitorare lo stato di avanzamento della migrazione in corso tramite l'interfaccia della riga di comando di Azure, usare il comando seguente:

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

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.

Arrestare la migrazione (facoltativo)

Se è necessario arrestare la migrazione, usare PowerShell o l'interfaccia della riga di comando di Azure. L'arresto della migrazione elimina il database di ripristino nell'istanza gestita, quindi la ripresa della migrazione non sarà possibile.

Per arrestare il processo di migrazione tramite PowerShell, usare il comando seguente:

Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Per arrestare il processo di migrazione tramite l'interfaccia della riga di comando di Azure, usare il comando seguente:

az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb

Completare la migrazione (modalità continua)

Se si avvia LRS in modalità continua, assicurarsi che l'applicazione e il carico di lavoro di SQL Server siano stati arrestati per evitare la generazione di nuovi file di backup. Assicurarsi che l'ultimo backup dell'istanza di SQL Server sia stato caricato nel proprio account di Archiviazione Blob di Azure. Monitorare lo stato di avanzamento del ripristino nell'istanza gestita e verificare che l'ultimo backup della parte finale del log sia stato ripristinato.

Quando l'ultimo backup della parte finale del log è stato ripristinato nell'istanza gestita, avvia il cutover manuale per completare la migrazione. Al termine del cutover, il database diventa disponibile per l'accesso in lettura e scrittura nell'istanza gestita.

Per completare il processo di migrazione in modalità continua tramite LRS usando PowerShell, utilizzare il comando seguente:

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

Per completare il processo di migrazione in modalità continua LRS tramite la CLI di Azure, usare il comando seguente:

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

Limiti

Considerare le seguenti limitazioni quando si esegue la migrazione con LRS:

  • Non è possibile usare i database che vengono ripristinati tramite LRS (archiviazione con ridondanza locale) fino al termine del processo di migrazione.
  • 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.
  • Una volta terminata, la migrazione è definitiva e non può essere ripresa con backup differenziali aggiuntivi.
  • Solo i file di database .bak, .log e .diff sono supportati da LRS. I file Dacpac e bacpac non sono supportati.
  • È necessario configurare una finestra di manutenzione per pianificare gli 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:
    • può potenzialmente eseguire la migrazione di database danneggiati.
    • il ripristino richiede più tempo rispetto ai backup del database con CHECKSUM abilitato.
  • Il token di firma di accesso condiviso (SAS) utilizzato dall'archiviazione localmente ridondante deve essere generato per l'intero container di Archiviazione BLOB di Azure e deve avere solo le autorizzazioni Read e List. Ad esempio, se si concedono le autorizzazioni Read, List e Write, LRS non si avvia a causa dell'autorizzazione aggiuntiva Write.
  • L'uso di token di firma di accesso condiviso creati con autorizzazioni impostate tramite la definizione di politica di accesso memorizzata non è supportato. Seguire le istruzioni in questo articolo per specificare manualmente le autorizzazioni di Lettura e Lista per il token SAS.
  • Inserire i file di backup per i vari database in cartelle separate nell'account di Archiviazione BLOB in una struttura di file flat. La nidificazione delle cartelle all'interno delle cartelle di database non è supportata.
  • 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 LRS per ogni database che punta al percorso URI completo, il quale contiene una singola cartella del database.
  • Il percorso dell'URI di backup, il nome del contenitore o i nomi delle cartelle non possono contenere backup o Backup 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.
  • LRS può supportare fino a 100 processi di ripristino simultanei per una singola istanza gestita.
  • Un singolo lavoro LRS 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.
  • Il caricamento di migliaia di file di database da ripristinare può causare tempi di migrazione eccessivi e persino errori. Consolidare i database in un minor numero di file per velocizzare il processo di migrazione e garantirne il successo.
  • Esistono due scenari, all'inizio e alla fine del processo di migrazione, in cui viene interrotta una migrazione se si verifica un failover e il processo di migrazione deve essere riavviato manualmente dall'inizio quando il database viene eliminato da Istanza gestita di SQL:
    • Se si verifica un failover quando il primo backup completo del database è in fase di ripristino in Istanza gestita di SQL al primo avvio del processo di migrazione, il processo di migrazione deve essere riavviato manualmente dall'inizio.
    • Se si verifica un failover dopo l'inizio del cutover della migrazione, il processo di migrazione deve essere riavviato manualmente dall'inizio. Assicurarsi che l'ultimo file di backup sia il più piccolo possibile per ridurre al minimo il tempo di cutover e ridurre il rischio di un failover durante il processo di cutover.

Nota

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 come soluzione di migrazione consigliata.

Limitazioni durante la migrazione al livello di servizio Business Critical

Quando si esegue la migrazione a un Istanza gestita di SQL nel livello di servizio Business Critical, considerare le limitazioni seguenti:

  • Quando si esegue la migrazione di database di grandi dimensioni, possono verificarsi tempi di inattività notevoli perché i database non sono disponibili dopo il cutover, mentre vengono distribuiti alle repliche secondarie del livello di servizio Business Critical. Le soluzioni alternative sono elencate nella sezione cutover più lunga.
  • La migrazione viene riavviata automaticamente dall'inizio se la migrazione viene interrotta da un failover non pianificato, da un aggiornamento del sistema o da una patch di sicurezza, rendendo difficile pianificare una migrazione prevedibile senza sorprese dell'ultimo minuto.

Importante

Queste limitazioni sono applicabili solo quando si esegue la migrazione al livello di servizio Business Critical e non al livello di servizio Per utilizzo generico.

Cutover più lungo nel livello di servizio Business Critical

Se si esegue la migrazione a un'istanza gestita di SQL nel livello di servizio Business Critical, tenere conto del ritardo nella messa online dei database nella replica primaria durante il processo di seeding nelle repliche secondarie. Ciò vale soprattutto per i database di dimensioni maggiori.

La migrazione a un'istanza gestita SQL nel livello di servizio Business Critical richiede più tempo per essere completata rispetto al livello di servizio Generale. Al termine della migrazione su Azure, i database non sono disponibili fino a quando non sono stati trasferiti dalla replica primaria alle tre repliche secondarie, processo che può richiedere un tempo prolungato a seconda delle dimensioni del database. Maggiore è il database, più tempo richiede il seeding alle repliche secondarie, fino a diverse ore, potenzialmente.

Se è importante che i database siano disponibili non appena viene completato il cutover, prendere in considerazione le soluzioni alternative seguenti:

  • Eseguire prima la migrazione al livello di servizio Generico e quindi eseguire l'aggiornamento al livello di servizio Business Critical. L'aggiornamento del livello di servizio è un'operazione online che mantiene online i database fino a quando non viene eseguito un breve failover come passaggio finale dell'operazione di aggiornamento.
  • Usare il link Istanza gestita per una migrazione online a un'istanza Business Critical senza dover attendere che i database siano disponibili dopo il trasferimento.

Risolvere i problemi relativi a LRS

Dopo aver avviato LRS, usare uno dei cmdlet di monitoraggio seguenti per visualizzare lo stato dell'operazione in corso:

  • Per PowerShell: get-azsqlinstancedatabaselogreplay
  • Per l'interfaccia della riga di comando di Azure: az_sql_midb_log_replay_show

Per esaminare i dettagli relativi a un'operazione non riuscita:

Se LRS non viene avviato dopo un po' di tempo e si verifica un errore, verificare la presenza dei problemi più comuni:

  • Un database esistente nell'istanza gestita ha lo stesso nome di quello di cui si sta tentando di eseguire la migrazione dall'istanza di SQL Server? Risolvere il conflitto rinominando uno dei database.
  • Le autorizzazioni concesse per il token SAS sono solo di lettura e di elenco? La concessione di più autorizzazioni rispetto a Read e List causerà il fallimento di LRS.
  • Hai copiato il token SAS per LRS dopo il punto interrogativo (?), con contenuto simile a sv=2020-02-10...?
  • Il tempo di validità del token di firma di accesso condiviso è appropriato per l'intervallo di tempo di avvio e completamento della migrazione? Potrebbero esserci discrepanze a causa dei diversi fusi orari utilizzati per la distribuzione della Istanza gestita di SQL e il token di firma di accesso condiviso (SAS). Provare a rigenerare il token SAS ed estendere la validità del token per l'intervallo di tempo che precede e segue la data corrente.
  • Quando si avviano più ripristini di riproduzione log in parallelo e questi sono destinati allo stesso contenitore di archiviazione, assicurarsi che per ogni operazione di ripristino venga fornito lo stesso token SAS valido.
  • Il nome del database, il nome del gruppo di risorse e il nome dell'istanza gestita sono scritti correttamente?
  • Se hai avviato LRS in modalità completamento automatico, è stato specificato un nome file valido per l'ultimo file di backup?
  • Il percorso dell'URI di backup contiene parole chiave backup o backups? Rinominare il contenitore o le cartelle che usano backup o backups perché si tratta di parole chiave riservate.

Contenuto correlato