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 que está disponível para a Instância Gerenciada de SQL do Azure e é baseado na tecnologia de envio de logs do SQL Server.

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 usando o Serviço de Reprodução de Log.

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

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

• SQL Server local/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

• É 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.

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 em andamento com o PowerShell (get-azsqlinstancedatabaselogreplay) ou com a CLI do Azure (cmdlets az_sql_midb_log_replay_show). 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 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 substituição, a Instância Gerenciada de SQL com a camada de serviço Comercialmente crítica pode levar significativamente mais tempo do que o Uso Geral para ficar disponível, pois três réplicas secundárias precisam ser propagadas 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 automaticamente suspensos e retomados para instâncias gerenciadas de Uso Geral e são reiniciados para instâncias gerenciadas Comercialmente crítica. 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, cada banco de dados deve estar na sua própria pasta. O LRS deve ser iniciado separadamente para cada banco de dados, apontando para o caminho completo do URI do contêiner de Armazenamento de Blobs do Azure e a pasta do 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, revise limitações ao usar o LRS.

Próximas etapas

• 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.

• Saiba mais sobre a migração de bancos de dados para a Instância Gerenciada de SQL usando o recurso de link.

• Saiba mais sobre migração de bancos de dados do SQL Server para a Instância Gerenciada do SQL .

• Saiba mais sobre as diferenças entre o SQL Server e a Instância Gerenciada de SQL.

• Saiba mais sobre as melhores práticas de custo e tamanho para cargas de trabalho migradas para o Azure.