Partager via

Effectuer la migration à l’aide d’un groupe de disponibilité distribué

Utilisez un groupe de disponibilité distribué pour migrer vos bases de données de SQL Server vers des machines virtuelles SQL Server sur Azure.

Cet article part du principe que vous avez déjà configuré votre groupe de disponibilité distribué pour vos bases de données autonomes ou vos bases de données de groupe de disponibilité, et que vous êtes maintenant prêt à finaliser la migration vers SQL Server sur des machines virtuelles Azure.

Surveiller la migration

Utilisez Transact-SQL (T-SQL) pour surveiller la progression de votre migration.

Exécutez le script suivant sur le serveur principal global et le redirecteur et vérifiez que l’état pour synchronization_state_desc le groupe de disponibilité principal (OnPremAG) et le groupe de disponibilité secondaire (AzureAG) est SYNCHRONIZED. Vérifiez que le synchronization_state_desc du groupe de disponibilité distribué (DAG) est synchronisé et que le last_hardened_lsn est identique par base de données à la fois sur le serveur principal global et sur le serveur de transfert.

Si ce n’est pas le cas, réexécutez la requête des deux côtés toutes les 5 secondes environ jusqu’à ce que ce soit le cas.

Utilisez le script suivant pour surveiller la migration :

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;

Terminer la migration

Une fois que vous avez validé les états du groupe de disponibilité et du groupe de disponibilité distribué, vous pouvez procéder à la migration. Il s’agit du basculement du groupe de disponibilité distribué vers le redirecteur (instance SQL Server dans Azure cible), puis de transitionner l’application vers la nouvelle application principale du côté Azure.

Pour basculer votre groupe de disponibilité distribué, consultez les instructions sur le basculement vers le groupe de disponibilité secondaire.

Après le basculement, mettez à jour la chaîne de connexion de votre application pour vous connecter au nouveau réplica principal dans Azure. À ce stade, vous pouvez choisir de conserver le groupe de disponibilité distribué, ou d’utiliser DROP AVAILABILITY GROUP [DAG] à la fois sur les instances SQL Server source et cible pour l’abandonner.

Si votre contrôleur de domaine est côté source, vérifiez que vos machines virtuelles SQL Server cibles dans Azure sont jointes au domaine avant d’abandonner les instances SQL Server sources. Ne supprimez pas le contrôleur de domaine côté source tant que vous n’avez pas créé un domaine côté source dans Azure et ajouté vos machines virtuelles SQL Server à ce nouveau domaine.

Contenu connexe

  • Last updated on