Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a:Instância Gerenciada de SQL do Azure
Este artigo compara o LRS (Serviço de Reprodução de Log) com o link da Instância Gerenciada ao migrar para a Instância Gerenciada de SQL do Azure.
Visão geral
O LRS (Serviço de Reprodução de Logs) tem sido usado para migrações para a Instância Gerenciada de SQL do Azure desde que o serviço foi iniciado em novembro de 2018. Sob o capô, o LRS depende da implementação do envio de logs, que também alimenta o DMS (Serviço de Migração de Banco de Dados do Azure) e a extensão de migração do SQL do Azure para o Azure Data Studio.
Em março de 2022, o link MI foi introduzido como uma opção de migração mais eficiente, com a promessa da melhor migração possível com tempo de inatividade mínimo. O link da Instância Gerenciada usa a tecnologia do grupo de disponibilidade Always On distribuído para replicar quase em tempo real os dados do SQL Server para a Instância Gerenciada de SQL do Azure. Com o link, você também pode retornar online da Instância Gerenciada SQL para o SQL Server 2022 ou posterior como garantia de migração.
O LRS e o link de MI se complementam em funcionalidades, com cada tecnologia que atenda às diferentes necessidades de negócios. Examine os recursos de cada ferramenta para determinar qual é o melhor a ser usado para migração com base em suas circunstâncias específicas.
Comparar o link LRS e MI
A diferença fundamental entre o LRS e o link de MI decorre da tecnologia subjacente. Como o LRS é baseado no envio de logs, backups diferenciais e de log de transações são continuamente feitos a partir do SQL Server, carregados para o Armazenamento de Blobs do Azure e restaurados na Instância Gerenciada de 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 registros de log de transações quase em tempo real do SQL Server para a Instância Gerenciada de SQL, tornando-a uma solução de migração consideravelmente mais eficaz. No entanto, para configurar o vínculo MI, você precisa estabelecer uma VPN entre o SQL Server e a Instância Gerenciada de SQL e abrir as portas apropriadas no firewall, enquanto o LRS funciona prontamente usando um ponto de extremidade 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 apenas para o SQL Server 2016 e posterior para edições Standard, Enterprise e Developer.
Observação
O SQL Server 2025 Preview apresenta edições separadas do Enterprise Developer e do Standard Developer 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 de SQL pode ser usado para cargas de trabalho de somente leitura enquanto a migração está em andamento. Essa funcionalidade não está disponível com LRS, pois o banco de dados está em um estado de restauração até que a migração seja concluída. Da mesma forma, quando você executa uma migração reversa de volta para o SQL Server 2022 e posterior, o banco de dados fica acessível para cargas de trabalho somente 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) | LRS (Serviço de Reprodução de Log) | Observações |
---|---|---|---|
Tecnologia subjacente | AG (grupos de disponibilidade distribuídos) | Envio de logs | O link mi usa um grupo de disponibilidade distribuído para replicação, que é mais recente e avançado quando comparado com a tecnologia de envio de logs usada pelo LRS. |
Desempenho da replicação | Quase em tempo real. | Restaura a cada alguns minutos. | Replicar dados por meio do link mi é consideravelmente mais eficaz do que aplicar backups de log de transações com LRS. |
Versão de origem mínima com suporte | SQL Server 2016 e superior | SQL Server 2008 e superior | O LRS pode dar suporte a versões muito mais antigas do SQL Server do que o link do MI. |
Versão mínima do Windows Server com suporte | Windows Server 2012 R2 | Windows Server 2008 | O LRS pode dar suporte a versões muito mais antigas do Windows Server do que o MI link. |
Secundário de apenas leitura | Suportado. | Não há suporte. | Enquanto a replicação está em andamento, os bancos de dados da Instância Gerenciada de SQL replicados por meio do link podem ser usados para cargas de trabalho de leitura. Isso permite testar sua migração antes da transição ou utilizar seus bancos de dados antes de migrar para o Azure. Da mesma forma, quando você executa uma migração reversa de volta para o SQL Server 2022 e posterior, o banco de dados fica acessível para cargas de trabalho somente leitura no SQL Server enquanto a migração está em andamento. Essa funcionalidade não está disponível com LRS. |
Replicação de bancos de dados criptografados TDE | Sim, requer a importação de chaves de segurança para a Instância Gerenciada de SQL. | Sim, requer a importação de chaves de segurança para a Instância Gerenciada de SQL. | O requisito e o procedimento para migrar o certificado de criptografia correspondente do SQL Server para a instância gerenciada de SQL antes de iniciar a migração é o mesmo para ambas as opções de migração. |
Tipo de conectividade de rede | - Ponto de extremidade privado – VPN configurada com portas de entrada e de saída |
Ponto de extremidade público | Embora o link mi forneça camadas adicionais de segurança e ofereça uma VPN como uma 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á-la imediatamente sem nenhuma 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 atender a alguns dos requisitos de segurança mais exigentes, pois utiliza uma conta de armazenamento de Blobs do Azure exposta publicamente como intermediário para armazenar dados temporariamente antes de serem restaurados na Instância Gerenciada de 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. |
Criptografia de dados na transmissão | - Dados criptografados com o AES e - O SSL é usado para criptografia de transmissão de dados. |
O SSL é usado para criptografia de transmissão de dados. | O MI link usa uma camada adicional de criptografia AES de dados. O SSL é usado para transmissão de dados para ferramentas de migração. |
Autenticação para a replicação | Certificados assinados por uma autoridade certificadora confiável (CA) | Identidades gerenciadas ou tokens SAS | O link MI requer uma CA (Autoridade de Certificação) para assinar um certificado para autenticação. Para LRS, o uso de identidades gerenciadas é mais seguro do que usar tokens SAS autogeridos. |
Afetado por atualizações do sistema ou failover | Não, exceto por uma interrupção mínima para um breve failover. | - Para instâncias de Uso Geral, a migração é pausada automaticamente e retomada após interrupções. - Para instâncias criticamente importantes para os negócios, o processo de migração é cancelado em caso de interrupções e deve ser reiniciado manualmente. |
O link MI é resiliente e a migração não é impactada por failovers da Instância Gerenciada de SQL. Por outro lado, as migrações LRS são atrasadas por reinicializações ou failovers de instâncias gerenciadas de SQL na camada de serviço de Uso Geral e a migração é reiniciada para instâncias na camada de serviço Comercialmente Crítico. |
Duração da replicação | Tempo de replicação ilimitado usando o link (meses e até anos de cada vez). | Um trabalho LRS pode ser executado por até 30 dias. | Um link MI pode funcionar por um período ilimitado de tempo. O LRS é limitado ao 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 | Migração online verdadeira com apenas um failover curto (medido em segundos). | – Migração online com tempo de inatividade esperado durante a transição, pelo tempo necessário para restaurar o último arquivo de backup. – A substituição leva consideravelmente mais tempo para instâncias na camada de serviço Comercialmente Crítico. |
O link MI é a única solução que oferece um tempo de inatividade mínimo (<1 minuto) para todas as camadas de serviço da Instância Gerenciada de 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 de SQL. Ao usar o LRS para migrar para a camada de serviço Essencial para os Negócios, o tempo de inatividade durante a migração pode ser significativamente maior, pois todo o banco de dados deve ser replicado dos nós primário para os nós secundários 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. Dessa forma, os bancos de dados podem se tornar online de forma consideravelmente mais lenta com o LRS do que com o link MI, que pode ser quase instantâneo. |
Manutenção necessária na origem | Sim, backups regulares de log de transações. | Não. | O link MI requer backups regulares de log de transação da instância do SQL Server de origem durante a migração para truncar o log de transação e prevenir o esgotamento do espaço em disco. Por outro lado, nenhuma manutenção é necessária para LRS. |
Resiliência | Retomará automaticamente a replicação de link se o SQL Server for reiniciado. | – A migração para se houver uma cadeia de backups quebrada ou se o último arquivo de backup estiver especificado incorretamente. - Não dá suporte a arquivos de backup de vários bancos de dados na mesma pasta (a migração falha). |
O link mi é mais resiliente do que o LRS porque a replicação é retomada automaticamente após problemas (como tempo de inatividade inesperado, atualizações, perda de conectividade de rede e muitos outros) terem sido resolvidos. Além disso, o link MI é resiliente a falhas do SQL MI ou atualizações de serviço. Determinadas condições resultam em paralisação de LRS. A migração de LRS será reiniciada automaticamente se a migração para a camada de serviço de Uso Geral for interrompida, mas precisar ser reiniciada se uma migração para a camada de serviço Comercialmente Crítico for interrompida. |
Migração reversa do SQL MI de volta para o SQL Server | Há suporte para a migração offline e online para o SQL Server 2022 e superior. | Não há suporte. | 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 o LRS e o link de MI depende de suas circunstâncias e necessidades comerciais. 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 fornece maior resiliência, segurança e flexibilidade.
Além disso, o tempo de mudança é consideravelmente menor com o link MI, o que representa uma vantagem significativa para muitos clientes. Na verdade, o tempo de inatividade potencialmente considerável ao migrar para a camada de serviço Comercialmente Crítico com LRS é o motivo pelo qual o link mi é chamado de a única migração "online verdadeira" para a camada de serviço Comercialmente Crítico.
Por fim, se você precisar do banco de dados 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 dá suporte a esses cenários.