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.

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.

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 votre base de données est migrée vers SQL Managed Instance, elle subit une mise à niveau interne vers une version plus récente de la base de données qui n'est pas compatible avec les versions antérieures de SQL Server. La compatibilité de la base de données de migration inverse est disponible uniquement lorsque SQL Managed Instance est configuré avec la stratégie de mise à jour correspondante.

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