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

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

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

Para começar, revise Migrar bancos de dados do SQL Server para a Instância Gerenciada SQL do Azure usando o Serviço de Repetição de Log.

Quando usar o Log Replay Service

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 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, quando:

• 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.
• O arquivo executável do Serviço de Migração de Banco de Dados não pode ser instalado 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.
• 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.
• Nenhum acesso ao sistema operacional host está disponível ou não há 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 do Armazenamento de Blob do Azure por meio da TO URL opção.
• Você precisa usar backups diferenciais.

São suportadas as seguintes origens:

• 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
• Mecanismo de computação do Google
• Cloud SQL para SQL Server - GCP (Google Cloud Platform)

Nota

• Recomendamos que você automatize a migração de bancos de dados do SQL Server para a Instância Gerenciada SQL do Azure usando a extensão de migração do SQL do Azure para o Azure Data Studio. Considere usar o LRS para orquestrar migrações quando a extensão de migração SQL do Azure não oferecer suporte total aos seus cenários.
• O LRS é o único método para restaurar backups diferenciais em instâncias gerenciadas. 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. São suportadas cópias de segurança diferenciais, completas e de registo. 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 LRS monitora sua conta de armazenamento de Blob para quaisquer novos backups diferenciais ou de log que sejam adicionados após a restauração do backup completo. O LRS restaura automaticamente esses novos ficheiros. 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 os ficheiros de cópias de segurança. 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. As bases de dados ficam no estado de restauro durante o processo de migração. Os bancos de dados são restaurados no modo NORECOVERY , portanto, 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 estiver a migrar várias bases de dados:

• 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/files e 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 em separado 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. A restauração de bancos de dados sem demora mais tempo, porque a Instância Gerenciada SQL executa uma verificação de integridade em backups que são restaurados sem CHECKSUM CHECKSUM habilitação.

Para obter mais informações, consulte Migrar bancos de dados do SQL Server para a instância gerenciada do SQL 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 automático versus 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 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 será concluída automaticamente quando o último arquivo de backup especificado tiver sido restaurado. O banco de dados migrado ficará disponível para acesso de leitura/gravação na Instância Gerenciada SQL.

Se você planeja continuar adicionando novos arquivos de backup enquanto a migração está em andamento, use o modo contínuo . Recomendamos este modo para cargas de trabalho ativas que necessitam da 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 verificará periodicamente a pasta Armazenamento de Blobs do Azure e restaurará qualquer novo log ou arquivos 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. Certifique-se de que 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 substituição manual. A etapa de transferência final torna o banco de dados online e disponível para acesso de leitura/gravação na Instância Gerenciada SQL.

Depois que o LRS for interrompido, seja automaticamente por meio do preenchimento automático ou manualmente por 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 do 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

Um 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 somente quando todos os arquivos da cadeia de backup estiverem disponíveis com antecedência. Recomendamos esse modo para cargas de trabalho passivas para as quais não é necessária a recuperaçã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 para as quais a recuperação de dados é necessária.

Operação	Detalhes
1. Copie backups de banco de dados da instância do SQL Server para a conta de Armazenamento de Blob.	Copie backups completos, diferenciais e de log da instância do SQL Server para o contêiner de Armazenamento de Blob 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.	Você pode iniciar o serviço com o PowerShell (start-azsqlinstancedatabaselogreplay) ou a CLI do Azure (cmdlets az_sql_midb_log_replay_start). Escolha entre o modo de preenchimento automático ou o modo de migração contínua. Inicie o LRS separadamente para cada banco de dados que aponta para uma pasta de backup na conta de Armazenamento de 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 o LRS é iniciado no modo de preenchimento automático, ele restaura todos os backups através do último arquivo de backup especificado. Todos os arquivos de backup devem ser carregados com antecedência e não é possível adicionar novos arquivos de backup enquanto a migração está em andamento. Este modo é recomendado para cargas de trabalho passivas para as quais não é necessária uma atualização dos dados. Quando o LRS é iniciado no modo contínuo, ele restaura todos os backups que foram inicialmente carregados e, em seguida, observa se há novos arquivos que foram carregados 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 para as quais a recuperação de dados é necessária.
2.1. Monitorizar o progresso da operação.	Você pode monitorar o progresso da operação de restauração com o PowerShell (get-azsqlinstancedatabaselogreplay) ou a CLI do Azure (cmdlets az_sql_midb_log_replay_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. Corte para a nuvem quando estiver pronto.	Se o LRS tiver sido iniciado 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 o LRS foi iniciado no modo contínuo, interrompa o aplicativo e a carga de trabalho. Pegue o último backup de cauda de log e carregue-o para a implantação do Armazenamento de Blob do Azure. Verifique se o último backup de log-tail foi restaurado na instância gerenciada. Conclua a substituição iniciando uma operação LRS com o PowerShell (complete-azsqlinstancedatabaselogreplay) ou a CLI do Azure az_sql_midb_log_replay_complete.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. Reaponte a cadeia de conexão do aplicativo da instância do SQL Server para a Instância Gerenciada 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).

Migrando bancos de dados grandes

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

• 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 execução, as atualizações do sistema interromperão e prolongarão 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 automaticamente suspensos e retomados para instâncias gerenciadas de uso geral e são reiniciados para instâncias gerenciadas críticas para os negócios. Essas atualizações afetarão o período de tempo da 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 com LRS.

• 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 tiver sido 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ó termina após a substituição manual ter sido solicitada.

  Você precisa usar a migração em modo contínuo quando não tiver toda a cadeia de backup com antecedência e quando planeja 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.

Nota

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

Limitações do LRS

Considere as seguintes limitações do LRS:

• Apenas a base de dados .bak, .loge .diff os ficheiros são suportados pelo LRS. Os ficheiros Dacpac e bacpac não são suportados.
• Durante o processo de migração, os bancos de dados que estão sendo migrados não podem ser usados para acesso somente leitura na Instância Gerenciada SQL.
• Você tem que configurar uma janela de manutenção para permitir o agendamento de atualizações do sistema em um dia e hora específicos. Planeje executar e concluir migrações fora da janela de manutenção agendada.
• Os backups de banco de dados que são feitos sem CHECKSUM levar mais tempo para restaurar do que os backups de banco de dados habilitados CHECKSUM .
• O token de assinatura de acesso compartilhado (SAS) que o LRS usa deve ser gerado para todo o contêiner de Armazenamento de Blob do Azure e deve ter somente permissões de Leitura e Lista. Por exemplo, se você conceder permissões de Leitura, Lista e Gravação, o LRS não poderá ser iniciado devido à permissão de Gravação extra.
• Não há suporte para o uso de tokens SAS criados com permissões definidas por meio da definição de uma política de acesso armazenado. 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 para diferentes bancos de dados em pastas separadas na conta de Armazenamento de Blob em uma estrutura de arquivo simples. Não há suporte para aninhamento de pastas dentro de pastas de banco de dados.
• Se você estiver usando o modo de preenchimento automático, toda a cadeia de backup precisa estar disponível com antecedência na conta de Armazenamento de Blob. 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 URI completo 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 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 suportar até 100 processos de restauração simultâneos por única instância gerenciada.
• Um único trabalho LRS pode ser executado por um máximo de 30 dias, após os quais será automaticamente cancelado.
• Embora seja possível usar uma conta de Armazenamento do Azure atrás de um firewall, é necessária uma configuração extra e a conta de armazenamento e a instância gerenciada devem estar na mesma região ou em duas regiões emparelhadas. Consulte Configurar firewall para saber mais.

Gorjeta

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

Próximos passos

• Para obter mais informações, consulte Migrar bancos de dados do SQL Server para a instância gerenciada do SQL usando o Log Replay Service.

• Saiba mais sobre como migrar bancos de dados para a Instância Gerenciada SQL usando o recurso de link.

• Saiba mais sobre como migrar 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 do SQL.

• Saiba mais sobre as práticas recomendadas para custear e dimensionar cargas de trabalho que são migradas para o Azure.