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

  • Artigo

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

Este artigo explica como migrar bancos de dados para a Instância Gerenciada SQL do Azure usando o LRS (Log Replay Service). 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.

São suportadas as seguintes origens:

  • SQL Server nas 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 seguintes requisitos para sua instância do SQL Server e do Azure.

SQL Server

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-o manualmente em sua conta de Armazenamento de Blob do Azure.
  • Para o SQL Server 2016 e posterior, você pode fazer o backup diretamente para sua conta de Armazenamento de Blob do Azure.

Embora não seja necessário ter CHECKSUM ativado para backups, é altamente recomendável para operações de restauração mais rápidas.

Azure

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

  • PowerShell Az.SQL módulo versão 4.0.0 ou posterior (instalado ou acessado por meio do Azure Cloud Shell).
  • Azure CLI versão 2.42.0 ou posterior (instalado).
  • Um contêiner provisionado de Armazenamento de Blob do Azure.
  • Um token de segurança de assinatura de acesso compartilhado (SAS) com permissões de Leitura e Lista geradas para o contêiner de Armazenamento de Blob ou uma identidade gerenciada que pode acessar o contêiner.
  • 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:

Melhores práticas

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

  • Execute o 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.
  • Ative a compressão de cópias de segurança 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 permitir o agendamento de atualizações do sistema em um dia e hora específicos. Essa configuração ajuda a obter um tempo mais previsível para migrações de banco de dados, porque as atualizações do sistema podem interromper as migrações em andamento.
  • 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 uma restauração mais rápida do banco de dados, habilite CHECKSUM quando estiver fazendo backups. A Instância Gerenciada SQL executa uma verificação de integridade em backups sem CHECKSUM, o que aumenta o tempo de restauraçã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. Durante uma atualização do sistema em uma instância, todas as migrações LRS pendentes são suspensas e retomadas somente depois que a atualização é aplicada. 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 para 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.

Importante

  • 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.
  • O LRS não oferece suporte ao acesso somente leitura a bancos de dados durante a migração.
  • Após a conclusão da migração, o processo de migração é final e não pode ser retomado com backups diferenciais adicionais.

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. Criar 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 vNet 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 armazenamento do Azure estiver protegido por um firewall, você] poderá ver a seguinte mensagem no log de erros da instância gerenciada SQL:

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

Isso gera um e-mail que notifica que a auditoria para a instância gerenciada SQL está falhando ao gravar logs 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 sua instância gerenciada no portal do Azure e selecione a sub-rede para abrir a página Sub-redes.

    Screenshot of the SQL managed instance Overview page of the Azure portal, with the subnet selected.

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

    Screenshot of the SQL managed instance Subnet page of the Azure portal, with the subnet selected.

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

    Screenshot of the SQL managed instance Subnet configuration page of the Azure portal.

  4. Em seguida, vá para sua conta de armazenamento no portal do Azure, selecione Rede em Segurança + rede e escolha a guia 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.

    Screenshot of the Storage Account Networking page of the Azure portal, with Add existing virtual network selected.

  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.

Aviso

Não é possível usar um token SAS e uma identidade gerenciada em paralelo na mesma conta de armazenamento. Você pode usar um token SAS ou uma identidade gerenciada, mas não ambos.

Gerar um token de autenticação SAS de armazenamento de Blob para LRS

Acesse sua conta de Armazenamento de Blobs do Azure usando um token SAS.

Você pode usar 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 da Instância Gerenciada do SQL. Gere um token de autenticação SAS para LRS apenas com permissões de Leitura e Lista. O token permite que o LRS acesse sua conta de armazenamento de Blob e usa os arquivos de backup para restaurá-los para sua instância gerenciada.

Siga estas etapas para gerar o token:

  1. No portal do Azure, abra o Gerenciador de Armazenamento.

  2. Expanda Contêineres de Blob.

  3. Clique com o botão direito do mouse no contêiner de blob e selecione Obter Assinatura de Acesso Compartilhado.

    Screenshot that shows selections for generating a SAS authentication token.

  4. Selecione o período de tempo para expiração do token. Certifique-se de que o token é válido durante a migração.

  5. Selecione o fuso horário para o token: UTC ou a sua hora local.

    Importante

    O fuso horário do token e sua instância gerenciada podem não corresponder. Certifique-se de que o token SAS tem a validade de tempo apropriada, levando em consideração os fusos horários. Para levar em conta as diferenças de fuso horário, defina o valor FROM de validade bem antes do início da janela de migração e o valor TO bem depois de esperar que a migração seja concluída.

  6. Selecione Somente permissões de Leitura e Lista .

    Importante

    Não selecione outras permissões. Se o fizer, o LRS não será iniciado. Este é um requisito de segurança predefinido.

  7. Selecione Criar.

    Screenshot that shows selections for SAS token expiration, time zone, and permissions, along with the Create button.

A autenticação SAS é gerada com a validade de tempo especificada. Você precisa da versão URI do token, conforme mostrado na captura de tela a seguir:

Screenshot that shows an example of the URI version of a SAS token.

Nota

No momento, não há suporte para o uso de tokens SAS criados com permissões definidas pela definição de uma política de acesso armazenado. Siga as instruções neste procedimento para especificar manualmente as permissões de Leitura e Lista para o token SAS.

Copiar parâmetros do token SAS

Acesse sua conta de Armazenamento de Blobs do Azure usando um token SAS ou uma identidade gerenciada.

Antes de usar o token SAS para iniciar o LRS, você precisa entender sua estrutura. O URI do token SAS gerado consiste em duas partes, separadas por um ponto de interrogação (?), conforme mostrado neste exemplo:

Example URI for a generated SAS token for Log Replay Service.

A primeira parte, começando com https:// até o ponto de interrogação (?), é usada para o parâmetro que é alimentado StorageContainerURI como a entrada para LRS. Ele fornece informações LRS sobre a pasta onde os arquivos de backup do banco de dados são armazenados.

A segunda parte, desde depois do ponto de interrogação (?) até o final da cadeia de caracteres, é o StorageContainerSasToken parâmetro. Esta parte é o token de autenticação assinado real, que é válido durante o tempo especificado. Esta parte não precisa necessariamente começar sp= , como mostrado no exemplo. Seu cenário pode ser diferente.

Copie os parâmetros da seguinte maneira:

  1. Copie a primeira parte do token, de até mas não incluindo o ponto de https:// interrogação (?). Use-o como parâmetro no PowerShell ou na CLI do Azure ao iniciar o StorageContainerUri LRS.

    Screenshot that shows where to copy the first part of the token.

  2. Copie a segunda parte do token, após o ponto de interrogação (?) até o final da cadeia de caracteres. Use-o como parâmetro no PowerShell ou na CLI do Azure ao iniciar o StorageContainerSasToken LRS.

    Screenshot that shows where to copy the second part of the token.

Nota

Não inclua o ponto de interrogação (?) quando copiar qualquer parte do token.

Valide o acesso ao armazenamento de instância gerenciada

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, para 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.

Se você estiver usando um token SAS para autenticar sua conta de armazenamento, substitua o <sastoken> por seu token SAS e execute a seguinte consulta em sua instância:

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'

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:

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

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 é obrigatório, mas nós recomendamos.

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 sua conta de armazenamento de 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:

Nota

Para migrar vários bancos de dados usando o mesmo contêiner de Armazenamento de Blob do Azure, coloque todos os arquivos de backup de um banco de dados individual em uma pasta separada dentro do contêiner. Use a estrutura de arquivo simples para cada pasta de banco de dados. Não há suporte para aninhamento de pastas dentro de pastas de banco de dados.

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 BACKUP TO URL do SQL Server. Se você puder usar BACKUP TO URLo , 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 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 start comando 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 substituição 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.

Nota

Quando você estiver migrando vários bancos de dados, o LRS deve ser iniciado separadamente para cada banco de dados e apontar para o caminho de URI completo do contêiner de Armazenamento de Blobs do Azure e para a pasta de banco de dados individual.

Iniciar o LRS no modo de preenchimento automático

Verifique se toda a cadeia de backup foi carregada na sua conta de Armazenamento de Blob do Azure. 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 -LastBackupName parâmetro. Após a conclusão da restauração do último arquivo de backup especificado, o serviço inicia automaticamente uma substituição.

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

Importante

  • Certifique-se de que toda a cadeia de backup foi carregada em sua conta de Armazenamento de Blob do Azure antes de iniciar a migração no modo de preenchimento automático. Esse modo não permite que novos arquivos de backup sejam adicionados enquanto a migração está em andamento.
  • Certifique-se de que especificou o último ficheiro de cópia de segurança corretamente e de que não carregou mais ficheiros depois dele. Se o sistema detetar mais arquivos de backup além do último arquivo de backup especificado, a migração falhará.

O exemplo do PowerShell a seguir inicia o LRS no modo de preenchimento automático usando um 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"

O exemplo da CLI do Azure a seguir inicia o LRS no modo de preenchimento automático usando um 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"

Iniciar o LRS em modo contínuo

Certifique-se de que carregou a cadeia de cópias de segurança inicial para a sua conta de Armazenamento de Blobs do Azure.

Importante

Depois de iniciar o LRS no modo contínuo, você poderá adicionar novos backups de log e diferenciais à sua conta de armazenamento até a transferência manual. Depois que a substituição manual tiver sido iniciada, nenhum arquivo diferencial adicional poderá ser adicionado ou restaurado.

O exemplo do PowerShell a seguir inicia o LRS no modo contínuo usando um 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"

O exemplo da CLI do Azure a seguir inicia o LRS no modo contínuo:

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"

Script do 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 o -AsJob switch. 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 o trabalho é executado. 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 LRS start:

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

Monitorar o progresso da migração

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

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

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

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

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

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 substituição, o banco de dados fica disponível para acesso de leitura e gravação na instância gerenciada.

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"

Solucionar problemas do LRS

Depois de iniciar o LRS, use um dos seguintes cmdlets de monitoramento para ver o status da operação:

  • Para PowerShell: get-azsqlinstancedatabaselogreplay
  • Para a CLI do Azure: az_sql_midb_log_replay_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 apenas para o token SAS Read and List?
  • Você copiou o token SAS para LRS após o ponto de interrogação (?), com conteúdo que se parece sv=2020-02-10...com ? 
  • 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 da janela 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 como estas são palavras-chave reservadas.

Próximos passos