Migrar utilizando o link - Azure SQL Managed Instance

Aplica-se a: Azure SQL Managed Instance

Este artigo ensina-o a migrar a sua base de SQL Server base de dados para Azure SQL Managed Instance usando o link Managed Instance.

Para um guia detalhado de migração, consulte Migrar para Azure SQL Managed Instance. Para comparar ferramentas de migração, consulte o Compare o LRS com Managed Instance link.

Observação

Agora pode migrar a sua instância SQL Server habilitada pelo Azure Arc para o Azure SQL Managed Instance diretamente através do portal Azure. Para mais informações, consulte Migrar para Azure SQL Managed Instance.

Visão geral

O link Managed Instance permite a migração do SQL Server alojado em qualquer lugar para o Azure SQL Managed Instance. A ligação utiliza tecnologia de grupo de disponibilidade Always On para replicar alterações quase em tempo real desde a instância principal do SQL Server para a secundária SQL Managed Instance. A ligação fornece a única opção de migração verdadeiramente online entre o SQL Server e o Azure SQL Managed Instance, uma vez que o único tempo de indisponibilidade é a transição para a instância SQL gerida de destino.

Migrar com o link dá as seguintes vantagens:

  • A capacidade de testar cargas de trabalho de somente leitura na Instância Gerida 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 de cada vez.
  • Replicação quase em tempo real de dados que proporciona a replicação de dados mais rápida disponível para o Azure.
  • A migração com o menor tempo de inatividade em comparação com todas as outras soluções disponíveis atualmente.
  • Transição instantânea para a SQL Managed Instance alvo.
  • A capacidade de migrar sempre que estiver pronto.
  • A capacidade de migrar uma ou várias bases de dados de uma ou múltiplas instâncias do SQL Server para a mesma ou múltiplas instâncias geridas SQL no Azure.
  • A única migração online verdadeira para a camada de serviço Business Critical.

Observação

Embora só possa migrar uma base de dados por ligação, pode estabelecer múltiplas ligações da mesma instância do SQL Server para a mesma SQL Managed Instance.

Comportamento da transição

O comportamento da transição depende da versão do SQL Server a partir da qual está a migrar e da política de atualização da Instância Gerida de SQL de destino:

  • Para SQL Server 2016 para SQL Server 2019, a transição para SQL Managed Instance elimina o link.
  • Para versões do SQL Server 2022 ou posteriores, a transição para SQL Managed Instance pode eliminar o link ou mantê-lo conforme a sua escolha durante o failover. Se optar por manter a ligação e a sua instância gerida SQL estiver configurada com uma política de atualização correspondente, pode migrar de volta para o SQL Server se necessário.

Para migração, remover o link é a opção recomendada. Se optar por manter o link mas depois decidir removê-lo, espere que o Azure complete o primeiro backup completo da base de dados após o failover antes de remover o link. Este passo assegura que a base de dados está saudável e totalmente funcional na SQL Managed Instance. Também ajuda a evitar um problema raro e conhecido, em que a base de dados pode ficar temporariamente indisponível após um reinício do servidor se a ligação for removida demasiado cedo. Para mais informações, consulte A base de dados fica indisponível após o reinício do servidor na sequência do failover da ligação MI.

Reverter uma migração

A migração reversa para SQL Server a partir de Azure SQL Managed Instance pode ser suportada dependendo da política update da sua instância gerida em SQL. Por exemplo:

Se a versão do SQL Server de origem for anterior ao SQL Server 2022, a migração reversa não é possível. Quando migra a sua base de dados para SQL Managed Instance, ela sofre uma atualização interna para uma versão mais recente da base de dados que não é compatível com versões anteriores do SQL Server. A compatibilidade da base de dados de migração reversa só está disponível quando o SQL Managed Instance está configurado com a respetiva política de atualização.

Pré-requisitos

Para usar a ligação com o Azure SQL Managed Instance para migração, precisa dos seguintes pré-requisitos:

Avalie e descubra

Depois de verificar se o ambiente de origem é suportado, comece com o estágio de pré-migração. Descubra todas as fontes de dados existentes, avalie a viabilidade da migração e identifique quaisquer problemas de bloqueio que possam impedir a migração. Na fase de Descobrir, analise a rede para identificar todas as instâncias e funcionalidades do SQL Server utilizadas pela sua organização.

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

  • SQL Server ativado por Azure Arc: SQL Server ativado por Azure Arc produz automaticamente uma avaliação para migração para Azure, simplificando o processo de descoberta e a avaliação de prontidão para migração.
  • Azure Migrate para avaliar a adequação à migração de servidores on-premises, realizar dimensionamentos baseados no desempenho e fornecer estimativas de custos para os executar em Azure.
  • Microsoft Kit de Ferramentas de Avaliação e Planeamento (o "MAP Toolkit") para avaliar a sua infraestrutura de TI atual. O kit de ferramentas fornece uma poderosa ferramenta de inventário, avaliação e geração de relatórios para simplificar o processo de planejamento da migração.

Depois de descobertas as fontes de dados, avalie quaisquer instâncias de SQL Server on-premises que possam ser migradas para Azure SQL Managed Instance para identificar bloqueadores de migração ou problemas de compatibilidade.

Pode usar a avaliação de prontidão para migração para avaliar a instância do seu SQL Server.

Para obter orientações detalhadas, consulte a pré-migração.

Criar instância de destino

Depois de avaliar o seu ambiente existente e determinar o nível de serviço e a configuração de hardware adequados para a sua instância SQL gerida de destino, implemente a sua instância alvo usando o portal Azure, PowerShell ou o CLI do Azure.

Depois de criada a sua instância SQL gerida de destino, configure uma ligação entre a base de dados na sua instância SQL Server e a Azure SQL Managed Instance. Primeiro, prepare o seu ambiente e depois configure uma ligação usando SQL Server Management Studio (SSMS) ou scripts.

Verificar o atraso de replicação

É importante que a réplica secundária acompanhe a réplica primária antes de realizar um failover de migração planeado. O failover planeado pode expirar e falhar se a réplica secundária ficar muito atrasada em relação à réplica primária.

Use a seguinte consulta T-SQL tanto no SQL Server como na SQL Managed Instance para monitorizar 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 elevado, espere que a réplica secundária apanhe a réplica primária. Pode ser necessário realizar passos adicionais de resolução de problemas se o atraso persistir, como pausar as cargas de trabalho na réplica principal, melhorar o rendimento da rede de ligação entre as duas instâncias ou aumentar a capacidade de recursos na réplica secundária. A forma mais fácil de parar cargas de trabalho numa réplica principal do SQL Server é cortar as ligações da aplicação à instância.

Migrar vários bancos de dados

Se planeia migrar múltiplas bases de dados de instâncias no mesmo servidor, para um desempenho e previsibilidade ótimos, migre 8 bases de dados por instância de cada vez. Por exemplo, se tiver 10 instâncias com 32 bases de dados ligadas cada, migre 8 bases de dados de cada vez de cada instância usando failovers planeados, e repita o processo até que todas as bases de dados sejam migradas.

Sincronização e transição de dados

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

  1. Parar a carga de trabalho na base de dados principal do SQL Server para que a base de dados secundária no SQL Managed Instance recupere. A forma mais fácil de parar cargas de trabalho numa réplica principal do SQL Server é cortar as ligações da aplicação à instância.
  2. Valide que todos os dados tenham sido transferidos para a base de dados secundária no SQL Managed Instance. Verifique o atraso de replicação para garantir que a réplica secundária está sincronizada com a réplica primária.
  3. Transfira o link para a instância SQL gerida secundária escolhendo transferência planejada.
  4. (Opcionalmente) Assinale a caixa para Remover o link após failover bem-sucedido para assegurar que o failover seja unidirecional e que o link seja removido.
  5. (Opcionalmente) Se estiver numa versão SQL Server suportada com uma política SQL Managed Instance update correspondente, pode manter a ligação após o failover para reverter uma migração, se necessário. Consulte a secção de migração inversa para detalhes específicos das versões.
  6. Corte o aplicativo para se conectar ao ponto de extremidade da instância gerenciada SQL.
  7. (Opcionalmente) Se não optaste por remover o link durante o failover, podes removê-lo depois do cutover quando deixares de precisar dele.

Validar migração

Depois de migrar para a instância gerida de SQL de destino, monitore a sua aplicação, teste o desempenho e corrija quaisquer problemas.

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

Problemas conhecidos com migração

Consulte as seguintes questões conhecidas relacionadas com a migração com o link.

Em circunstâncias raras, a sua base de dados pode ficar temporariamente indisponível na SQL Managed Instance após um reinício do servidor após o failover da ligação. Este problema conhecido ocorre quando se desliga um link antes do Azure completar um backup completo da base de dados após o failover inicial para o SQL Managed Instance.

A base de dados recupera automaticamente após a intervenção da Microsoft, mas esta recuperação pode demorar algum tempo.

Para evitar este problema, não perca o link até que o primeiro backup completo esteja concluído após o failover do SQL Server para a SQL Managed Instance. Para mais informações, consulte Base de dados indisponível após reinício do servidor.

Falhas nas operações de restauro após a migração para o SQL Managed Instance.

Se migrar uma base de dados para Azure SQL Managed Instance a partir do SQL Server 2019 e versões posteriores com recuperação acelerada da base de dados ativada, mas configurada com a persistent version store (PVS) definida para algo diferente do PRIMARY grupo de ficheiros, pode experienciar falhas nas operações de restauro na instância SQL gerida de destino.

Para contornar este problema, certifique-se de definir o armazenamento de versões persistentes (PVS) como PRIMARY na base de dados SQL Server de origem antes de migrá-lo para a Instância Gerida SQL. Se já migrou a base de dados sem definir o PVS para PRIMARY, pode defini-lo na base de dados SQL Server de origem e depois migrá-la novamente para uma Instância de SQL Gerida.

Não é possível usar a recuperação acelerada da base de dados após migrar para o SQL Managed Instance

A partir do SQL Server 2019, se migrar uma base de dados para Azure SQL Managed Instance, e a base de dados de origem tiver a recuperação acelerada da base de dados desativada, não pode usar a recuperação acelerada da base de dados na instância SQL gerida de destino.

Para contornar este problema, certifique-se de que ativa a recuperação acelerada da base de dados na base de dados de origem do SQL Server antes de a migrar para o SQL Managed Instance. Se já migrou a base de dados sem ativar a recuperação acelerada da base de dados, pode ativá-la na base de dados SQL Server de origem e depois remigrar a base de dados para uma instância gerida em SQL.

O SQL Server 2017 e versões anteriores não suportam recuperação acelerada de bases de dados, por isso este problema não se aplica a bases de dados migradas dessas versões do SQL Server.

Não é possível usar o Service Broker após migrar para a SQL Managed Instance

Se migrar uma base de dados para Azure SQL Managed Instance e o Service Broker estiver desativado na base de dados de origem, não pode usar o Service Broker na instância SQL gerida de destino.

Para contornar este problema, certifique-se de ativar o Service Broker na base de dados SQL Server de origem antes de migrá-lo para o SQL Managed Instance. Se já migrou a base de dados sem ativar o Service Broker, pode ativá-la na base de dados SQL Server de origem e depois remigrar a base de dados para o SQL Managed Instance.

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