Migrar com o link – Instância Gerenciada de SQL do Azure

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

Este artigo ensina você a migrar seu banco de dados SQL Server para Instância Gerenciada de SQL do Azure usando o link Instância Gerenciada.

Para obter um guia de migração detalhado, examine Migrate para Instância Gerenciada de SQL do Azure. Para comparar as ferramentas de migração, examine Compare LRS com Instância Gerenciada link.

Observação

Agora você pode migrar sua instância de SQL Server habilitada por Azure Arc para Instância Gerenciada de SQL do Azure diretamente por meio do portal Azure. Para obter mais informações, consulte Migrate to Instância Gerenciada de SQL do Azure.

Visão geral

O link Instância Gerenciada permite a migração de SQL Server hospedados em qualquer lugar para Instância Gerenciada de SQL do Azure. O link usa a tecnologia de grupo de disponibilidade Always On para replicar alterações quase em tempo real da instância de SQL Server primária para a Instância Gerenciada de SQL secundária. O link fornece a única opção de migração verdadeiramente online entre o SQL Server e a Instância Gerenciada de SQL do Azure, já que o único tempo de inatividade é a transferência para a instância gerenciada de SQL de destino.

A migração com o link oferece:

  • A capacidade de testar cargas de trabalho somente leitura na Instância Gerenciada de SQL antes de finalizar a migração para o Azure.
  • A capacidade de manter o link e a migração funcionando pelo tempo que você precisar, semanas e até meses por vez.
  • Replicação de dados quase em tempo real que fornece a replicação de dados mais rápida disponível para o Azure.
  • Migração com o menor tempo de inatividade em comparação com todas as outras soluções disponíveis atualmente.
  • Migração instantânea para o Instância Gerenciada de SQL de destino.
  • A capacidade de migrar sempre que estiver pronto.
  • A capacidade de migrar bancos de dados únicos ou múltiplos de uma ou várias instâncias de SQL Server para as mesmas ou várias instâncias gerenciadas de SQL em Azure.
  • A única migração online verdadeira para a camada de serviço Comercialmente Crítico.

Observação

Embora você só possa migrar um banco de dados por link, é possível estabelecer vários links da mesma instância de SQL Server para a mesma Instância Gerenciada de SQL.

Comportamento da substituição

O comportamento de substituição depende da versão de SQL Server da qual você está migrando e da política de atualização da Instância Gerenciada de SQL de destino:

  • Para SQL Server 2016 a SQL Server 2019, a substituição para Instância Gerenciada de SQL descarta o link.
  • Para SQL Server 2022 ou versões posteriores, a migração definitiva para a Instância Gerenciada de SQL pode remover o link ou mantê-lo, com base na opção escolhida durante o failover. Se você optar por manter o link e sua instância gerenciada de SQL estiver configurada com uma política de atualização correspondente, você poderá reverter a migração de volta para SQL Server, se necessário.

Para a migração, remover o link é a opção recomendada. Se você optar por manter o link, mas depois decidir removê-lo, aguarde Azure concluir o primeiro backup completo do banco de dados após o failover antes de remover o link. Esta etapa garante que o banco de dados esteja íntegro e totalmente funcional em Instância Gerenciada de SQL. Ele também ajuda a evitar um problema conhecido raro em que o banco de dados pode ficar temporariamente indisponível após uma reinicialização do servidor se o link for removido muito cedo. Para obter mais informações, consulte Banco de dados fica indisponível após a reinicialização do servidor após o failover do link do MI.

Reverter uma migração

Reverter a migração de volta para SQL Server da Instância Gerenciada de SQL do Azure pode ter suporte dependendo da política de atualização da instância gerenciada de SQL. Por exemplo:

Se a versão de SQL Server de origem for anterior à SQL Server 2022, a migração reversa não será possível. Quando você migra o banco de dados para Instância Gerenciada de SQL, ele passa por uma atualização interna para uma versão mais recente do banco de dados que não é compatível com versões de SQL Server anteriores. A compatibilidade do banco de dados de migração reversa só estará disponível quando Instância Gerenciada de SQL estiver configurado com a política de atualização correspondente.

Pré-requisitos

Para usar o link com Instância Gerenciada de SQL do Azure para migração, você precisa dos seguintes pré-requisitos:

Avaliar e descobrir

Depois de verificar se o ambiente de origem tem suporte, comece com a fase de pré-migração. Descubra todas as fontes de dados existentes, avalie a viabilidade da migração e identifique problemas de bloqueio que possam impedir a migração. Na fase descobrir, examine a rede para identificar todas as instâncias do SQL Server e funcionalidades usadas pela sua organização.

Você pode usar as seguintes ferramentas para descobrir origens de SQL em seu ambiente:

Depois que as fontes de dados forem descobertas, avalie as instâncias SQL Server locais que podem ser migradas para Instância Gerenciada de SQL do Azure para identificar os bloqueadores de migração ou problemas de compatibilidade.

Você pode usar a avaliação de preparação para migração para avaliar sua instância de SQL Server de origem.

Para obter diretrizes detalhadas, consulte a pré-migração.

Criar instância de destino

Depois de avaliar seu ambiente existente e determinar a configuração de hardware e a camada de serviço apropriada para sua instância gerenciada de SQL de destino, implante sua instância de destino usando o portal Azure, PowerShell ou o CLI do Azure.

Depois que a instância gerenciada de SQL de destino for criada, configure um link entre o banco de dados em sua instância de SQL Server e Instância Gerenciada de SQL do Azure. Primeiro, preparar seu ambiente e configurar um link usando SQL Server Management Studio (SSMS) ou scripts.

Verificar o atraso de replicação

É importante que a réplica secundária se atualize até a réplica primária antes de executar um failover de migração planejado. O failover planejado pode expirar e falhar se a réplica secundária estiver significativamente atrasada em relação à réplica primária.

Use a seguinte consulta T-SQL em SQL Server e Instância Gerenciada de SQL para monitorar o atraso de replicação entre as réplicas:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Se o atraso de replicação for alto, aguarde até que a réplica secundária acompanhe a réplica primária. Talvez seja necessário executar etapas adicionais de solução de problemas se o atraso persistir, como pausar cargas de trabalho na réplica primária, melhorar a taxa de transferência de rede de vínculo entre as duas instâncias ou aumentar a capacidade do recurso na réplica secundária. A maneira mais fácil de parar cargas de trabalho em uma réplica primária SQL Server é cortar conexões de aplicativo com a instância.

Migrar vários bancos de dados

Se você planeja migrar vários bancos de dados de instâncias no mesmo servidor, para obter o desempenho e a previsibilidade ideais, migre 8 bancos de dados por instância de cada vez. Por exemplo, se você tiver 10 instâncias com 32 bancos de dados vinculados cada, migre 8 bancos de dados por vez de cada instância usando failovers planejados e repita o processo até que todos os bancos de dados sejam migrados.

Sincronização e substituição de dados

Depois que o link estiver estabelecido e você estiver pronto para migrar, siga estas etapas (normalmente durante uma janela de manutenção):

  1. Interrompa a carga de trabalho no banco de dados de SQL Server primário para que o banco de dados secundário em Instância Gerenciada de SQL se atualize. A maneira mais fácil de parar cargas de trabalho em uma réplica primária SQL Server é cortar conexões de aplicativo com a instância.
  2. Valide se todos os dados foram transferidos para o banco de dados secundário no Instância Gerenciada de SQL. Verifique o atraso de replicação para garantir que a réplica secundária esteja alinhada com a réplica primária.
  3. Faça failover do link para a instância gerenciada de SQL secundária escolhendo Failover planejado.
  4. (Opcionalmente) Marque a caixa para Remover o link após o failover bem-sucedido, garantindo assim que o failover seja unidirecional e o link seja removido.
  5. (Opcionalmente) Se você estiver em uma versão do SQL Server com suporte e uma política de atualização correspondente do Instância Gerenciada de SQL, poderá manter o link após o failover para reverter uma migração, se necessário. Verifique a seção 'Reverter uma migração' para obter detalhes específicos da versão.
  6. Substitua o aplicativo para se conectar ao ponto de extremidade da instância gerenciada de SQL.
  7. (Opcionalmente) Se você não optou por remover o link durante o failover, poderá remover o link após a substituição depois de não precisar mais dele.

Validar a migração

Depois de migrar para o alvo da instância gerenciada de SQL, monitore o aplicativo, teste o desempenho e corrija quaisquer problemas.

Para obter detalhes, verifique pós-migração.

Problemas conhecidos com a migração

Examine os seguintes problemas conhecidos relacionados à migração com o link.

Em circunstâncias raras, seu banco de dados pode ficar temporariamente indisponível no Instância Gerenciada de SQL após uma reinicialização do servidor após o failover do link. Esse problema conhecido ocorre quando você remove um link antes de o Azure concluir um backup completo do banco de dados após o failover inicial para o Instância Gerenciada de SQL.

O banco de dados se recupera automaticamente após a intervenção de Microsoft, mas essa recuperação pode levar algum tempo.

Para evitar esse problema, não solte o link até que o primeiro backup completo seja concluído após o failover de SQL Server para Instância Gerenciada de SQL. Para obter mais informações, consulte Banco de Dados indisponível após a reinicialização do servidor.

Restaurar falhas de operação após a migração para Instância Gerenciada de SQL

Se você migrar um banco de dados para uma instância gerenciada do SQL na Azure a partir do SQL Server 2019 e versões posteriores, com a recuperação de banco de dados acelerada habilitada, mas se o repositório de versão persistente (PVS) estiver configurado para algo diferente do grupo de arquivos PRIMARY, poderão ocorrer falhas nas operações de restauração na instância gerenciada de SQL de destino.

Para contornar esse problema, defina o persistent version store (PVS) como PRIMARY no banco de dados de SQL Server de origem antes de migrá-lo para Instância Gerenciada de SQL. Se você já migrou o banco de dados sem definir o PVS para PRIMARY, poderá defini-lo no banco de dados do SQL Server de origem e migrar novamente o banco de dados para a Instância Gerenciada de SQL.

Não é possível usar a recuperação acelerada do banco de dados após a migração para Instância Gerenciada de SQL

A partir do SQL Server 2019, se você migrar um banco de dados para a Instância Gerenciada de SQL do Azure e o banco de dados de origem tiver a recuperação acelerada do banco de dados desabilitada, você não poderá usar a recuperação acelerada do banco de dados na instância gerenciada de SQL de destino.

Para contornar esse problema, verifique se você abilita recuperação acelerada de banco de dados no banco de dados de SQL Server de origem antes de migrá-lo para Instância Gerenciada de SQL. Se você já migrou o banco de dados sem habilitar a recuperação acelerada do banco de dados, poderá habilitá-lo no banco de dados de SQL Server de origem e, em seguida, migrar novamente o banco de dados para a instância gerenciada de SQL.

O SQL Server 2017 e versões anteriores não dão suporte à recuperação acelerada do banco de dados, portanto, esse problema não se aplica aos bancos de dados migrados dessas versões do SQL Server.

Não é possível usar o Service Broker depois de migrar para Instância Gerenciada de SQL

Se você migrar um banco de dados para a Instância Gerenciada de SQL do Azure e o Service Broker estiver desabilitado no banco de dados de origem, você não poderá usar o Service Broker na instância gerenciada de SQL de destino.

Para solucionar esse problema, habilite o Service Broker no banco de dados de SQL Server de origem antes de migrá-lo para Instância Gerenciada de SQL. Se você já migrou o banco de dados sem habilitar o Service Broker, poderá habilitá-lo no banco de dados de SQL Server de origem e migrar novamente o banco de dados para Instância Gerenciada de SQL.

Conteúdo relacionado

Para usar o link:

Para saber mais sobre o link:

Para outros cenários de replicação e migração, considere:

  • Last updated on