Migrer avec le lien - Azure SQL Managed Instance

Applies to :Azure SQL Managed Instance

Cet article vous apprend à migrer votre base de données SQL Server vers Azure SQL Managed Instance à l’aide du lien Managed Instance.

Pour obtenir un guide de migration détaillé, consultez Migrate vers Azure SQL Managed Instance. Pour comparer les outils de migration, consultez le lien Comparaison de LRS avec Instance Gérée.

Remarque

Vous pouvez maintenant migrer votre instance de SQL Server activée par Azure Arc pour Azure SQL Managed Instance directement via le portail Azure. Pour plus d’informations, consultez Migrate vers Azure SQL Managed Instance.

Vue d’ensemble

Le lien Managed Instance permet la migration de SQL Server hébergée n’importe où, vers Azure SQL Managed Instance. Le lien utilise la technologie du groupe de disponibilité Always On pour répliquer les modifications presque en temps réel de l’instance principale SQL Server vers le SQL Managed Instance secondaire. Le lien offre la véritable option de migration en ligne entre SQL Server et Azure SQL Managed Instance, puisque le seul temps d'arrêt est le basculement vers l’instance managée SQL cible.

La migration avec le lien vous donne :

  • Possibilité de tester les charges de travail en lecture seule sur SQL Managed Instance avant de finaliser la migration vers Azure.
  • Possibilité de maintenir le lien et la migration en cours d’exécution tant que vous en avez besoin, des semaines et même des mois à la fois.
  • Réplication en temps quasi réel des données qui fournit la réplication de données la plus rapide disponible pour Azure.
  • La migration avec le moins de temps d'arrêt possible par rapport à toutes les autres solutions disponibles aujourd'hui.
  • Basculement instantané vers la SQL Managed Instance cible.
  • Possibilité de migrer chaque fois que vous êtes prêt.
  • Possibilité de migrer des bases de données uniques ou multiples d’une ou plusieurs instances SQL Server vers les mêmes instances managées SQL dans Azure.
  • La seule migration en ligne vraie vers le niveau de service Critique pour l'entreprise.

Remarque

Même si vous ne pouvez migrer qu’une base de données par lien, vous pouvez établir plusieurs liens de la même instance de SQL Server vers la même SQL Managed Instance.

Comportement de basculement

Le comportement de basculement dépend de la version de SQL Server à partir de laquelle vous migrez et de la stratégie de mise à jour de votre SQL Managed Instance cible :

  • Pour SQL Server 2016 à SQL Server 2019, le basculement vers SQL Managed Instance supprime le lien.
  • Pour SQL Server 2022 ou version ultérieure, le basculement vers SQL Managed Instance peut supprimer le lien ou conserver le lien en fonction de votre choix lors du basculement. Si vous choisissez de conserver le lien et que votre instance managée SQL est configurée avec une stratégie de mise à jour correspondante, vous pouvez annuler la migration vers SQL Server si nécessaire.

Pour la migration, la suppression du lien est l’option recommandée. Si vous choisissez de conserver le lien, mais que vous décidez ultérieurement de le supprimer, attendez que Azure termine la première sauvegarde complète de la base de données après le basculement avant de supprimer le lien. Cette étape garantit que la base de données est saine et entièrement fonctionnelle sur SQL Managed Instance. Il permet également d’éviter un problème connu rare où la base de données peut devenir temporairement indisponible après le redémarrage d’un serveur si le lien est supprimé trop tôt. Pour plus d’informations, consultez La base de données devient indisponible après le redémarrage du serveur à la suite d’un basculement du lien MI.

Inverser une migration

La migration inversée vers SQL Server de Azure SQL Managed Instance peut être prise en charge en fonction de la stratégie update de votre instance managée SQL. Par exemple:

  • Stratégie de mise à jour de SQL Server 2022 : les bases de données provenant d’instances configurées avec la stratégie de mise à jour SQL Server 2022 peuvent être restaurées dans des instances SQL Server 2022.
  • Stratégie de mise à jour SQL Server 2025 : des bases de données d’instances configurées avec la stratégie de mise à jour SQL Server 2025 peuvent être restaurées vers des instances SQL Server 2025.
  • Stratégie de mise à jour Always-up-to-date : Les bases de données provenant d'instances configurées avec la stratégie de mise à jour Always-up-to-date ne peuvent pas être restaurées sur SQL Server.

Si votre version SQL Server source est antérieure à SQL Server 2022, la migration inverse n'est pas possible. Lorsque vous migrez votre base de données vers SQL Managed Instance, elle subit une mise à niveau interne vers une version de base de données plus récente qui n'est pas compatible avec les versions antérieures SQL Server. La compatibilité de la base de données de migration inverse n’est disponible que lorsque SQL Managed Instance est configuré avec la stratégie de mise à jour correspondante.

Prérequis

Pour utiliser le lien avec Azure SQL Managed Instance pour la migration, vous avez besoin des prérequis suivants :

Évaluer et découvrir

Une fois que vous avez vérifié que votre environnement source est pris en charge, commencez par la phase de prémigration. Découvrez toutes les sources de données existantes, évaluez la faisabilité de la migration et identifiez les problèmes bloquants susceptibles d’empêcher la migration de s’effectuer correctement. Dans la phase Découvrir, analysez le réseau pour identifier toutes les instances et fonctionnalités SQL Server utilisées par votre organisation.

Vous pouvez utiliser les outils suivants pour découvrir des sources SQL dans votre environnement :

  • SQL Server activé par Azure Arc : SQL Server activé par Azure Arc produit automatiquement une évaluation de la migration vers Azure, ce qui simplifie le processus de découverte et l’évaluation de préparation pour la migration.
  • Azure Migrate pour évaluer l’adéquation de la migration des serveurs locaux, effectuer le dimensionnement basé sur les performances et fournir des estimations de coûts pour les exécuter dans Azure.
  • Microsoft Assessment and Planning Toolkit (the MAP Toolkit) pour évaluer votre infrastructure informatique actuelle. La boîte à outils fournit un puissant outil d’inventaire, d’évaluation et de création de rapports, qui permet de simplifier le processus de planification de la migration.

Une fois les sources de données découvertes, évaluez les instances locales SQL Server qui peuvent être migrées vers Azure SQL Managed Instance pour identifier les bloqueurs de migration ou les problèmes de compatibilité.

Vous pouvez utiliser l'évaluation de l'état de préparation à la migration pour évaluer l'instance de SQL Server source.

Pour obtenir des instructions détaillées, passez en revue la pré-migration.

Créer une instance cible

Une fois que vous avez évalué votre environnement existant et déterminé le niveau de service et la configuration matérielle appropriés pour votre instance managée SQL cible, déployez votre instance cible à l'aide du portail Azure, PowerShell ou du Azure CLI.

Une fois votre instance managée SQL cible créée, configurez un lien entre la base de données sur votre instance de SQL Server et Azure SQL Managed Instance. Tout d’abord, preparez votre environnement puis configurez un lien à l’aide de SQL Server Management Studio (SSMS) ou scripts.

Vérifier le décalage de réplication

Il est important que la réplique secondaire rattrape la réplique principale avant d'effectuer un basculement planifié lors d'une migration. Le basculement planifié peut expirer et échouer si la réplique secondaire se trouve nettement derrière la réplique principale.

Utilisez la requête T-SQL suivante sur SQL Server et SQL Managed Instance pour surveiller le décalage de réplication entre les 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

Si le décalage de réplication est élevé, attendez que la réplique secondaire rattrape la réplique principale. Vous devrez peut-être effectuer des étapes de dépannage supplémentaires si le décalage persiste, comme la suspension des charges de travail sur le réplica principal, l’amélioration du débit réseau de liaison entre les deux instances ou l’augmentation de la capacité des ressources sur le réplica secondaire. Le moyen le plus simple d’arrêter des charges de travail sur un réplica principal SQL Server consiste à couper les connexions d’application à l’instance.

Migrer plusieurs bases de données

Si vous envisagez de migrer plusieurs bases de données à partir d’instances sur le même serveur, pour des performances et une prévisibilité optimales, migrez 8 bases de données par instance à la fois. Par exemple, si vous avez 10 instances avec 32 bases de données liées chacune, migrez 8 bases de données à la fois à partir de chaque instance à l’aide de basculements planifiés et répétez le processus jusqu’à ce que toutes les bases de données soient migrées.

Synchronisation des données et basculement

Une fois votre lien établi et que vous êtes prêt à migrer, procédez comme suit (généralement pendant une fenêtre de maintenance) :

  1. Arrêtez la charge de travail sur la base de données principale SQL Server afin que la base de données secondaire sur SQL Managed Instance se synchronise. Le moyen le plus simple d’arrêter des charges de travail sur un réplica principal SQL Server consiste à couper les connexions d’application à l’instance.
  2. Vérifiez que toutes les données sont passées à la base de données secondaire sur SQL Managed Instance. Vérifiez le décalage de réplication pour vous assurer que le réplica secondaire est synchronisé avec le réplica principal.
  3. Basculez la liaison vers SQL Managed Instance secondaire en choisissant Basculement planifié.
  4. (Facultatif) Cochez la case pour supprimer le lien après le basculement réussi pour vous assurer que le basculement est unidirectionnel et que le lien est supprimé.
  5. (Facultatif) Si vous utilisez une version de SQL Server prise en charge avec une stratégie SQL Managed Instance update correspondante, vous pouvez conserver le lien après le basculement pour inverser une migration si nécessaire. Consultez la section consacrée à l'inversion d'une migration pour obtenir des détails de version spécifiques.
  6. Basculez l’application pour vous connecter au point de terminaison SQL Managed Instance.
  7. (Facultatif) Si vous n’avez pas choisi de supprimer le lien pendant le basculement, vous pouvez supprimer le lien après le basculement une fois que vous n’en avez plus besoin.

Vérifiez la migration

Après avoir basculé vers la cible SQL managed instance, surveillez votre application, testez les performances et remédiez aux éventuels problèmes.

Pour plus d’informations, consultez post-migration.

Problèmes connus liés à la migration

Passez en revue les problèmes connus suivants liés à la migration avec le lien.

Dans de rares cas, votre base de données peut devenir temporairement indisponible sur SQL Managed Instance après le redémarrage d’un serveur après le basculement du lien. Ce problème connu se produit lorsque vous supprimez un lien avant que Azure termine une sauvegarde complète de la base de données après le basculement initial vers SQL Managed Instance.

La base de données récupère automatiquement après l'intervention de Microsoft, mais cette récupération peut prendre un certain temps.

Pour éviter ce problème, ne supprimez pas le lien tant que la première sauvegarde complète n'est pas terminée après le basculement de SQL Server vers SQL Managed Instance. Pour plus d’informations, consultez Base de données indisponible après le redémarrage du serveur.

Échecs d’opération de restauration après la migration vers SQL Managed Instance

Si vous migrez une base de données vers Azure SQL Managed Instance à partir de SQL Server 2019 et versions ultérieures avec récupération accélérée de base de données activée, mais avec le magasin de versions persistantes (PVS) configuré sur une valeur autre que le groupe de fichiers PRIMARY, vous pouvez rencontrer des échecs d’opération de restauration sur l’instance SQL managée cible.

Pour contourner ce problème, veillez à définir le magasin de versions persistantes (PVS) sur PRIMARY sur la base de données SQL Server source avant de la migrer vers SQL Managed Instance. Si vous avez déjà migré la base de données sans définir le PVS à PRIMARY, vous pouvez le configurer sur la base de données source SQL Server, puis ré-migrer la base de données vers une instance SQL gérée.

Impossible d’utiliser la récupération de base de données accélérée après la migration vers SQL Managed Instance

À compter de SQL Server 2019, si vous migrez une base de données vers Azure SQL Managed Instance et que la base de données source a accéléré la récupération de base de données désactivée, vous ne pouvez pas utiliser la récupération de base de données accélérée sur l’instance managée SQL cible.

Pour contourner ce problème, veillez à activer la récupération accélérée de la base de données sur la base de données source SQL Server avant de la migrer vers SQL Managed Instance. Si vous avez déjà migré la base de données sans activer la récupération accélérée de la base de données, vous pouvez l’activer sur la base de données SQL Server source, puis migrer à nouveau la base de données vers une instance managée SQL.

SQL Server 2017 et versions antérieures ne prennent pas en charge la récupération accélérée des bases de données. Ce problème ne s’applique donc pas aux bases de données migrées à partir de ces versions de SQL Server.

Impossible d’utiliser Service Broker après la migration vers SQL Managed Instance

Si vous migrez une base de données vers Azure SQL Managed Instance et que Service Broker est désactivé sur la base de données source, vous ne pouvez pas utiliser Service Broker sur l'instance managée SQL cible.

Pour contourner ce problème, veillez à activer Service Broker sur la base de données source SQL Server avant de la migrer vers SQL Managed Instance. Si vous avez déjà migré la base de données sans activer Service Broker, vous pouvez l’activer sur la base de données source SQL Server, puis migrer à nouveau la base de données vers SQL Managed Instance.

Contenu connexe

Pour utiliser le lien :

Pour en savoir plus sur le lien :

Pour d’autres scénarios de réplication et de migration, considérez :

  • Last updated on