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 suppose 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é. Vous êtes maintenant prêt à finaliser la migration vers SQL Server sur des machines virtuelles SQL Server sur Azure.
Surveiller la migration
Utilisez Transact-SQL (T-SQL) pour surveiller la progression de votre migration.
Exécutez le script suivant sur le principal global et le redirecteur, et validez que l’état pour synchronization_state_desc pour le groupe de disponibilité principal (OnPremAG) et le groupe de disponibilité secondaire (AzureAG) est SYNCHRONIZED. Confirmez que le synchronization_state_desc du groupe de disponibilité distribué (DAG) se synchronise et que last_hardened_lsn est identique sur la base de données principale globale et le redirecteur.
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 drs
INNER JOIN sys.availability_groups 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 êtes prêt à effectuer 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 Basculer vers un 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 se trouve du côté source, validez que vos machines virtuelles SQL Server cibles dans Azure ont joint le 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.