Migrar bancos de dados do SQL Server usando o Serviço de Reprodução de Log – Instância Gerenciada de SQL do Azure
Aplica-se a:
Instância Gerenciada de SQL do Azure
Este artigo explica como migrar bancos de dados para a Instância Gerenciada de SQL do Azure usando o LRS (Serviço de Reprodução de Log). O LRS é um serviço de nuvem gratuito que está disponível para a Instância Gerenciada de SQL do Azure, baseado na tecnologia de envio de logs do SQL Server.
Há suporte para as fontes a seguir:
- 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
- Google Compute Engine
- SQL de Nuvem para SQL Server – GCP (Google Cloud Platform)
Pré-requisitos
Antes de começar, considere os requisitos a seguir para sua instância de SQL Server e para o Azure.
SQL Server
Verifique se você tem os seguintes requisitos para o SQL Server:
- Versões do SQL Server 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 do SQL Server 2008 a 2016, faça um backup localmente e carregue-o manualmente em sua conta do Armazenamento de Blobs do Azure.
- A partir do SQL Server 2016 e posterior, você pode levar seu backup diretamente para a conta de Armazenamento de Blobs 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
Verifique se você tem os seguintes requisitos para o Azure:
- Módulo Az.SQL do PowerShell versão 4.0.0 ou posterior (instalado ou acessado por meio do Azure Cloud Shell).
- CLI do Azure versão 2.42.0 ou posterior (instalada).
- Um contêiner provisionado do Armazenamento de Blobs do Azure.
- Um token de segurança SAS (assinatura de acesso compartilhado) com permissões de Leitura e Lista geradas para o contêiner do Armazenamento de Blobs ou uma identidade gerenciada que possa acessar o contêiner.
- Coloque os arquivos de backup de um banco de dados individual em uma pasta separada em uma conta de armazenamento usando a estrutura de arquivo simples (obrigatório). Não há suporte para pastas aninhadas dentro de pastas de banco de dados.
Permissões RBAC do Azure
A execução do LRS por meio dos clientes fornecidos requer uma das seguintes funções de RBAC (controle de acesso baseado em função) do Azure:
- Função Colaborador da Instância Gerenciada de SQL
- Uma função personalizada com a seguinte permissão:
Microsoft.Sql/managedInstances/databases/*
Práticas recomendadas
Ao usar o LRS, considere as seguintes melhores práticas:
- Execute o Assistente de Migração de Dados para validar que os bancos de dados estão prontos para serem migrados para a Instância Gerenciada de SQL.
- Divida os backups completos e diferenciais em vários arquivos em vez de usar um único arquivo.
- Habilite a compactação de backup para ajudar nas velocidades de transferência da rede.
- Use o Cloud Shell para executar scripts PowerShell ou 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 atingir um tempo mais previsível para migrações de banco de dados, pois as atualizações do sistema podem interromper migrações em andamento.
- Planeje concluir um só trabalho de migração LRS em no máximo 30 dias. Quando esse período vencer, o trabalho do LRS será cancelado automaticamente.
- Para uma restauração de banco de dados mais rápida, habilite
CHECKSUMao fazer backups. A Instância Gerenciada de SQL executa uma verificação de integridade nos backups semCHECKSUM, o que aumenta o tempo de restauração.
As atualizações do sistema na Instância Gerenciada de SQL terão precedência em relação às 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 após a aplicação da atualização. Esse comportamento do sistema pode prolongar o tempo de migração, principalmente em 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 janela de manutenção designado.
Importante
- Você não pode usar os 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 dá suporte a acesso somente leitura a bancos de dados durante a migração.
- Após a conclusão da migração, o processo de migração será finalizado e não poderá ser retomado com backups diferenciais adicionais.
Migrar vários bancos de dados
Caso esteja migrando vários bancos de dados usando o mesmo contêiner do Armazenamento de Blobs do Azure, você deverá colocar os arquivos de backup de bancos de dados diferentes em pastas separadas dentro do contêiner. Todos os arquivos de backup de um banco de dados individual precisam 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 pastas aninhadas dentro de pastas de banco de dados.
Aqui está um exemplo de uma estrutura de pasta dentro de um contêiner de Armazenamento de Blobs 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 Blobs 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 de SQL. Para criar uma nova conta de armazenamento e um contêiner de blobs dentro da conta de armazenamento:
- Criar uma conta de armazenamento.
- Crie um contêiner de blobs na conta de armazenamento.
Configurar o armazenamento do Azure com a proteção de um firewall
Há suporte para o uso do Armazenamento de Blobs do Azure protegido por um firewall, mas isso exige uma configuração adicional. Para habilitar o acesso de leitura/gravação no Armazenamento do Azure com o Firewall do Azure ativado, você precisa adicionar a sub-rede da instância gerenciada de SQL às regras de firewall da VNet da conta de armazenamento usando a delegação de sub-rede da MI e o ponto de extremidade do serviço de Armazenamento. A conta de armazenamento e a instância gerenciada precisam 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 de SQL:
Audit: Storage access denied user fault. Creating an email notification:
Isso gera um email que notifica você de que a auditoria para a instância gerenciada de SQL não está conseguindo gravar os logs de auditoria na conta de armazenamento. Se você vir esse erro ou receber esse email, siga as etapas desta seção para configurar o firewall.
Para configurar o cofre, siga estas etapas:
Acesse a instância gerenciada no portal do Azure e selecione a sub-rede para abrir a página Sub-redes.
Na página Sub-redes, escolha o nome da sub-rede para abrir a página de configuração da sub-rede.
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 sejam propagadas e, em Pontos de extremidade de serviço, escolha Microsoft.Storage na lista suspensa Serviços.
Em seguida, acesse sua conta de armazenamento no portal do Azure, selecione Rede em Segurança + rede e escolha a guia Firewalls e redes virtuais.
Na guia Firewalls e redes virtuais da conta de armazenamento, escolha +Adicionar rede virtual existente para abrir a página Adicionar redes.
Escolha a assinatura apropriada, a rede virtual e a sub-rede da instância gerenciada nos menus suspensos e selecione Adicionar para adicionar a rede virtual da instância gerenciada de SQL à conta de armazenamento.
Autenticar em sua conta de Armazenamento de Blobs
Acesse sua conta Armazenamento de Blobs do Azure usando um token SAS ou uma identidade gerenciada.
Aviso
Não é possível usar um token SAS e uma identidade gerenciada em paralelo na mesma conta de armazenamento. Você pode usar tanto um token SAS quanto uma identidade gerenciada, mas não ambos.
Gerar um token de autenticação SAS do Armazenamento de Blobs para o LRS
Acesse sua conta de Armazenamento de Blobs do Azure usando um token SAS.
Você pode usar uma conta de Armazenamento de Blobs 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 de 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 do Armazenamento de Blobs e use os arquivos de backup para restaurá-los para sua instância gerenciada.
Siga estas etapas para gerar o token:
No portal do Azure, abra o Gerenciador de Armazenamento.
Expanda Contêineres de Blob.
Clique com o botão direito do mouse no contêiner de blob e selecione Obter Assinatura de Acesso Compartilhado.
Selecione o período de duração do token. Verifique se o token é válido durante a migração.
Selecione o fuso horário para o token: UTC ou seu horário local.
Importante
O fuso horário do token e sua instância gerenciada podem não ser compatíveis. Verifique se o token SAS tem a validade de tempo apropriada, levando os fusos horários em consideração. Para contabilizar as diferenças de fuso horário, defina o valor A PARTIR DE da validade bem antes do início da janela de migração e o valor ATÉ bem depois de esperar que a migração termine.
Selecione apenas as permissões de Leitura e Lista.
Importante
Não selecione nenhuma outra permissão. Se você fizer isso, o LRS não será iniciado. Esse requisito de segurança é proposital.
Selecione Criar.
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:
Observação
No momento, não há suporte para o uso de tokens SAS criados com permissões definidas durante a configuração da política de acesso armazenada. 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 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 a estrutura dele. O URI do token SAS gerado consiste em duas partes separadas por um ponto de interrogação (?), conforme mostrado neste exemplo:
A primeira parte, começando com https:// até o ponto de interrogação (?), é usada para o parâmetro StorageContainerURI que é alimentado como a entrada no LRS. Ele fornece ao LRS informações sobre a pasta em que os arquivos de backup dos bancos de dados são armazenados.
A segunda parte, depois do ponto de interrogação (?) até o final da cadeia de caracteres, é o parâmetro StorageContainerSasToken. Essa parte é o token de autenticação assinado real, que é válido durante a duração do tempo especificado. Essa parte não precisa necessariamente começar com sp=, como mostrado no exemplo. Seu cenário pode ser diferente.
Edite os seguintes parâmetros:
Copie a primeira parte do token, de
https://até, mas não incluindo, o ponto de interrogação (?). Use-o como o parâmetroStorageContainerUrino PowerShell ou na CLI do Azure ao iniciar o LRS.
Copie a segunda parte do token, depois do ponto de interrogação (
?) até o final da cadeia de caracteres. Use-o como o parâmetroStorageContainerSasTokenno PowerShell ou na CLI do Azure ao iniciar o LRS.
Observação
Não inclua o ponto de interrogação (?) ao copiar qualquer parte do token.
Validar o acesso de armazenamento da instância gerenciada
Valide se sua instância gerenciada pode acessar sua conta de Armazenamento de Blobs.
Primeiro, carregue qualquer backup de banco de dados, como full_0_0.bak, no contêiner do Armazenamento de Blobs do Azure.
Em seguida, conecte-se à instância gerenciada e execute um exemplo de consulta de teste para determinar se a instância gerenciada pode acessar o backup no contêiner.
Se você estiver usando um token SAS para se autenticar na sua conta de armazenamento, substitua o <sastoken> pelo token SAS e execute a seguinte consulta na 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'
Carregar backups em sua conta de Armazenamento de Blobs
Quando seu contêiner de blobs estiver pronto e você confirmar que sua instância gerenciada pode acessar o contêiner, você poderá começar a carregar seus backups para sua conta de Armazenamento de Blobs. Você pode:
- Copie seus backups para sua conta de Armazenamento de Blobs.
- Se o ambiente permitir, faça backups de SQL Server diretamente para sua conta de Armazenamento de Blobs usando o comando BACKUP TO URL (começando com o SQL Server versões 2012 SP1 CU2 e SQL Server 2014).
Copiar backups existentes para sua conta de Armazenamento de Blobs
Se você estiver usando uma versão anterior do SQL Server ou se o ambiente não der suporte ao backup diretamente na URL, faça seus backups no SQL Server como normalmente faria e copie-os para sua conta de Armazenamento de Blobs do Azure.
Fazer backups em uma Instância do SQL Server
Configure os bancos de dados que você deseja migrar para o modo de recuperação completa para permitir backups de logs.
-- 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 de seu banco de dados para o armazenamento local, use os seguintes scripts de exemplo do T-SQL. CHECKSUM não é necessário, mas é recomendável.
O exemplo a seguir usa 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 Blobs
Depois que os backups estiverem prontos e você quiser começar a migrar os bancos de dados para uma instância gerenciada usando o LRS, use as seguintes abordagens para copiar os backups existentes para sua conta de Armazenamento de Blobs:
- Baixar e instalar o AzCopy.
- Baixe e instale o Gerenciador de Armazenamento do Azure.
- Use o Gerenciador de Armazenamento no portal do Azure.
Observação
Para migrar vários bancos de dados usando o mesmo contêiner do Armazenamento de Blobs 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 pastas aninhadas dentro de pastas de banco de dados.
Fazer backups diretamente na sua conta de Armazenamento de Blobs
Se você estiver usando uma versão com suporte do SQL Server (a partir do SQL Server 2012 SP1 CU2 e do SQL Server 2014) e suas políticas corporativas e de rede permitirem isso, faça backups do SQL Server diretamente para a sua conta de Armazenamento de Blobs usando a opção nativa do SQL Server BACKUP TO URL. Se você puder usar BACKUP TO URL, não precisará fazer backups no armazenamento local e carregá-los na sua conta de Armazenamento de Blobs.
Ao fazer backups nativos diretamente na sua conta de Armazenamento de Blobs do Azure, você precisa se autenticar na conta de armazenamento.
Use o seguinte comando para criar uma credencial que importa o token SAS para a 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, confira 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, use o comando BACKUP TO URL para fazer backups diretamente na conta de armazenamento. CHECKSUM é recomendado, mas não é obrigatório.
O exemplo a seguir usa um backup completo do banco de dados para um 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 um 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 um 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
Entrar no Azure e selecionar uma assinatura
Use o seguinte cmdlet do PowerShell para conectar no Azure:
Login-AzAccount
Selecione a assinatura na qual está a instância gerenciada usando o seguinte cmdlet do PowerShell:
Select-AzSubscription -SubscriptionId <subscription ID>
Inicie 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.
Ao usar o modo de preenchimento automático, a migração é finalizada automaticamente quando o último dos arquivos de backup especificados tiver sido restaurado. Essa opção exige que toda a cadeia de backup esteja disponível com antecedência e seja carregada na sua conta de Armazenamento de Blobs do Azure. Ela não permite adicionar novos arquivos de backup enquanto a migração está em andamento. Essa opção requer que o comando start especifique o nome do arquivo do último backup. Recomendamos este modo para cargas de trabalho passivas que não exigem atualização de dados.
Quando você usa o modo contínuo, o serviço examina continuamente a pasta do Armazenamento de Blobs do Azure e restaura os novos arquivos de backup que foram adicionados enquanto a migração está em andamento. A migração só é finalizada após a solicitação de substituição manual. Você precisará usar a migração de modo contínuo quando não tiver toda a cadeia de backup com antecedência e ao planejar adicionar novos arquivos de backup depois que a migração estiver em andamento. Recomendamos este modo para cargas de trabalho ativas que exigem atualização de dados.
Planeje concluir um só trabalho de migração LRS em no máximo 30 dias. Quando esse período vencer, o trabalho do LRS será cancelado automaticamente.
Observação
Ao migrar vários bancos de dados, o LRS deverá ser iniciado separadamente para cada banco de dados e apontará para o caminho de URI completo do contêiner do Armazenamento de Blobs do Azure e da 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 Blobs 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 do PowerShell ou do CLI do Azure. Especifique o nome do último arquivo de backup usando o parâmetro -LastBackupName. Depois que a restauração do último arquivo de backup especificado for concluída, o serviço iniciará uma substituição automaticamente.
Restaure seu banco de dados da conta de armazenamento usando o token SAS ou uma identidade gerenciada.
Importante
- Verifique se toda a cadeia de backup foi carregada em sua conta de Armazenamento de Blobs 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 estiver em andamento.
- Verifique se você especificou o último arquivo de backup corretamente e que não carregou mais arquivos depois dele. Se o sistema detectar mais arquivos de backup além do último arquivo de backup especificado, a migração falhará.
O exemplo seguinte do PowerShell 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 seguinte da CLI do Azure 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 no modo contínuo
Verifique se você carregou a cadeia de backup inicial na sua conta de Armazenamento de Blobs do Azure.
Importante
Depois de iniciar o LRS no modo contínuo, você poderá adicionar novos logs e backups diferenciais a sua conta de armazenamento até que ocorra a substituição manual. Depois que a substituição manual for iniciada, nenhum arquivo diferencial adicional poderá ser adicionado nem restaurado.
O exemplo seguinte do PowerShell 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 do PowerShell e da CLI do Azure que irão iniciar o LRS no modo contínuo são síncronos. Nesse modo, o PowerShell e a CLI do Azure aguardarão a resposta da API para relatar o sucesso ou a falha antes de iniciar o trabalho.
Durante essa espera, o comando não devolverá o controle ao prompt de comando. Se você estiver criando scripts para a experiência de migração e precisar do comando “start” do LRS para devolver o controle imediatamente e continuar com o restante do script, você 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, obtém imediatamente como retorno um objeto de trabalho, mesmo que o trabalho demore muito tempo para ser finalizado. É possível 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 Start-Job do PowerShell.
Da mesma forma, para iniciar um comando do CLI do Azure no Linux como um processo em segundo plano, use o “e” comercial (&) no final do comando “start” do LRS:
az sql midb log-replay start <required parameters> &
Monitorar o progresso da migração
O Az.SQL 4.0.0 e posterior fornece um relatório de progresso detalhado. Confira Detalhes de restauração do banco de dados gerenciado – GET para ver um exemplo de saída.
Para monitorar o progresso de 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
Parar 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 sendo restaurado na sua instância gerenciada. Portanto, retomar a migração não será possível.
Para parar o processo de migração por meio do PowerShell, use o seguinte comando:
Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName"
Para parar o processo de migração por meio do 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 evitar que novos arquivos de backup sejam gerados. Verifique se o último backup de sua instância do SQL Server foi carregado no Armazenamento de Blobs do Azure. Monitore o progresso da restauração em sua instância gerenciada, garantindo que o último backup da parte final do log tenha sido restaurado.
Quando o último backup da parte final do log for restaurado em sua instância gerenciada, inicie a substituição manual para concluir a migração. Depois que a substituição for concluída, o banco de dados ficará disponível para acesso de leitura e gravação na instância gerenciada.
Para concluir o processo de migração no modo contínuo do 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 do LRS por meio do CLI do Azure, use o seguinte comando:
az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"
Solução de problemas de LRS
Depois de iniciar o LRS, use um dos seguintes cmdlets de monitoramento para verificar o status da operação:
- Para o PowerShell:
get-azsqlinstancedatabaselogreplay - Para a CLI do Azure:
az_sql_midb_log_replay_show
Se a inicialização do LRS falhar após algum tempo e você receber um erro, verifique os problemas mais comuns:
- Há na sua instância gerenciada um banco de dados com o mesmo nome que aquele que você está tentando migrar de sua instância do SQL Server? Resolva esse conflito renomeando um dos bancos de dados.
- As permissões concedidas pelo token SAS são apenas de Leitura e Lista?
- Você copiou o token SAS para LRS após o ponto de interrogação (
?), com conteúdo semelhante asv=2020-02-10...? - O tempo de validade do token SAS é apropriado para a janela de tempo de inicialização e conclusão da migração? Pode haver incompatibilidades devido aos diferentes fusos horários usados para sua implantação da Instância Gerenciada de SQL e o token SAS. Tente regenerar o token SAS e estender a validade da janela de tempo do token para antes e depois da data atual.
- Ao iniciar várias restaurações do Log Replay em paralelo direcionando para 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, um nome de arquivo válido para o último arquivo de backup foi especificado?
- O caminho do URI de backup contém as palavras-chave
backupoubackups? Renomeie o contêiner ou as pastas que estão usandobackupoubackups, pois elas são palavras-chave reservadas.
Próximas etapas
- Saiba mais sobre Como migrar para a Instância Gerenciada de SQL do Azure usando o recurso de link.
- Saiba mais sobre Como migrar do SQL Server para a Instância Gerenciada de SQL do Azure.
- Saiba mais sobre As diferenças entre o SQL Server e a Instância Gerenciada de SQL.
- Saiba mais sobre as melhores práticas para custo e tamanho de cargas de trabalho migradas para o Azure.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de