Migrar bancos de dados do SQL Server usando o Serviço de Repetição de Log - Instância Gerenciada SQL do Azure

Aplica-se a:Instância Gerenciada do Azure SQL

Este artigo explica como migrar bancos de dados para a Instância Gerenciada SQL do Azure usando o Log Replay Service (LRS). O LRS é um serviço de nuvem gratuito que está disponível para a Instância Gerenciada SQL do Azure, com base na tecnologia de envio de logs do SQL Server.

As seguintes fontes são suportadas:

• SQL Server em máquinas virtuais
• Amazon EC2 (nuvem de computação elástica)
• Amazon RDS (serviço de banco de dados relacional) para SQL Server
• Mecanismo de computação do Google
• Cloud SQL para SQL Server - GCP (Google Cloud Platform)

Pré-requisitos

Antes de começar, considere os requisitos nesta seção para sua instância do SQL Server e do Azure. Analise cuidadosamente as seções de limitações e de melhores práticas , para garantir uma migração bem-sucedida.

Servidor SQL

Certifique-se de atender aos seguintes requisitos para o SQL Server:

• SQL Server versões 2008 a 2022.
• Seu banco de dados do SQL Server está usando o modelo de recuperação completa (obrigatório).
• Um backup completo de bancos de dados (um ou vários arquivos).
• Um backup diferencial (um ou vários arquivos).
• Um backup de log (não dividido para um arquivo de log de transações).
• Para as versões 2008 a 2016 do SQL Server, faça um backup localmente e carregue manualmente ele em sua conta de Armazenamento de Blob do Azure.
• Para o SQL Server 2016 e posterior, você pode fazer o backup diretamente sua conta de Armazenamento de Blob do Azure.
• Embora não seja necessário ter CHECKSUM habilitado para backups, é altamente recomendável evitar a migração involuntária de um banco de dados corrompido e para operações de restauração mais rápidas.

Azure

Certifique-se de que cumpre os seguintes requisitos para o Azure:

• PowerShell módulo Az.SQL versão 4.0.0 ou posterior (instalado ou acessado através do Azure Cloud Shell).
• CLI do Azure versão 2.42.0 ou mais recente (já instalado).
• Um contentor provisionado de Armazenamento de Blobs do Azure.
• Um token de segurança de assinatura de acesso compartilhado (SAS) com permissões de Read e List geradas para o contentor de Blob Storage ou uma identidade gerida que pode aceder ao contentor. Conceder mais permissões do que Read e List fará com que o LRS falhe.
• Coloque os arquivos de backup de um banco de dados individual dentro de uma pasta separada em uma conta de armazenamento usando uma estrutura de arquivo simples (obrigatório). Não há suporte para aninhamento de pastas dentro de pastas de banco de dados.

Permissões do RBAC do Azure

A execução do LRS por meio dos clientes fornecidos requer uma das seguintes funções RBAC (controle de acesso baseado em função) do Azure:

• função de Colaborador de SQL Managed Instance
• Uma função com a seguinte permissão: Microsoft.Sql/managedInstances/databases/*

Melhores práticas

Ao usar o LRS, considere as seguintes práticas recomendadas:

• Execute Assistente de Migração de Dados para validar se seus bancos de dados estão prontos para serem migrados para a Instância Gerenciada SQL.
• Divida backups completos e diferenciais em vários arquivos, em vez de usar um único arquivo.
• Habilite a compactação de backup para ajudar na velocidade de transferência da rede.
• Use o Cloud Shell para executar scripts do PowerShell ou da CLI, pois ele sempre será atualizado para usar os cmdlets lançados mais recentemente.
• Configure uma janela de manutenção para que as atualizações do sistema sejam agendadas em um dia e hora específicos fora da janela de migração para evitar atrasar ou interromper a migração.
• Planeje concluir um único trabalho de migração LRS dentro de um máximo de 30 dias. Após a expiração deste período de tempo, o trabalho LRS é automaticamente cancelado.
• Para evitar a migração involuntária de um banco de dados corrompido e para uma restauração mais rápida do banco de dados, habilite CHECKSUM quando estiver fazendo backups. Embora a Instância Gerenciada SQL execute uma verificação de integridade básica em backups sem CHECKSUM, não é garantido capturar todas as formas de corrupção. Fazer backups com CHECKSUM é a única maneira de garantir que o backup restaurado para a Instância Gerenciada SQL não esteja corrompido. A verificação de integridade básica em backups sem CHECKSUM aumenta o tempo de restauração de um banco de dados.
• Ao migrar para a camada de serviço Business Critical, leve em conta um atraso prolongado na disponibilidade do banco de dados após a transferência, enquanto os bancos de dados são propagados para réplicas secundárias. Para bases de dados especialmente grandes com requisitos mínimos de tempo de inatividade, considere migrar primeiro para a camada de serviço de Uso Geral e, em seguida, atualizar para a camada de serviço Business Critical, ou usar o link Managed Instance para migrar os seus dados.
• Carregar milhares de arquivos de banco de dados para restaurar pode levar a tempos de migração excessivos e até mesmo falhas. Consolide bancos de dados em menos arquivos para acelerar o processo de migração e garantir seu sucesso.
• Para minimizar o tempo de substituição e reduzir o risco de falha, certifique-se de que seu último backup seja o menor possível.

Configurar uma janela de manutenção

As atualizações do sistema para a Instância Gerenciada SQL têm precedência sobre as migrações de banco de dados em andamento.

A migração é afetada de forma diferente com base na camada de serviço:

• Na camada de serviço de uso geral, todas as migrações LRS pendentes são suspensas e retomadas somente após a aplicação da atualização. Esse comportamento do sistema pode prolongar o tempo de migração, especialmente para bancos de dados grandes.
• Na camada de serviço Business Critical, todas as migrações LRS pendentes são canceladas e reiniciadas automaticamente após a aplicação da atualização. Esse comportamento do sistema pode prolongar o tempo de migração, especialmente para bancos de dados grandes.

Para obter um tempo previsível para migrações de banco de dados, considere configurar uma janela de manutenção agendar atualizações do sistema para um dia e hora específicos e executar e concluir trabalhos de migração fora do período de tempo da janela de manutenção designada. Por exemplo, para uma migração que começa na segunda-feira, configure sua janela de manutenção personalizada no domingo para permitir o máximo de tempo para concluir a migração.

A configuração de uma janela de manutenção não é necessária, mas é altamente recomendada para bancos de dados grandes.

Migrar vários bancos de dados

Se você estiver migrando vários bancos de dados usando o mesmo contêiner de Armazenamento de Blob do Azure, deverá colocar arquivos de backup para bancos de dados diferentes em pastas separadas dentro do contêiner. Todos os arquivos de backup de um único banco de dados devem ser colocados em uma estrutura de arquivo simples dentro de uma pasta de banco de dados e as pastas não podem ser aninhadas. Não há suporte para aninhamento de pastas dentro de pastas de banco de dados.

Aqui está um exemplo de uma estrutura de pastas dentro de um contêiner de Armazenamento de Blob do Azure, uma estrutura necessária para migrar vários bancos de dados usando o 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>

Criar uma conta de armazenamento

Você usa uma conta de Armazenamento de Blob do Azure como armazenamento intermediário para arquivos de backup entre sua instância do SQL Server e sua implantação de Instância Gerenciada do SQL. Para criar uma nova conta de armazenamento e um contêiner de blob dentro da conta de armazenamento:

1. Crie uma conta de armazenamento.
2. Crie um contêiner de blob dentro da conta de armazenamento.

Configurar o armazenamento do Azure atrás de um firewall

O uso do armazenamento de Blob do Azure protegido por um firewall é suportado, mas requer configuração adicional. Para habilitar o acesso de leitura/gravação ao Armazenamento do Azure com o Firewall do Azure ativado, você precisa adicionar a sub-rede da instância gerenciada SQL às regras de firewall da rede virtual para a conta de armazenamento usando a delegação de sub-rede MI e o ponto de extremidade do serviço de Armazenamento. A conta de armazenamento e a instância gerenciada devem estar na mesma região ou em duas regiões emparelhadas.

Se o seu armazenamento do Azure estiver protegido por um firewall, poderá ver a seguinte mensagem no registo de erros da instância gerida SQL:

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

Isso gera um e-mail que te notifica de que a auditoria para a instância gerida do SQL está a falhar ao gravar os registos de auditoria na conta de armazenamento. Se vir este erro ou receber este e-mail, siga os passos nesta secção para configurar a firewall.

Para configurar o firewall, siga estas etapas:

1. Vá para a sua instância gerida no portal do Azure e selecione a sua sub-rede para abrir a página Sub-redes .

   

2. Na página Sub-redes, selecione o nome da sub-rede para abrir a página de configuração da sub-rede.

   

3. pt-PT: Em delegação de sub-rede, escolha Microsoft.Sql/managedInstances na lista suspensa de delegação de sub-rede para um serviço. Aguarde cerca de uma hora para que as permissões se propaguem e, em seguida, em Pontos de extremidade de serviço, escolha Microsoft.Storage na lista suspensa Serviços de .

   

4. Em seguida, vá para a sua conta de armazenamento no portal do Azure, selecione Rede em Segurança + rede e, em seguida, escolha o separador Firewalls e redes virtuais.

5. Na guia Firewalls e redes virtuais da sua conta de armazenamento, escolha +Adicionar rede virtual existente para abrir a página Adicionar redes.

   

6. Selecione a assinatura, a rede virtual e a sub-rede de instância gerenciada apropriadas nos menus suspensos e, em seguida, selecione Adicionar para adicionar a rede virtual da instância gerenciada SQL à conta de armazenamento.

Autenticar na sua conta de Armazenamento de Blobs

Use um token SAS ou uma identidade gerenciada para acessar sua conta de Armazenamento de Blob do Azure.

Valide o acesso ao armazenamento da instância gerida

Valide se sua instância gerenciada pode acessar sua conta de armazenamento de Blob.

Primeiro, carregue qualquer backup de banco de dados, como full_0_0.bak, em seu contêiner de Armazenamento de Blob do Azure.

Em seguida, conecte-se à instância gerenciada e execute uma consulta de teste de exemplo para determinar se a instância gerenciada pode acessar o backup no contêiner.

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' 

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

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'MANAGED IDENTITY' 

Carregue backups para sua conta de armazenamento de Blob

Quando o contêiner de blob estiver pronto e você confirmar que sua instância gerenciada pode acessar o contêiner, poderá começar a carregar seus backups para sua conta de Armazenamento de Blob. Pode escolher entre:

• Copie seus backups para sua conta de armazenamento de Blob.
• Faça backups do SQL Server diretamente para a sua conta de Armazenamento Blob usando o comando BACKUP TO URL, se o seu ambiente permitir (a partir das versões SQL Server 2012 SP1 CU2 e SQL Server 2014).

Copie backups existentes para sua conta de armazenamento de Blob

Se você estiver em uma versão anterior do SQL Server ou se seu ambiente não oferecer suporte ao backup diretamente em uma URL, faça os backups na instância do SQL Server como faria normalmente e copie-os para sua conta de Armazenamento de Blob.

Fazer backups em uma instância do SQL Server

Defina os bancos de dados que você deseja migrar para o modelo de recuperação completa para permitir backups de 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

Para fazer manualmente backups completos, diferenciais e de log do seu banco de dados para armazenamento local, use os seguintes scripts T-SQL de exemplo. CHECKSUM não é necessário, mas é recomendado para evitar a migração de um banco de dados corrompido e para tempos de restauração mais rápidos.

O exemplo a seguir faz um backup completo do banco de dados para o disco local:

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

O exemplo a seguir usa um backup diferencial para o disco local:

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

O exemplo a seguir usa um backup de log de transações para o disco local:

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

Copiar backups para a sua conta de armazenamento Blob

Depois que os backups estiverem prontos e você quiser começar a migrar bancos de dados para uma instância gerenciada usando o LRS, poderá usar as seguintes abordagens para copiar backups existentes para sua conta de Armazenamento de Blob:

• Transfira e instale AzCopy.
• Transfira e instale Azure Storage Explorer.
• Use Explorador de Armazenamento no portal do Azure.

Faça backups diretamente para sua conta de armazenamento de Blob

Se você estiver em uma versão com suporte do SQL Server (começando com o SQL Server 2012 SP1 CU2 e o SQL Server 2014) e suas políticas corporativas e de rede permitirem, você poderá fazer backups do SQL Server diretamente para sua conta de Armazenamento de Blob usando a opção nativa do SQL Server BACKUP PARA URL. Se você puder usar BACKUP TO URL, não precisará fazer backups para o armazenamento local e carregá-los para sua conta de Armazenamento de Blob.

Quando você faz backups nativos diretamente para sua conta de Armazenamento de Blob, precisa se autenticar na conta de armazenamento.

Use o seguinte comando para criar uma credencial que importe o token SAS para sua instância do SQL Server:

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

Para obter instruções detalhadas sobre como trabalhar com tokens SAS, consulte o tutorial Usar o Armazenamento de Blobs do Azure com o SQL Server.

Depois de criar a credencial para autenticar sua instância do SQL Server com o Armazenamento de Blobs, você pode usar o comando BACKUP TO URL para fazer backups diretamente na conta de armazenamento. CHECKSUM é recomendado, mas não obrigatório.

O exemplo a seguir leva um backup de banco de dados completo para uma 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

O exemplo a seguir usa um backup de banco de dados diferencial para uma 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

O exemplo a seguir usa um backup de log de transações para uma 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

Entre no Azure e selecione uma assinatura

Use o seguinte cmdlet do PowerShell para entrar no Azure:

Login-AzAccount

Selecione a assinatura onde sua instância gerenciada reside usando o seguinte cmdlet do PowerShell:

Select-AzSubscription -SubscriptionId <subscription ID>

Iniciar a migração

Inicie a migração iniciando o LRS. Você pode iniciar o serviço no modo de preenchimento automático ou no modo contínuo .

Quando você usa o modo de preenchimento automático, a migração é concluída automaticamente quando o último dos arquivos de backup especificados tiver sido restaurado. Essa opção requer que toda a cadeia de backup esteja disponível com antecedência e seja carregada na sua conta de Armazenamento de Blob. Ele não permite adicionar novos arquivos de backup enquanto a migração está em andamento. Esta opção requer o comando start para especificar o nome do arquivo do último arquivo de backup. Recomendamos este modo para cargas de trabalho passivas para as quais a recuperação de dados não é necessária.

Quando você usa o modo contínuo, o serviço verifica continuamente a pasta Armazenamento de Blob do Azure e restaura todos os novos arquivos de backup que são adicionados enquanto a migração está em andamento. A migração só termina após a mudança manual ter sido solicitada. Você precisa usar a migração em modo contínuo quando não tiver toda a cadeia de backup com antecedência e quando planeja adicionar novos arquivos de backup depois que a migração estiver em andamento. Recomendamos esse modo para cargas de trabalho ativas para as quais a recuperação de dados é necessária.

Planeje concluir um único trabalho de migração LRS dentro de um máximo de 30 dias. Quando esse tempo expira, o trabalho LRS é automaticamente cancelado.

Iniciar o LRS no modo de preenchimento automático

Assegure-se de que toda a cadeia de cópias de segurança foi carregada na sua conta de armazenamento do Azure Blob. Essa opção não permite que novos arquivos de backup sejam adicionados enquanto a migração estiver em andamento.

Para iniciar o LRS no modo de preenchimento automático, use os comandos PowerShell ou CLI do Azure. Especifique o último nome do arquivo de backup usando o parâmetro -LastBackupName. Após concluir a restauração do último ficheiro de backup especificado, o serviço inicia automaticamente um corte.

Restaure seu banco de dados da conta de armazenamento usando o token SAS ou uma identidade gerenciada.

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"

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"

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity  `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

Iniciar o LRS em modo contínuo

Certifique-se de que fez o upload da cadeia de backups inicial para a sua conta de Armazenamento de Blobs do Azure.

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"

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"

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity

Script para o trabalho de migração

Os clientes PowerShell e CLI do Azure que iniciam o LRS no modo contínuo são síncronos. Nesse modo, o PowerShell e a CLI do Azure aguardam a resposta da API para relatar o sucesso ou a falha antes de iniciarem o trabalho.

Durante essa espera, o comando não retornará o controle para o prompt de comando. Se você estiver criando scripts para a experiência de migração e precisar que o comando LRS start devolva o controle imediatamente para continuar com o restante do script, poderá executar o PowerShell como um trabalho em segundo plano com a opção -AsJob. Por exemplo:

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

Quando você inicia um trabalho em segundo plano, um objeto de trabalho retorna imediatamente, mesmo que o trabalho demore muito tempo para ser concluído. Você pode continuar a trabalhar na sessão sem interrupção enquanto a tarefa está a ser executada. Para obter detalhes sobre como executar o PowerShell como um trabalho em segundo plano, consulte a documentação do PowerShell Start-Job.

Da mesma forma, para iniciar um comando da CLI do Azure no Linux como um processo em segundo plano, use o e comercial (&) no final do comando do processo LRS start:

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

Monitorar o progresso da migração

Az.SQL 4.0.0 e posteriores fornecem um relatório de progresso detalhado. Revise os detalhes da restauração do banco de dados gerido - Obtenha para uma saída de exemplo.

Para monitorar o progresso da migração contínua por meio do PowerShell, use o seguinte comando:

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

Para monitorar o progresso da migração contínua por meio da CLI do Azure, use o seguinte comando:

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

Para acompanhar detalhes adicionais sobre uma solicitação com falha, use o comando do PowerShell Get-AzSqlInstanceOperation ou o comando da CLI do Azure az sql mi op show.

Interromper a migração (opcional)

Se você precisar interromper a migração, use o PowerShell ou a CLI do Azure. Interromper a migração exclui o banco de dados de restauração em sua instância gerenciada, portanto, não será possível retomar a migração.

Para interromper o processo de migração por meio do PowerShell, use o seguinte comando:

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

Para interromper o processo de migração por meio da CLI do Azure, use o seguinte comando:

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

Concluir a migração (modo contínuo)

Se você iniciar o LRS no modo contínuo, verifique se o aplicativo e a carga de trabalho do SQL Server foram interrompidos para impedir que novos arquivos de backup sejam gerados. Verifique se o último backup da sua instância do SQL Server foi carregado na sua conta de Armazenamento de Blob do Azure. Monitore o progresso da restauração em sua instância gerenciada e verifique se o último backup de log-tail foi restaurado.

Quando o último backup de log-tail tiver sido restaurado em sua instância gerenciada, inicie a substituição manual para concluir a migração. Após a conclusão da mudança, o banco de dados torna-se disponível para leitura e gravação na instância gerida.

Para concluir o processo de migração no modo contínuo LRS por meio do PowerShell, use o seguinte comando:

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

Para concluir o processo de migração no modo contínuo LRS por meio da CLI do Azure, use o seguinte comando:

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

Limitações

Considere as seguintes limitações ao migrar com o LRS:

• Não é possível usar bancos de dados que estão sendo restaurados por meio do LRS até que o processo de migração seja concluído.
• Durante o processo de migração, os bancos de dados que estão sendo migrados não podem ser usados para acesso somente leitura na Instância Gerenciada SQL.
• Após a conclusão da migração, o processo de migração é final e não pode ser retomado com backups diferenciais adicionais.
• Somente arquivos de .bak, .loge .diff de banco de dados são suportados pelo LRS. Os ficheiros Dacpac e bacpac não são suportados.
• Você precisa configurar uma janela de manutenção para agendar atualizações do sistema em um dia e hora específicos. Planeje executar e concluir migrações fora da janela de manutenção agendada.
• Backups de banco de dados feitos sem CHECKSUM:
  • pode potencialmente migrar bancos de dados corrompidos.
  • demorar mais tempo a restaurar do que os backups de bases de dados com CHECKSUM habilitada.
• O token de assinatura de acesso compartilhado (SAS) que o LRS usa deve ser gerado para todo o contêiner de Armazenamento de Blob do Azure e deve ter apenas permissões Read e List. Por exemplo, se concederes permissões de Read, Liste Write, o LRS falha ao iniciar devido à permissão extra de Write.
• Não há suporte para o uso de tokens SAS criados com permissões configuradas através de uma política de acesso armazenada . Siga as instruções neste artigo para especificar manualmente as permissões de Leitura e Lista para o token SAS.
• Você deve colocar arquivos de backup para diferentes bancos de dados em pastas separadas na conta de Armazenamento de Blob em uma estrutura de arquivo simples. Não há suporte para aninhamento de pastas dentro de pastas de banco de dados.
• Caso esteja a usar o modo de preenchimento automático, toda a cadeia de backup precisa estar disponível com antecedência na conta de Blob Storage. Não é possível adicionar novos arquivos de backup no modo de preenchimento automático. Use o modo contínuo se precisar adicionar novos arquivos de backup enquanto a migração estiver em andamento.
• Você deve iniciar o LRS separadamente para cada base de dados que aponta para o caminho URI completo que contém uma pasta de base de dados individual.
• O caminho do URI de backup, o nome do contêiner ou os nomes das pastas não devem conter backup ou backups, pois são palavras-chave reservadas.
• Ao iniciar várias restaurações do Log Replay em paralelo, visando o mesmo contêiner de armazenamento, certifique-se de que o mesmo token SAS válido seja fornecido para cada operação de restauração.
• O LRS pode suportar até 100 processos de restauração simultâneos por única instância gerenciada.
• Um único trabalho LRS pode ser executado por um máximo de 30 dias, após os quais será automaticamente cancelado.
• Embora seja possível usar uma conta de Armazenamento do Azure atrás de um firewall, é necessária uma configuração extra e a conta de armazenamento e a instância gerenciada devem estar na mesma região ou em duas regiões emparelhadas. Consulte Configuração do firewall para obter mais informações.
• O número máximo de bancos de dados que você pode restaurar em paralelo é de 200 por assinatura única. Em alguns casos, é possível aumentar esse limite abrindo um ticket de suporte.
• Carregar milhares de arquivos de banco de dados para restaurar pode levar a tempos de migração excessivos e até mesmo falhas. Consolide bancos de dados em menos arquivos para acelerar o processo de migração e garantir seu sucesso.
• Há dois cenários, no início e no final do processo de migração, em que uma migração é abortada se ocorrer um failover e o trabalho de migração deve ser reiniciado manualmente desde o início à medida que o banco de dados é descartado da Instância Gerenciada SQL:
  • Se ocorrer um failover quando o primeiro backup completo do banco de dados estiver sendo restaurado para a Instância Gerenciada do SQL quando o trabalho de migração for iniciado pela primeira vez, o trabalho de migração deverá ser reiniciado manualmente desde o início.
  • Se ocorrer um failover após o início da interrupção da migração, o processo de migração deverá ser reiniciado manualmente desde o início. Certifique-se de que o último arquivo de backup seja o menor possível para minimizar o tempo de substituição e reduzir o risco de failover durante o processo de substituição.

Limitações ao migrar para a camada de serviço Business Critical

Ao migrar para uma instância gerenciada SQL na camada de serviço Business Critical, considere as seguintes limitações:

• Ao migrar grandes bases de dados, pode haver um tempo de inatividade considerável, uma vez que as bases de dados ficam indisponíveis após a transição, enquanto são inicializadas para as réplicas secundárias do nível de serviço Business Critical. As soluções alternativas estão listadas na secção de transição mais longa.
• A migração é reiniciada automaticamente desde o início se a migração for interrompida por um failover não planejado, atualização do sistema ou patch de segurança, dificultando o planejamento de uma migração previsível sem surpresas de última hora.

Transição mais longa no nível de serviço Business Critical

Se você estiver migrando para uma Instância Gerenciada SQL na camada de serviço Business Critical, contabilize o atraso em colocar os bancos de dados online na réplica primária enquanto eles são propagados para as réplicas secundárias. Isso é especialmente verdadeiro para bancos de dados maiores.

A migração para uma instância gerenciada SQL na camada de serviço Business Critical leva mais tempo para ser concluída do que na camada de serviço de uso geral. Após a conclusão da transferência para o Azure, os bancos de dados ficam indisponíveis até que tenham sido propagados da réplica primária para as três réplicas secundárias, o que pode levar um período prolongado de tempo, dependendo do tamanho do banco de dados. Quanto maior o banco de dados, mais tempo a semeadura para as réplicas secundárias leva - até várias horas, potencialmente.

Se for importante que os bancos de dados estejam disponíveis assim que a substituição for concluída, considere as seguintes soluções alternativas:

• Migre primeiro para a camada de serviço Geral e, em seguida, atualize para a camada de serviço Business Critical. A atualização da camada de serviço é uma operação online que mantém os bancos de dados online até que, como etapa final da operação de atualização, ocorra um breve failover.
• Use o link Instância Gerenciada para uma migração on-line para uma instância Business Critical sem ter que esperar que os bancos de dados estejam disponíveis após a transferência.

Solucionar problemas do LRS

Depois de iniciar o LRS, utilize um dos seguintes cmdlets de monitorização para verificar o estado da operação em curso:

• Para PowerShell: get-azsqlinstancedatabaselogreplay
• Para a CLI do Azure: az_sql_midb_log_replay_show

Para verificar os detalhes sobre uma operação com falha:

• Para PowerShell: Get-AzSqlInstanceOperation
• Para a CLI do Azure: az sql mi op show

Se o LRS não conseguir iniciar após algum tempo e você receber um erro, verifique os problemas mais comuns:

• Um banco de dados existente em sua instância gerenciada tem o mesmo nome daquele que você está tentando migrar da instância do SQL Server? Resolva esse conflito renomeando um dos bancos de dados.
• As permissões concedidas para o token SAS Read and List são apenas? Conceder mais permissões do que Read e List fará com que o LRS falhe.
• Você copiou o token SAS para LRS após o ponto de interrogação (?), com conteúdo que se parece com sv=2020-02-10...?
• O tempo de validade do token SAS é apropriado para a janela de tempo de iniciar e concluir a migração? Pode haver incompatibilidades devido aos diferentes fusos horários usados para sua implantação de Instância Gerenciada SQL e o token SAS. Tente regenerar o token SAS e estender a validade do token para o período de tempo antes e depois da data atual.
• Ao iniciar várias restaurações do Log Replay em paralelo visando o mesmo contêiner de armazenamento, certifique-se de que o mesmo token SAS válido seja fornecido para cada operação de restauração.
• O nome do banco de dados, o nome do grupo de recursos e o nome da instância gerenciada estão escritos corretamente?
• Se você iniciou o LRS no modo de preenchimento automático, foi especificado um nome de arquivo válido para o último arquivo de backup?
• O caminho do URI de backup contém palavras-chave backup ou backups? Renomeie o contêiner ou pastas que estão usando backup ou backups pois são palavras-chave reservadas.

Próximos passos

• Saiba mais sobre como migrar para a Instância Gerenciada SQL do Azure usando o recurso de link.
• Saiba mais sobre migrar do SQL Server para a Instância Gerida SQL do Azure.
• Saiba mais sobre as diferenças entre o SQL Server e a Instância Gerenciada do SQL.
• Saiba mais sobre práticas recomendadas para custear e dimensionar cargas de trabalho migradas para o Azure.