Compartilhar via

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

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 disponível para a Instância Gerenciada de SQL do Azure e se baseia 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 de SQL do Azure diretamente por meio do portal do Azure. Para obter mais informações, consulte Migrar para a Instância Gerenciada de 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 de SQL do Azure.

Para iniciar a migração com o LRS, examine Migrar bancos de dados do SQL Server usando o Serviço de Reprodução de Logs.

Importante

Antes de migrar bancos de dados para a camada de serviço Comercialmente crítica, considere estas limitações, que não se aplicam à camada de serviço Uso Geral.

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

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 o uso de LRS nos seguintes casos:

  • 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.
  • 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 a arquivos nos seus backups de banco de dados.
  • Você não pode instalar a extensão de migração do 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 privilégios de administrador.
  • Você não pode abrir as portas de rede do seu ambiente para o Azure.
  • Problemas de limitação de rede ou bloqueio de proxy existem em seu ambiente.
  • Os backups são armazenados diretamente nas contas do Azure Blob Storage através da opção TO URL.
  • Você precisa usar backups diferenciais.

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

  • SQL Server instalado localmente/box
  • 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)
  • 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 de SQL. Não é possível restaurar manualmente backups diferenciais em instâncias gerenciadas ou definir manualmente o NORECOVERY modo usando o 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. O LRS dá suporte a backups completos, de logs 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 sua conta de Armazenamento de Blobs para quaisquer novos backups diferenciais ou de log que forem adicionados depois que o backup completo for restaurado. 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. O LRS restaura bancos de dados no modo NORECOVERY , portanto, eles não podem ser usados para cargas de trabalho de leitura ou gravação até que o processo de migração seja concluído.

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, consulte Migrar bancos de dados do SQL Server usando o Serviço de Reprodução de Logs.

Cuidado

Fazer backups no SQL Server com CHECKSUM habilitado é altamente recomendável, pois há um 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 quando não planeja 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 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 é 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 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 escaneia periodicamente a pasta de Armazenamento de Blobs do Azure e restaura qualquer log novo ou arquivo de backup diferencial encontrado.

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. Verifique se o último arquivo de backup foi 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 transição faz com que o banco de dados fique online e disponível para leitura e gravação na Instância Gerenciada de SQL.

Depois que o LRS for interrompido, automaticamente por meio do 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 você fez 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

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 de cadeia de backup estiverem disponíveis com antecedência. 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 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 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. Inicie 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 inicia, ele obtém os backups do contêiner de Armazenamento Blob e começa a restaurá-los na Instância Gerenciada do SQL.

Quando você inicia o LRS no modo de preenchimento automático, ele restaura todos os backups por meio 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 atualizaçã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 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 esse modo para cargas de trabalho ativas que exigem atualização de dados.
2.1. Monitorar o progresso da operação. Monitore o progresso da operação de restauração em andamento com o PowerShell (get-azsqlinstancedatabaselogreplay) ou com o Azure CLI (az_sql_midb_log_replay_show cmdlets). Para acompanhar detalhes adicionais sobre uma solicitação com falha, use o comando Get-AzSqlInstanceOperation do PowerShell ou use o comando az sql mi op show da CLI do Azure.
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 você iniciar o LRS no modo de preenchimento automático, a migração será concluída automaticamente após a restauração do último arquivo de backup especificado.

Se você iniciar o LRS 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 se o último backup de log-tail foi restaurado na instância gerenciada de SQL. 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 transição, a Instância Gerenciada de SQL com o nível de serviço Business Critical pode levar significativamente mais tempo para ficar disponível do que a General Purpose, 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, confira Duração das operações de gerenciamento.

Migrar bancos de dados grandes

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

  • Uma única tarefa de LRS pode ser executada por no máximo 30 dias. Quando esse período expira, o trabalho é cancelado automaticamente.
  • Para trabalhos de execução prolongada, as atualizações do sistema podem interromper e prolongar 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.
  • Trabalhos de migração interrompidos por atualizações do sistema são automaticamente suspensos e retomados para instâncias gerenciadas de SQL de Uso Geral, e são reiniciados para instâncias gerenciadas de SQL Criticamente Importante. Essas atualizações afetam o período de tempo 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, verifique Migrar bancos de dados do SQL Server usando o Serviço de Reprodução de Logs.

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

    • Exige que toda a cadeia de backup esteja disponível antecipadamente e seja carregada na conta do Azure Blob Storage.
    • 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 é concluída somente depois que você solicita o corte manual.

    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 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, cada banco de dados deve estar na sua própria pasta. Inicie o LRS separadamente para cada banco de dados, apontando para o caminho de URI completo do contêiner do Armazenamento Blob do Azure e para a pasta individual do banco de dados. Não há suporte para pastas aninhadas dentro de pastas de banco de dados.

Limitações do LRS

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

Conteúdo relacionado

  • Last updated on