Partilhar via

Visão geral do Serviço de Reprodução de Log com a Instância Gerida do Azure SQL

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

Este artigo fornece uma visão geral do Log Replay Service (LRS), que você pode usar para migrar bancos de dados do SQL Server para a Instância Gerenciada SQL do Azure. O LRS é um serviço de nuvem gratuito disponível para a Instância Gerenciada SQL do Azure e é baseado na tecnologia de envio de logs do SQL Server.

Observação

Agora você pode migrar sua instância do SQL Server habilitada pelo Azure Arc para a Instância Gerenciada do SQL do Azure diretamente por meio do portal do Azure. Para obter mais informações, consulte Migrar para a instância gerenciada SQL do Azure.

Como o LRS restaura arquivos de backup padrão do SQL Server, você pode usá-lo para migrar do SQL Server hospedado em qualquer lugar (local ou em qualquer nuvem) para a Instância Gerenciada SQL do Azure.

Para iniciar a migração com o LRS, revise Migrar bancos de dados do SQL Server usando o Serviço de Repetição de Log.

Importante

Antes de migrar bancos de dados para a camada de serviço Business Critical, considere essas limitações, que não se aplicam à camada de serviço de uso geral.

Quando usar o Log Replay Service

Serviço de Migração de Banco de Dados do Azure, a extensão de migração SQL do Azure para o Azure Data Studioe o LRS usam a mesma tecnologia de migração subjacente e APIs. O LRS permite ainda migrações personalizadas complexas e arquiteturas híbridas entre instâncias locais do SQL Server e implantações de Instância Gerenciada do SQL.

Quando não for possível usar o Serviço de Migração de Banco de Dados do Azure ou a extensão SQL do Azure para migração, você poderá usar o LRS diretamente com PowerShell, cmdlets da CLI do Azure ou APIs para criar e orquestrar manualmente migrações de banco de dados para a Instância Gerenciada do SQL.

Considere o uso do LRS nos seguintes casos:

  • Você precisa de mais controle para seu projeto de migração de banco de dados.
  • Há pouca tolerância ao tempo de inatividade durante a transferência de migração.
  • Não é possível instalar o arquivo executável do Serviço de Migração de Banco de Dados em seu ambiente.
  • O arquivo executável do Serviço de Migração de Banco de Dados não tem acesso aos backups do banco de dados.
  • Você não pode instalar a extensão de migração SQL do Azure em seu ambiente ou ela não pode acessar seus backups de banco de dados.
  • Você não tem acesso ao sistema operacional host ou aos privilégios de administrador.
  • Não é possível abrir portas de rede do seu ambiente para o Azure.
  • Existem problemas de limitação de rede ou bloqueio de proxy no seu ambiente.
  • Os backups são armazenados diretamente nas contas de Armazenamento de Blob do Azure por meio da opção TO URL.
  • Você precisa usar backups diferenciais.

Como o LRS funciona restaurando arquivos de backup padrão do SQL Server, ele oferece suporte a migrações de qualquer fonte. Foram testadas as seguintes fontes:

  • SQL Server local/em servidor
  • 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
  • Google Compute Engine
  • Cloud SQL para SQL Server - GCP (Google Cloud Platform)
  • Alibaba Cloud RDS para SQL Server

Se você encontrar problemas inesperados ao migrar de uma fonte não listada, abra um tíquete de suporte para obter assistência.

Observação

  • O LRS é o único método para restaurar backups diferenciais em instâncias gerenciadas pelo SQL. Não é possível restaurar manualmente backups diferenciais em instâncias gerenciadas ou definir manualmente o modo usando o NORECOVERY T-SQL.

Como funciona o LRS

A criação de uma solução personalizada para migrar bancos de dados para a nuvem com o LRS requer várias etapas de orquestração, conforme mostrado no diagrama e na tabela mais adiante nesta seção.

A migração consiste em fazer backups de banco de dados no SQL Server e copiar arquivos de backup para uma conta de Armazenamento de Blob do Azure. O LRS suporta backups completos, de log e diferenciais. Em seguida, use o serviço de nuvem LRS para restaurar arquivos de backup da conta de Armazenamento de Blob do Azure para a Instância Gerenciada do SQL. A conta de Armazenamento de Blob serve como armazenamento intermediário para arquivos de backup entre o SQL Server e a Instância Gerenciada do SQL.

O serviço LRS monitora a sua conta de Armazenamento de Blob em busca de quaisquer novos backups diferenciais ou de log que forem adicionados após a restauração de um backup completo. Em seguida, o LRS restaura automaticamente esses novos arquivos. Você pode usar o serviço para monitorar o progresso dos arquivos de backup que estão sendo restaurados para a Instância Gerenciada do SQL e interromper o processo, se necessário.

O LRS não requer uma convenção de nomenclatura específica para arquivos de backup. Ele verifica todos os arquivos colocados na conta de Armazenamento de Blob do Azure e constrói a cadeia de backup a partir da leitura apenas dos cabeçalhos de arquivo. Os bancos de dados estão em estado de restauro durante o processo de migração. O LRS restaura bancos de dados no modo NORECOVERY , para que não possam ser usados para cargas de trabalho de leitura ou gravação até que o processo de migração seja concluído.

Se estiver migrando vários bancos de dados, você precisará:

  • Coloque os arquivos de backup de cada banco de dados em uma pasta separada na conta de Armazenamento de Blob em uma estrutura de arquivo simples. Por exemplo, use pastas de banco de dados separadas: blobcontainer/database1/files, blobcontainer/database2/filese assim por diante.
  • Não use pastas aninhadas dentro de pastas de banco de dados, porque a estrutura de pastas aninhadas não é suportada. Por exemplo, não use subpastas como blobcontainer/database1/subfolder/files.
  • Inicie o LRS separadamente para cada base de dados.
  • Especifique caminhos de URI diferentes para separar pastas de banco de dados na conta de Armazenamento de Blob.

Embora não seja necessário ter CHECKSUM ativado para backups, é altamente recomendável fazê-lo. A restauração de bancos de dados sem CHECKSUM leva mais tempo, porque a Instância Gerenciada SQL executa uma verificação de integridade em backups que são restaurados sem CHECKSUM habilitados.

Para obter mais informações, consulte Migrar bancos de dados do SQL Server usando o Log Replay Service.

Atenção

Fazer backups no SQL Server com CHECKSUM habilitado é altamente recomendado, pois há um risco de restaurar um banco de dados corrompido para o Azure sem ele.

Migração de modo autocompletar versus modo contínuo

Pode iniciar o LRS no modo de preenchimento automático () ou no modo contínuo ().

Use o modo de preenchimento automático quando toda a cadeia de backup for gerada com antecedência e quando não planejar adicionar mais arquivos após o início da migração. Esse modo de migração é recomendado para cargas de trabalho passivas que não exigem recuperação de dados. Carregue todos os arquivos de backup para a conta de armazenamento de Blob e inicie a migração do modo de preenchimento automático. A migração é concluída automaticamente quando o último arquivo de backup especificado é restaurado. O banco de dados migrado fica disponível para acesso de leitura/gravação na Instância Gerenciada SQL.

Se tiveres planos de continuar a adicionar novos arquivos de backup enquanto a migração está em andamento, usa o modo contínuo. Recomendamos esse modo para cargas de trabalho ativas que exigem atualização de dados. Carregue a cadeia de backup atualmente disponível para a conta de armazenamento de Blob, inicie a migração no modo contínuo e continue adicionando novos arquivos de backup de sua carga de trabalho, conforme necessário. O sistema verifica periodicamente a pasta Armazenamento de Blobs do Azure e restaura quaisquer novos arquivos de log ou de backup diferencial encontrados.

Quando estiver pronto para a substituição, pare a carga de trabalho na instância do SQL Server, gere o último arquivo de backup e carregue-o. Verifique se o último arquivo de backup foi restaurado verificando se o backup final de log-tail é mostrado como restaurado na Instância Gerenciada do SQL. Em seguida, inicie a transição manual. A etapa de transferência final coloca o banco de dados online e o torna disponível para acesso de leitura e escrita na Instância Gerenciada SQL.

Depois que o LRS é interrompido, automaticamente por meio do preenchimento automático ou manualmente por substituição, você não pode retomar o processo de restauração de um banco de dados que você colocou online na Instância Gerenciada SQL. Por exemplo, após a conclusão da migração, você não poderá mais restaurar backups diferenciais para um banco de dados online. Para restaurar mais arquivos de backup após a conclusão da migração, você precisa excluir o banco de dados da instância gerenciada e reiniciar a migração desde o início.

Fluxo de trabalho de migração

A imagem nesta seção mostra um fluxo de trabalho de migração típico enquanto a tabela descreve as etapas.

Use o modo de preenchimento automático somente quando todos os arquivos da cadeia de backup estiverem disponíveis antecipadamente. Recomendamos esse modo para cargas de trabalho passivas que não exigem atualização de dados.

Use a migração em modo contínuo quando não tiver toda a cadeia de backup com antecedência e quando planejar adicionar novos arquivos de backup depois que a migração estiver em andamento. Recomendamos esse modo para cargas de trabalho ativas que exigem atualização de dados.

Diagrama que ilustra as etapas de orquestração do Serviço de Repetição de Log para a Instância Gerenciada SQL.

Funcionamento Detalhes
1. Copie cópias de segurança da base de dados da instância do SQL Server para a conta de Armazenamento Blob. Copie backups completos, diferenciais e de log da instância do SQL Server para o contentor Blob Storage usando AzCopy ou Azure Storage Explorer.

Use qualquer nome de arquivo. O LRS não requer uma convenção específica de nomenclatura de arquivos.

Use uma pasta separada para cada banco de dados ao migrar vários bancos de dados.
2. Inicie o LRS na nuvem. Inicie o serviço com o PowerShell (start-azsqlinstancedatabaselogreplay) ou a CLI do Azure (az_sql_midb_log_replay_start cmdlets). Escolha entre o modo de preenchimento automático ou o modo de migração contínua.

Inicie o LRS separadamente para cada base de dados que aponta para uma pasta de backup na conta de Armazenamento Blob.

Depois que o serviço é iniciado, ele faz backups do contêiner de Armazenamento de Blob e começa a restaurá-los para a Instância Gerenciada do SQL.

Quando você inicia o LRS no modo de preenchimento automático, ele restaura todos os backups através do último arquivo de backup especificado. Você deve carregar todos os arquivos de backup com antecedência e não pode adicionar novos arquivos de backup enquanto a migração estiver em andamento. Esse modo é recomendado para cargas de trabalho passivas que não exigem recuperação de dados.

Quando você inicia o LRS no modo contínuo, ele restaura todos os backups que você carregou inicialmente e, em seguida, observa se há novos arquivos que você carrega para a pasta. O serviço aplica continuamente logs com base na cadeia de número de sequência de log (LSN) até que seja interrompido manualmente. Recomendamos esse modo para cargas de trabalho ativas que exigem atualização de dados.
2.1. Monitorizar o progresso da operação. Monitore o progresso da operação de restauração em andamento com o PowerShell (get-azsqlinstancedatabaselogreplay) ou a CLI do Azure (cmdlets az_sql_midb_log_replay_show). Para monitorizar detalhes adicionais sobre uma solicitação com falha, use o comando PowerShell Get-AzSqlInstanceOperation ou o comando Azure CLI az sql mi op show.
2.2. Pare a operação, se necessário (opcional). Se você precisar interromper o processo de migração, use o PowerShell (stop-azsqlinstancedatabaselogreplay) ou a CLI do Azure (az_sql_midb_log_replay_stop).

A interrupção da operação exclui o banco de dados que você está restaurando para a Instância Gerenciada do SQL. Depois de parar uma operação, não é possível retomar o LRS para um banco de dados. Você precisa reiniciar o processo de migração desde o início.
3. Migre para a nuvem quando estiver pronto. Se você iniciar o LRS no modo de preenchimento automático, a migração será concluída automaticamente depois que o último arquivo de backup especificado for restaurado.

Se você iniciar o LRS no modo contínuo, interrompa o aplicativo e a carga de trabalho. Faça o último backup de cauda de log e carregue-o na implementação do Azure Blob Storage. Certifique-se de que o último backup da cauda de log seja restaurado na instância gerida pelo SQL. Conclua a transição iniciando uma operação LRS complete com o PowerShell (complete-azsqlinstancedatabaselogreplay) ou com a Azure CLI az_sql_midb_log_replay_complete. Esta operação interrompe o LRS e coloca o banco de dados online para cargas de trabalho de leitura/gravação na Instância Gerenciada SQL.

Redirecione a cadeia de ligação da aplicação da instância do SQL Server para a Instância Gerida do SQL. Você mesmo precisa orquestrar essa etapa, seja por meio de uma alteração manual da cadeia de conexão em seu aplicativo ou automaticamente (por exemplo, se seu aplicativo puder ler a cadeia de conexão de uma propriedade ou de um banco de dados).

Importante

Após a transição, a Instância Gerenciada SQL com camada de serviço Crítica para Negócios pode levar significativamente mais tempo do que de Uso Geral para estar disponível, pois três réplicas secundárias precisam ser inicializadas para o grupo de disponibilidade. A duração da operação depende do tamanho dos dados. Para obter mais informações, consulte Duração das operações de gestão.

Migrar bancos de dados grandes

Se você estiver migrando bancos de dados grandes de vários terabytes de tamanho, considere os seguintes pontos:

  • Um único trabalho LRS pode ser executado por um máximo de 30 dias. Quando este período expira, o trabalho é automaticamente cancelado.
  • Para trabalhos de longa duração, as atualizações do sistema podem interromper e prolongar os trabalhos de migração. É altamente recomendável que você use uma janela de manutenção para agendar atualizações planejadas do sistema. Planeje sua migração em torno da janela de manutenção agendada.
  • Os trabalhos de migração interrompidos por atualizações do sistema são suspensos e retomados automaticamente para instâncias geridas SQL de uso geral e são reiniciados para instâncias geridas SQL de Importância Crucial para o Negócio. Essas atualizações afetam o período de migração.
  • Para aumentar a velocidade de carregamento dos arquivos de backup do SQL Server para a conta de Armazenamento de Blob, se sua infraestrutura tiver largura de banda de rede suficiente, considere o uso de paralelização com vários threads.

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. Para obter detalhes específicos, consulte Migrar bases de dados do SQL Server usando o Serviço de Reprodução de Registos.

  • modo de conclusão automática. Quando você usa o modo de preenchimento automático, a migração é concluída automaticamente quando o último dos arquivos de backup especificados é restaurado. Esta opção:

    • Requer que toda a cadeia de backup esteja disponível com antecedência e carregada na conta de Armazenamento de Blob do Azure.
    • Não permite adicionar novos arquivos de backup enquanto a migração está em andamento.
    • Requer o comando start para especificar o nome do arquivo do último arquivo de backup.

    Recomendamos o uso do modo de preenchimento automático para cargas de trabalho passivas para as quais a recuperação de dados não é necessária.

  • Modo contínuo. 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 adicionados enquanto a migração está em andamento.

    A migração só é concluída depois de ser solicitado o corte manual.

    Use a migração em modo contínuo quando não tiver toda a cadeia de backup com antecedência e quando planejar adicionar novos arquivos de backup depois que a migração estiver em andamento.

    Recomendamos o uso do modo contínuo 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 este período expira, o trabalho LRS é automaticamente cancelado.

Observação

Ao migrar vários bancos de dados, cada banco de dados deve estar em sua própria pasta. Inicie o LRS separadamente para cada banco de dados, apontando para o caminho de URI completo do contêiner de Armazenamento de Blobs do Azure e para a pasta de banco de dados individual. Não há suporte para pastas aninhadas dentro de pastas de banco de dados.

Limitações do LRS

Para obter informações, consulte as limitações ao usar o LRS.

Conteúdo relacionado