Compartilhar via

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

  • Artigo

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

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

Para iniciar, confira Migrar bancos de dados do SQL Server para a Instância Gerenciada de SQL usando o Log Replay Service.

Quando usar o Serviço de Reprodução de Log

O Serviço de Migração de Banco de Dados do Azure, a extensão de migração SQL do Azure para o Azure Data Studio e o LRS usam as mesmas APIs e a mesma tecnologia de migração subjacentes. O LRS permite ainda mais migrações personalizadas complexas e arquiteturas híbridas entre as instâncias SQL Server locais e as implantações da Instância Gerenciada de 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 o PowerShell, cmdlets da CLI do Azure ou APIs para criar e orquestrar manualmente as migrações de banco de dados para a Instância Gerenciada do SQL.

Considere usar o LRS nos casos a seguir quando:

  • Você precisa de mais controle para seu projeto de migração de banco de dados.
  • Há pouca tolerância para tempo de inatividade durante a substituição da migração.
  • O arquivo executável do Serviço de Migração de Banco de Dados não pode ser instalado para seu ambiente.
  • O arquivo executável do Serviço de Migração de Banco de Dados não tem acesso a arquivos nos seus backups de banco de dados.
  • A extensão de migração SQL do Azure não pode ser instalada em seu ambiente ou não pode acessar seus backups de banco de dados.
  • Não houver acesso disponível ao sistema operacional do host ou aos privilégios de administrador.
  • Você não pode abrir as portas de rede do seu ambiente para o Azure.
  • Houver limitação da largura de banda da rede ou problemas de bloqueio do proxy em seu ambiente.
  • Os backups estiverem armazenados diretamente nas contas de Armazenamento de Blobs do Azure por meio da opção TO URL.
  • Você precisa usar backups diferenciais.

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)

Observação

  • É recomendável que você automatize a migração de bancos de dados do SQL Server para a Instância Gerenciada de SQL do Azure usando a extensão de migração SQL do Azure para Azure Data Studio. Considere usar o LRS para orquestrar migrações quando a extensão de migração SQL do Azure não der suporte completo aos seus cenários.
  • O LRS é o único método para restaurar backups diferenciais nas instâncias gerenciadas. Não é possível restaurar manualmente os backups diferenciais nas instâncias gerenciadas nem definir o modo NORECOVERY manualmente usando T-SQL.

Como funciona o LRS

Para criar uma solução personalizada para migrar bancos de dados para a nuvem com o LRS, são necessárias 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 os arquivos de backup para uma conta de Armazenamento de Blobs do Azure. Há suporte para backups completos, de log e diferenciais. Em seguida, use o serviço de nuvem do LRS para restaurar os arquivos de backup da conta de Armazenamento de Blobs do Azure para a Instância Gerenciada de SQL. A conta de Armazenamento de Blobs serve como armazenamento intermediário para arquivos de backup entre o SQL Server e a Instância Gerenciada do SQL.

O LRS monitora a conta de Armazenamento de Blobs em busca de novos backups diferenciais ou de logs que foram adicionados após a restauração do backup completo. 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 na Instância Gerenciada de 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 examina todos os arquivos colocados na conta de Armazenamento de Blobs do Azure e constrói a cadeia de backup por meio da leitura somente dos cabeçalhos de arquivos. Os bancos de dados ficam em um estado restaurando durante o processo de migração. Os bancos de dados são restaurados no modo NORECOVERY, portanto, eles não podem ser usados para leitura ou gravação de cargas até que o processo de migração termine.

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

  • Coloque os arquivos de backup de cada banco de dados em uma pasta separada na conta de Armazenamento de Blobs em uma estrutura de arquivo simples. Por exemplo, use pastas de banco de dados separadas: blobcontainer/database1/files, blobcontainer/database2/files e assim por diante.
  • Não use pastas aninhadas dentro de pastas de banco de dados, pois não há suporte para a estrutura de pastas aninhadas. Por exemplo, não use subpastas como blobcontainer/database1/subfolder/files.
  • Iniciar o LRS separadamente para cada banco de dados.
  • Indique diferentes caminhos de URI para separar as pastas de banco de dados na conta de Armazenamento de Blobs.

Embora não seja necessário, é altamente recomendável, ter o CHECKSUM habilitado para backups. A restauração de bancos de dados sem o CHECKSUM levará mais tempo, pois a Instância Gerenciada de SQL executa uma verificação de integridade nos backups que foram restaurados sem o CHECKSUM habilitado.

Para obter mais informações, confira Migrar bancos de dados do SQL Server para a Instância Gerenciada do SQL usando o Serviço de Reprodução de Log.

Cuidado

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

Comparação entre o preenchimento automático e a migração de modo contínuo

Você pode iniciar o LRS no modo de preenchimento automático ou contínuo.

Use o modo de preenchimento automático quando você tiver toda a cadeia de backup gerada com antecedência e não planeja adicionar mais arquivos depois do início da migração. Esse modo de migração é recomendado para cargas de trabalho passivas que não exigem atualização de dados. Carregue todos os arquivos de backup na conta de Armazenamento de Blobs e inicie a migração no modo de preenchimento automático. A migração será concluída automaticamente quando o último dos arquivos de backup especificados for restaurado. O banco de dados migrado ficará disponível para acesso de leitura/gravação na Instância Gerenciada de SQL.

Se você planeja continuar adicionando novos arquivos de backup enquanto a migração estiver em andamento, use o modo contínuo. Recomendamos esse modo para cargas de trabalho ativas que exigem atualização de dados. Carregue a cadeia de backup disponível no momento na conta de Armazenamento de Blobs, inicie a migração no modo contínuo e continue adicionando novos arquivos de backup da carga de trabalho conforme o necessário. O sistema vai verificar periodicamente a pasta do Armazenamento de Blobs do Azure e restaurar os novos logs ou arquivos de backup diferenciais que encontrar.

Quando estiver pronto para a substituição, interrompa a carga de trabalho da instância de SQL Server, gere o último arquivo de backup e carregue-o. Certifique-se de que o último arquivo de backup tenha sido restaurado, verificando se o backup final do log-tail é mostrado como restaurado na Instância Gerenciada de SQL. Depois, inicie a substituição manual. A etapa final da substituição faz com que o banco de dados fique online e disponível para acesso de leitura/gravação na Instância Gerenciada do SQL.

Depois que o LRS for interrompido, seja automaticamente por meio de preenchimento automático ou manualmente por meio de substituição, você não poderá retomar o processo de restauração de um banco de dados que foi colocado online na Instância Gerenciada de SQL. Por exemplo, depois que terminar a migração, não será mais possível restaurar backups diferenciais adicionais de um banco de dados online. Para restaurar mais arquivos de backup após o término da migração, precisará excluir o banco de dados da instância gerenciada e reiniciar a migração desde o início.

Fluxo de trabalho de migração

O fluxo de trabalho de migração típico é mostrado na imagem a seguir e as etapas são descritas na tabela.

Você precisa usar o modo de preenchimento automático quando todos os arquivos da cadeia de backup estão disponíveis antecipadamente. Recomendamos este modo para cargas de trabalho passivas que não exigem atualização de dados.

Use a migração de modo contínuo quando você não tem toda a cadeia de backup com antecedência e planeja adicionar novos arquivos de backup após a migração estiver em andamento. Recomendamos este modo para cargas de trabalho ativas que exigem atualização de dados.

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

Operação Detalhes
1. Copie os backups de banco de dados da instância do SQL Server para a conta de Armazenamento de Blobs. Copie backups completos, diferenciais e os log da instância do SQL Server para um contêiner de Armazenamento de Blobs usando o AzCopy ou o Gerenciador de Armazenamento do Azure.

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

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

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

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

Quando o LRS é iniciado no modo de preenchimento automático, ele restaura todos os backups por meio do último arquivo de backup especificado. Todos os arquivos de backup precisam ser carregados com antecedência e não é possível adicionar novos arquivos de backup enquanto a migração está em andamento. Esse modo é recomendado para cargas de trabalho passivas que não exigem atualização de dados.

Quando iniciado no modo contínuo, o LRS restaura todos os backups carregados inicialmente e, em seguida, observa os novos arquivos carregados na pasta. O serviço aplica logs continuamente com base na cadeia do LSN (número de sequência de log) até que seja interrompido manualmente. Recomendamos este modo para cargas de trabalho ativas que exigem atualização de dados.
2.1. Monitorar o progresso da operação. Você pode monitorar o progresso da operação de restauração com o PowerShell (get-azsqlinstancedatabaselogreplay) ou com a CLI do Azure (cmdlets az_sql_midb_log_replay_show).
2.2. Parar a operação se necessário (opcional). Se precisar parar o processo de migração, use o PowerShell (Stop-azsqlinstancedatabaselogreplay) ou a CLI do Azure (az_sql_midb_log_replay_stop).

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

Se o LRS foi iniciado no modo contínuo, interrompa o aplicativo e a carga de trabalho. Faça o último backup da parte final do log e carregue-o na implantação do Armazenamento de Blobs do Azure. Verifique na instância gerenciada se o último backup da parte final do log foi restaurado. Conclua a substituição iniciando uma operação complete no LRS com o PowerShell (Complete-azsqlinstancedatabaselogreplay) ou a CLI do Azure az_sql_midb_log_replay_complete. Essa operação interrompe o LRS e coloca o banco de dados online para cargas de trabalho de leitura/gravação na Instância Gerenciada de SQL.

Reponha a cadeia de conexão de aplicativos da instância do SQL Server para a Instância Gerenciada de SQL. Você precisa orquestrar essa etapa por conta própria com uma alteração manual da cadeia de conexão no aplicativo ou automaticamente (por exemplo, se o aplicativo puder ler a cadeia de conexão de uma propriedade ou de um banco de dados).

Importante

Após a transferência, a Instância Gerenciada de SQL com a camada de serviço Business Critical pode levar muito mais tempo do que a General Purpose para ficar disponível, pois três réplicas secundárias precisam ser semeadas para o grupo de disponibilidade. A duração da operação depende do tamanho dos dados. Para obter mais informações, confira Duração das operações de gerenciamento.

Migrando bancos de dados grandes

Se você estiver migrando bancos de dados grandes de vários terabytes, considere o seguinte:

  • Um só trabalho de LRS pode ser executado por um máximo de 30 dias. Quando esse período expira, o trabalho é cancelado automaticamente.
  • Em trabalhos de longa execução, as atualizações do sistema interromperão e prolongarão os trabalhos de migração. É altamente recomendável usar a 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 em instâncias gerenciadas de uso geral e reiniciados em instâncias gerenciadas comercialmente críticas. Essas atualizações afetarão o período da migração.
  • Para aumentar a velocidade de carregamento dos arquivos de backup do SQL Server para a conta do Armazenamento de Blobs, se houver largura de banda de rede suficiente na infraestrutura, considere usar a paralelização com vários threads.

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. Para obter detalhes específicos, confira Migrar com o LRS.

  • Modo de preenchimento automático. 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 conta do Armazenamento de Blobs do Azure.
    • Não permite adicionar novos arquivos de backup enquanto a migração está em andamento.
    • Requer que o comando start especifique o nome do último arquivo do backup.

    É recomendável usar o modo de preenchimento automático em cargas de trabalho passivas para as quais a atualização de dados não é necessária.

  • Modo contínuo. 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 a utilização do modo contínuo para cargas de trabalho ativas que exigem atualização de dados.

Planeje finalizar um único trabalho de migração LRS no máximo em 30 dias. Quando esse período expira, o trabalho de LRS é cancelado automaticamente.

Observação

Ao migrar vários bancos de dados, o LRS deverá ser iniciado separadamente para cada banco de dados que aponta para o caminho de URI completo do contêiner do Armazenamento de Blobs do Azure e a pasta de banco de dados individual.

Limitações do LRS

Considere as seguintes limitações do LRS:

  • Somente os arquivos dos banco de dados .bak, .log e .diff são suportados pelo LRS. Não há suporte para arquivos dacpac e bacpac.
  • Durante o processo de migração, os bancos de dados que estão sendo migrados não podem ser usados para o acesso somente leitura na Instância Gerenciada de SQL.
  • Você tem que configurar a janela de manutenção para permitir o agendamento de atualizações do sistema em um dia e hora específicos. Planeje executar e concluir as migrações fora da janela de manutenção agendada.
  • Os backups de banco de dados feitos sem CHECKSUM levam mais tempo para serem restaurados do que os bancos de dados com a CHECKSUM habilitada.
  • O token SAS (Assinatura de Acesso Compartilhado) que o LRS usa deve ser gerado para o contêiner completo do Armazenamento de Blobs do Azure e deve ter apenas permissões de Leitura e de Lista. Por exemplo, se você conceder as permissões Ler, Listar e Gravar, não será possível iniciar o LRS devido à permissão Gravar adicional.
  • No momento, não há suporte para o uso de tokens SAS criados com permissões definidas por meio da 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 de bancos de dados diferentes em pastas separadas do Armazenamento de Blobs em uma estrutura de arquivos simples. Não há suporte para pastas aninhadas dentro de pastas de banco de dados.
  • Se estiver usando o modo de preenchimento automático, toda a cadeia de backup precisará estar disponível com antecedência na conta do Armazenamento de Blobs do Azure. 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 banco de dados que aponta para o caminho completo de URI que contém uma pasta de banco 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 estas 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 dar suporte a até 100 processos de restauração simultâneos para cada instância gerenciada.
  • Um único trabalho do LRS pode ser executado por no máximo 30 dias. Após esse período ele será cancelado automaticamente.
  • Embora seja possível usar uma conta do Armazenamento do Azure com a proteção de um firewall, uma configuração extra é necessária, e a conta de armazenamento e a instância gerenciada precisam estar na mesma região ou em duas regiões emparelhadas. Confira Configurar firewall para saber mais.
  • O número máximo de bancos de dados que você pode restaurar em paralelo é 200 por assinatura única. Em alguns casos, é possível aumentar esse limite via tíquete de suporte.

Dica

Se você precisar que um banco de dados seja acessível somente leitura durante a migração, com um período de tempo muito mais longo para executar a migração e com tempo de inatividade mínimo, considere usar o recurso link da Instância Gerenciada de SQL do Azure como uma solução de migração recomendada.

Próximas etapas