Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aplica-se a:
Azure SQL Managed Instance
Este artigo compara o LRS (Log Replay Service) com o link Instância Gerenciada ao migrar para a Instância Gerenciada SQL do Azure.
Visão geral
O Log Replay Service (LRS) tem sido usado para migrações para a Instância Gerenciada SQL do Azure desde o lançamento do serviço em novembro de 2018. Nos bastidores, o LRS depende da implementação do envio de logs, que também habilita o DMS (Serviço de Migração de Banco de Dados do Azure) e a extensão de migração SQL do Azure para o Azure Data Studio.
Em março de 2022, o link Instância Gerenciada (link MI) foi introduzido como uma opção de migração com maior desempenho, com a promessa da melhor migração mínima possível. O link Instância Gerenciada usa a tecnologia de grupo de disponibilidade Always On distribuída para replicar dados quase em tempo real do SQL Server para a Instância Gerenciada SQL do Azure. Com o link, você também pode ficar online da Instância Gerenciada do SQL para o SQL Server 2022 ou posterior como uma apólice de seguro de migração.
O LRS e o link MI complementam-se em capacidades, com cada tecnologia a adequar-se a diferentes necessidades de negócio. Analise os recursos de cada ferramenta para determinar qual é a melhor a ser usada para migração com base em suas circunstâncias específicas.
Comparar LRS e MI link
A diferença fundamental entre o LRS e o link MI decorre da tecnologia subjacente. Como o LRS se baseia no envio de logs, os backups diferenciais e de log de transações são continuamente retirados do SQL Server, carregados no Armazenamento de Blobs do Azure e restaurados para a Instância Gerenciada do SQL. O processo não é em tempo real, pois leva tempo para fazer backup de arquivos, carregá-los e restaurá-los. O desempenho do LRS é baseado no tamanho das partes de backup.
Por outro lado, o link MI usa a tecnologia de grupo de disponibilidade Always On para enviar registos de log de transações praticamente em tempo real do SQL Server para o SQL Managed Instance, o que a torna uma solução de migração consideravelmente mais eficiente. No entanto, para configurar o link MI, necessita de configurar uma VPN entre o SQL Server e a Instância Gerida do SQL e abrir as portas apropriadas no firewall, enquanto que o LRS funciona logo à partida usando um endpoint público. O LRS pode ser usado para todas as edições do SQL Server 2008 e posteriores, enquanto o link MI pode ser usado para o SQL Server 2016 e posterior, apenas para as edições Standard, Enterprise e Developer.
Observação
O SQL Server 2025 introduz edições separadas para Desenvolvedores Empresariais e Desenvolvedores Padrão do SQL Server.
Um dos principais benefícios do link MI é a capacidade de executar uma migração reversa de volta para o SQL Server 2022 e posterior, o que não é possível com o LRS. Outro grande benefício da migração com o link MI é que o banco de dados na Instância Gerenciada SQL pode ser usado para cargas de trabalho somente leitura enquanto a migração está em andamento. Esse recurso não está disponível com o LRS, pois o banco de dados está em um estado de restauração até que a migração seja concluída. Da mesma forma, ao executar uma migração reversa de volta para o SQL Server 2022 e posterior, o banco de dados fica acessível para tarefas de leitura no SQL Server enquanto a migração está em andamento.
A tabela a seguir compara o link LRS e MI com mais detalhes:
| Funcionalidade | Link da instância gerenciada (link MI) | Serviço de Reprodução de Logs (LRS) | Notas |
|---|---|---|---|
| Tecnologia subjacente | Grupos de disponibilidade distribuída (AG) | Envio de logs | O link MI usa um grupo de disponibilidade distribuído para replicação, que é mais recente e avançado quando comparado à tecnologia de envio de logs usada pelo LRS. |
| Desempenho da replicação | Quase em tempo real. | Restaura a cada poucos minutos. | A replicação de dados por meio do link MI é consideravelmente mais eficiente do que a aplicação de backups de log de transações com o LRS. |
| Versão de origem mínima suportada | SQL Server 2016 e superior | SQL Server 2008 e superior | O LRS pode oferecer suporte a versões muito mais antigas do SQL Server do que o link MI. |
| Versão mínima suportada do Windows Server | Windows Server 2012 R2 | Windows Server 2008 | O LRS pode suportar versões muito mais antigas do Windows Server do que o link MI. |
| Secundário só de leitura | Suportado. | Não suportado. | Enquanto a replicação está em andamento, os bancos de dados da Instância SQL Gerida que são replicados por meio do link podem ser usados para cargas de trabalho somente leitura, permitindo-lhe testar a sua migração antes da transição ou usar as suas bases de dados antes de migrar para o Azure. Da mesma forma, ao executar uma migração reversa de volta para o SQL Server 2022 e posterior, o banco de dados fica acessível para tarefas de leitura no SQL Server enquanto a migração está em andamento. Esta capacidade não está disponível com o LRS. |
| Replicação de bancos de dados criptografados TDE | Sim, requer a importação de chaves de segurança para a Instância Gerenciada SQL. | Sim, requer a importação de chaves de segurança para a Instância Gerenciada SQL. | O requisito e o procedimento para migrar o certificado de criptografia correspondente do SQL Server para a instância gerenciada do SQL antes de iniciar a migração são os mesmos para ambas as opções de migração. |
| Tipo de conectividade de rede | - Ponto final privado - VPN configurada com portas de entrada e saída |
Ponto final público | Enquanto o link MI fornece camadas adicionais de segurança e oferece uma VPN como opção, a rede é mais difícil de configurar em comparação com o LRS. Por padrão, o LRS fornece uma experiência simplificada para que você possa usá-lo imediatamente sem qualquer configuração de rede ou VPN. O LRS usa um ponto de extremidade público por padrão, que é menos seguro do que a VPN usada com o link MI, e pode não satisfazer alguns dos requisitos de segurança mais exigentes, pois usa uma conta de armazenamento de Blob do Azure exposta publicamente como intermediário para salvar dados antes de serem restaurados para a Instância Gerenciada SQL. Embora seja possível usar um ponto de extremidade privado com LRS para tornar a transmissão de dados mais segura, isso aumenta a complexidade da configuração inicial. |
| Encriptação de dados na transmissão | - Dados encriptados com AES, e - SSL é usado para criptografia de transmissão de dados. |
SSL é usado para criptografia de transmissão de dados. | MI link usa uma camada de criptografia AES de dados adicionais. SSL é usado para transmissão de dados para ferramentas de migração. |
| Autenticação para a replicação | Certificados assinados por uma autoridade confiável (CA) | Identidades gerenciadas ou tokens SAS | O link MI requer uma Autoridade de Certificação (CA) para assinar um certificado para autenticação. Para o LRS, o uso de identidades gerenciadas é mais seguro do que o uso de tokens SAS gerados automaticamente. |
| Afetado por atualizações do sistema ou failover | Não, além de uma interrupção mínima para um failover curto. | - Para instâncias de uso geral, a migração é automaticamente pausada e retomada após interrupções. - Para instâncias críticas de negócios, o processo de migração é cancelado por interrupções e deve ser reiniciado manualmente. |
O link MI é resiliente e a migração não é afetada pelos failovers da Instância Gerenciada SQL. Por outro lado, as migrações LRS são atrasadas por reinicializações ou failovers de instâncias geridas por SQL no nível de serviço de Propósito Geral, e a migração é reiniciada para instâncias no nível de serviço Crítico para os Negócios. |
| Duração da replicação | Tempo de replicação ilimitado usando o link (meses e até anos de cada vez). | O trabalho LRS pode durar até 30 dias. | Um link MI pode manter-se ativo por um período ilimitado de tempo. O LRS é limitado a um máximo de 30 dias de envio contínuo de logs, após o qual a migração é interrompida automaticamente e precisa ser reiniciada desde o início. |
| Tipo de migração | Verdadeira migração online com apenas um curto failover (medido em segundos). | - Migração on-line com tempo de inatividade esperado durante a transferência para o tempo que leva para restaurar o último arquivo de backup. - A transição leva consideravelmente mais tempo para instâncias na camada de serviço Business Critical. |
O link MI é a única solução que oferece um tempo de indisponibilidade mínimo (<1 minuto) para todas as camadas de serviço da Instância Gerida SQL. Com o LRS, o último arquivo de backup ainda está sendo restaurado durante a substituição, portanto, com base no tamanho do último arquivo de backup e no tempo necessário para restaurá-lo, pode haver uma espera significativa até que o banco de dados fique disponível na Instância Gerenciada SQL. Ao usar o LRS para migrar para a camada de serviço Business Critical, o tempo de inatividade da transição pode ser significativamente maior, pois todo o banco de dados deve ser replicado para os nós secundários a partir do nó primário antes que o banco de dados esteja disponível para cargas de trabalho no nó primário. Dependendo do tamanho geral do banco de dados, a replicação para os outros nós e, portanto, o tempo de inatividade, às vezes pode levar horas. Como tal, as bases de dados podem ficar online consideravelmente mais lentamente com o LRS do que com a ligação MI, que pode ser quase instantânea. |
| Manutenção necessária na fonte | Sim, backups regulares de log de transações. | Não. | O link MI requer backups regulares do log de transações da instância do SQL Server de origem durante a migração para truncar o log de transações e evitar a falta de espaço em disco. Por outro lado, não é necessária manutenção para o LRS. |
| Resiliência | Retoma automaticamente a replicação de link se o SQL Server for reiniciado. | - A migração é interrompida se houver uma cadeia de backup quebrada ou um último arquivo de backup especificado incorretamente. - Não suporta arquivos de backup de vários bancos de dados na mesma pasta (falha na migração). |
O link MI é mais resiliente do que o LRS porque a replicação é retomada automaticamente após problemas (como tempo de inatividade inesperado, upgrades, perda de conectividade de rede e muitos outros) terem sido resolvidos. Além disso, o link MI é resistente a falhas de SQL Managed Instance ou atualizações de serviço. Certas condições resultam na estagnação do LRS. A migração LRS é reiniciada automaticamente se a migração para a camada de serviço de Propósito Geral for interrompida, mas precisa ser reiniciada se uma migração para a camada de serviço Crítica para os Negócios for interrompida. |
| Migração reversa do SQL MI de volta para o SQL Server | Há suporte para a migração offline e online de volta para o SQL Server 2022 e superior. | Não suportado. | O link MI é a única solução que oferece migração reversa online e offline para o SQL Server 2022 e versões posteriores - a migração reversa não está disponível para versões mais antigas do SQL Server. |
O que escolher?
A escolha entre LRS e o link MI depende de suas circunstâncias e necessidades de negócios. A diferença notável entre as soluções de migração é o desempenho. O LRS tem uma configuração inicial mais simples, que permite migrar rapidamente. Embora a configuração inicial do link MI seja mais complexa, ela oferece maior resiliência, segurança e flexibilidade.
Além disso, o tempo de transição é consideravelmente menor com a ligação MI, o que é uma vantagem significativa para muitos clientes. Na verdade, o tempo de inatividade potencialmente considerável ao migrar para a camada de serviço Business Critical com LRS é o motivo pelo qual o link MI é referido como a única migração "verdadeiramente online" para a camada de serviço Business Critical.
Por fim, se você precisar que seu banco de dados esteja acessível para cargas de trabalho somente leitura no destino de migração enquanto a migração estiver em andamento, ou se precisar executar uma migração reversa de volta para o SQL Server 2022 e posterior, o link MI será a única opção que oferece suporte a esses cenários.