Partilhar via

Migração completa usando um AG distribuído

Use um grupo de disponibilidade distribuída (AG) para migrar seus bancos de dados do SQL Server para o SQL Server em Máquinas Virtuais (VMs) do Azure.

Este artigo pressupõe que você já configurou seu AG distribuído para seus bancos de dados autônomos ou seus bancos de dados de grupo de disponibilidade, e agora você está pronto para finalizar a migração para o SQL Server em VMs do Azure.

Monitorar a migração

Use o Transact-SQL (T-SQL) para monitorar o progresso da migração.

Execute o seguinte script no primário global e no forwarder e valide que o estado de synchronization_state_desc no grupo de disponibilidade primária (OnPremAG) e no grupo de disponibilidade secundária (AzureAG) é SYNCHRONIZED. Confirme se o synchronization_state_desc para o AG distribuído (DAG) está sincronizando e se o last_hardened_lsn é o mesmo em cada base de dados no primário global e no encaminhador.

Caso contrário, execute novamente a consulta em ambos os lados a cada 5 segundos, aproximadamente, até que a condição seja satisfeita.

Use o seguinte script para monitorar a migração:

SELECT ag.name,
       drs.database_id,
       db_name(drs.database_id) AS database_name,
       drs.group_id,
       drs.replica_id,
       drs.synchronization_state_desc,
       drs.last_hardened_lsn
FROM sys.dm_hadr_database_replica_states AS drs
     INNER JOIN sys.availability_groups AS ag
         ON drs.group_id = ag.group_id;

Migração completa

Depois de validar os estados do grupo de disponibilidade e do AG distribuído, você estará pronto para concluir a migração. Isso consiste em realizar o failover do AG distribuído para o encaminhador (o SQL Server de destino no Azure) e, em seguida, migrar a aplicação para o novo primário no lado do Azure.

Para fazer failover do seu grupo de disponibilidade distribuído, revise o failover para o grupo de disponibilidade secundário.

Após o failover, atualize a cadeia de conexão do seu aplicativo para se conectar à nova réplica primária no Azure. Neste ponto, você pode optar por manter o grupo de disponibilidade distribuída ou usar DROP AVAILABILITY GROUP [DAG] nas instâncias de origem e de destino do SQL Server para descartá-lo.

Se o controlador de domínio estiver no lado da origem, valide se as VMs do SQL Server de destino no Azure ingressaram no domínio antes de abandonar as instâncias do SQL Server de origem. Não exclua o controlador de domínio no lado da origem até criar um domínio no lado da origem no Azure e adicionar suas VMs do SQL Server a esse novo domínio.

Conteúdo relacionado

  • Last updated on