Tutoriel : Migrer Azure Database pour MySQL - Serveur unique vers Serveur flexible hors connexion à l’aide de DMS via le Portail Azure

Vous pouvez migrer une instance d’Azure Database pour MySQL – Serveur unique vers Azure Database pour MySQL – Serveur flexible à l’aide d’Azure Database Migration Service (DMS), un service complètement managé conçu pour permettre des migrations transparentes de plusieurs sources de base de données vers des plateformes de données Azure. Dans ce tutoriel, nous effectuons une migration hors connexion d’un exemple de base de données d’Azure Database pour MySQL serveur unique vers un serveur flexible MySQL (les deux exécutant la version 5.7) à l’aide d’une activité de migration DMS.

DMS prend en charge la migration de serveurs MySQL d’une version antérieure (v5.6 et versions ultérieures) vers des versions ultérieures. De plus, DMS prend en charge les migrations entre régions, groupes de ressources et abonnements. Vous pouvez donc sélectionner une région, un groupe de ressources et un abonnement pour le serveur cible différents de ceux spécifiés pour votre serveur source.

Dans ce tutoriel, vous apprendrez à :

Prérequis

Pour suivre ce didacticiel, vous devez effectuer les opérations suivantes :

• Créez ou utilisez une instance existante d’Azure Database pour MySQL – Serveur unique (serveur source).

• Pour réussir une migration de schéma, sur le serveur source, l’utilisateur effectuant la migration a besoin des privilèges suivants :

  • Privilège « SELECT » au niveau du serveur sur la source.
  • S’il migre des vues, l’utilisateur doit disposer du privilège « SHOW VIEW » sur le serveur source et du privilège « CREATE VIEW » sur le serveur cible.
  • Si la migration se déclenche, l’utilisateur doit disposer du privilège « TRIGGER » sur les serveurs source et cible.
  • En cas de migration de routines (procédures et/ou fonctions), l’utilisateur doit disposer des privilèges « CREATE ROUTINE » et « ALTER ROUTINE » accordés au niveau du serveur sur la cible.
  • S’il migre des événements, l’utilisateur doit disposer du privilège « EVENT » sur les serveurs source et cible.
  • En cas de migration des utilisateurs/connexions, l’utilisateur doit disposer du privilège « CREATE USER » sur le serveur cible.
  • Privilège « DROP » au niveau du serveur sur la cible afin de supprimer des tables qui pourraient déjà exister. Par exemple, lors d’une nouvelle tentative de migration.
  • Privilège « REFERENCES » au niveau du serveur sur la cible afin de créer des tables avec des clés étrangères.
  • En cas de migration vers MySQL 8.0, l’utilisateur doit disposer du privilège « SESSION_VARIABLES_ADMIN » sur le serveur cible.
  • Privilège « CREATE » au niveau du serveur sur la cible.
  • Privilège « INSERT » au niveau du serveur sur la cible.
  • Privilège « UPDATE » au niveau du serveur sur la cible.
  • Privilège « DELETE » au niveau du serveur sur la cible.

Limites

Lorsque vous préparez la migration, veillez à prendre en compte les limitations suivantes.

• Lors de la migration d’objets non de table, DMS ne prend pas en charge le renommage des bases de données.

• Lors de la migration vers un serveur cible avec bin_log activé, veillez à activer log_bin_trust_function_creators pour permettre la création de routines et de déclencheurs.

• Lors de la migration du schéma, DMS ne prend pas en charge la création d’une base de données sur le serveur cible.

• DMS ne prend pas en charge la migration de la clause DEFINER pour les objets. Tous les types d’objets avec des definers sur la source sont supprimés et, après la migration, le definer par défaut pour les tables sera défini sur la connexion utilisée pour exécuter la migration.

• Actuellement, DMS prend uniquement en charge la migration d’un schéma dans le cadre du déplacement des données. Si rien n’est sélectionné pour le déplacement des données, la migration de schéma ne se produit pas. La sélection d’une table pour la migration de schéma la sélectionne également pour le déplacement des données.

Meilleures pratiques pour créer un serveur flexible afin d’accélérer les chargements de données à l’aide de DMS

DMS prend en charge les migrations entre régions, groupes de ressources et abonnements. Vous êtes donc libre de sélectionner la région, le groupe de ressources et l’abonnement appropriés pour votre serveur flexible cible. Avant de créer votre serveur flexible cible, prenez en compte les conseils de configuration suivants pour garantir des chargements de données plus rapides à l’aide de DMS.

• Sélectionnez la taille de calcul et le niveau de calcul du serveur flexible cible en fonction du niveau tarifaire et des VCores du serveur unique source, en vous basant sur le tableau suivant.

  Niveau tarifaire du serveur unique	VCores du serveur unique	Taille de calcul du serveur flexible	Niveau de calcul du serveur flexible
  De base1	1	Usage général	Standard_D16ds_v4
  De base1	2	Usage général	Standard_D16ds_v4
  Usage général 1	4	Usage général	Standard_D16ds_v4
  Usage général 1	8	Usage général	Standard_D16ds_v4
  Usage général	16	Usage général	Standard_D16ds_v4
  Usage général	32	Usage général	Standard_D32ds_v4
  Usage général	64	Usage général	Standard_D64ds_v4
  Mémoire optimisée	4	Critique pour l’entreprise	Standard_E4ds_v4
  Mémoire optimisée	8	Critique pour l’entreprise	Standard_E8ds_v4
  Mémoire optimisée	16	Critique pour l’entreprise	Standard_E16ds_v4
  Mémoire optimisée	32	Critique pour l’entreprise	Standard_E32ds_v4

  ¹ Pour la migration, sélectionnez le calcul d’usage général 16 vCores pour le serveur flexible cible pour des migrations plus rapides. Revenez à la taille de calcul souhaitée pour le serveur cible une fois la migration terminée en suivant la recommandation de taille de calcul dans la section Exécution des activités de post-migration plus loin dans cet article.

• La version MySQL du serveur flexible cible doit être supérieure ou égale à celle du serveur unique source.

• Sauf si vous devez déployer le serveur flexible cible dans une zone spécifique, définissez la valeur du paramètre Zone de disponibilité sur « Aucune préférence ».

• Pour la connectivité réseau, sous l’onglet Mise en réseau, si le serveur unique source a des points de terminaison privés ou des liaisons privées configurés, sélectionnez Accès privé ; sinon, sélectionnez Accès public.

• Copiez toutes les règles de pare-feu du serveur unique source vers le serveur flexible cible.

• Copiez toutes les étiquettes nom/valeur du serveur unique vers le serveur flexible lors de la création elle-même.

Créer et configurer le serveur flexible cible

Avec ces meilleures pratiques à l’esprit, créez votre serveur flexible cible, puis configurez-le.

• Créez le serveur flexible cible. Pour obtenir des instructions guidées, consultez le démarrage rapide Démarrage rapide : Créer une instance d’Azure Database pour MySQL avec le Portail Azure.

• Ensuite, pour configurer le serveur flexible cible nouvellement créé, procédez comme suit :

  • L’utilisateur effectuant la migration doit disposer des autorisations suivantes :
    • Pour créer des tables sur la cible, l’utilisateur doit disposer du privilège « CREATE ».
    • Si vous migrez vers une table avec une option « UNION », l’utilisateur doit disposer des privilèges « SELECT », « UPDATE » et « DELETE » pour les tables que vous mappez à une table MERGE.
    • Si vous migrez des vues, vous devez disposer du privilège « CREATE VIEW ». N’oubliez pas que certains privilèges peuvent être nécessaires en fonction du contenu des vues. Si vous souhaitez obtenir plus d’informations, reportez-vous à la documentation MySQL spécifique à votre version pour « CREATE VIEW STATEMENT »
    • Si vous migrez des événements, l’utilisateur doit disposer du privilège « EVENT ».
    • Si vous migrez des déclencheurs, l’utilisateur doit disposer du privilège « TRIGGER ».
    • Si vous migrez des routines, l’utilisateur doit disposer du privilège « CREATE ROUTINE ».
  • Créez une base de données cible, même si elle n’a pas besoin d’être remplie avec des tables/vues, etc.
    • Définissez le caractère, les classements et tous les autres paramètres de schéma applicables appropriés avant de démarrer la migration, car cela peut affecter l’ensemble DEFAULT dans certaines définitions d’objets.
    • En outre, si vous migrez des objets non de table, veillez à utiliser le même nom pour le schéma cible que celui utilisé sur la source.
  • Configurez les paramètres du serveur sur le serveur flexible cible comme suit :
    • Définissez la version TLS et le paramètre de serveur require_secure_transport pour qu’ils correspondent aux valeurs sur le serveur source.
    • Définissez le paramètre sql_mode du serveur pour qu’il corresponde aux valeurs du serveur source.
    • Configurez les paramètres de serveur sur le serveur cible pour qu’ils correspondent à toutes les valeurs non par défaut utilisées sur le serveur source.
    • Pour garantir des chargements de données plus rapides lors de l’utilisation de DMS, configurez les paramètres de serveur suivants comme décrit.
      • max_allowed_packet défini sur 1073741824 (par ex., 1 Go) pour éviter tout problème de connexion en raison de grandes lignes.
      • slow_query_log : définissez cette valeur sur OFF pour désactiver le journal des requêtes lentes. Cela élimine la surcharge causée par la journalisation de requêtes lentes pendant les chargements de données.
      • Innodb_buffer_pool_size : peut être augmenté uniquement en effectuant un scale-up du calcul pour le serveur Azure Database pour MySQL. Effectuez un scale-up du serveur vers la SKU 64 vCores à usage général à partir du niveau tarifaire du portail pendant la migration afin d’augmenter la valeur innodb-buffer-pool-size.
      • innodb_io_capacity & innodb_io_capacity_max : passez à 9000 à partir des paramètres de serveur dans le Portail Azure pour améliorer l’utilisation des E/S afin d’optimiser la vitesse de la migration.
      • innodb_write_io_threads : affectez la valeur 4 aux paramètres du serveur dans le Portail Azure pour accélérer la migration.
  • Configurez les réplicas sur le serveur cible pour qu’ils correspondent à ceux sur le serveur source.
  • Répliquez les fonctionnalités de gestion de serveur suivantes du serveur unique source vers le serveur flexible cible :
    • Attributions de rôles, Rôles, Affectations de refus, administrateurs classiques, Contrôle d’accès (IAM)
    • Verrous (lecture seule et suppression)
    • Alertes
    • Tâches
    • Alertes Resource Health

Configurer DMS

Une fois votre serveur flexible cible déployé et configuré, vous devez ensuite configurer DMS pour migrer votre serveur unique vers un serveur flexible.

Inscrire le fournisseur de ressources

Pour inscrire le fournisseur de ressources Microsoft.DataMigration, procédez comme suit.

1. Avant de créer votre première instance DMS, connectez-vous au Portail Azure, puis recherchez et sélectionnez Abonnements.

   

2. Sélectionnez l’abonnement que vous souhaitez utiliser pour créer l’instance DMS, puis sélectionnez Fournisseurs de ressources.

   

3. Recherchez le terme « Migration » puis, pour Microsoft.DataMigration, sélectionnez Inscrire.

   

Créer une instance de Database Migration Service (DMS)

1. Dans le portail Azure, sélectionnez + Créer une ressource, recherchez le terme « Azure Database Migration Service », puis sélectionnez Azure Database Migration Service dans la liste déroulante.

   

2. Dans l’écran Azure Database Migration Service, sélectionnez Créer.

   

3. Dans la page Sélectionner le scénario de migration et Database Migration Service, sous Scénario de migration, sélectionnez Azure Database pour MySQL - Serveur unique comme type de serveur source, sélectionnez Azure Database pour MySQL comme type de serveur cible, puis sélectionnez Sélectionner.

   

4. Dans la page Créer un service de migration, sous l’onglet Informations de base, sous Détails du projet, sélectionnez l’abonnement approprié, puis sélectionnez un groupe de ressources existant ou créez-en un.

5. Sous Détails de l’instance, spécifiez un nom pour le service, sélectionnez une région, puis vérifiez que Azure est sélectionné comme mode de service.

6. À droite de Niveau tarifaire, sélectionnez Configurer le niveau.

   

7. Dans la page Configurer, sélectionnez le niveau tarifaire Premium avec 4 vCores pour votre instance DMS, puis sélectionnez Appliquer.

   Le DMS Premium à 4 vCores est gratuit pendant 6 mois (183 jours) à compter de la date de création du service DMS avant toute facturation. Pour plus d’informations sur les coûts et les niveaux tarifaires de DMS, consultez la page de tarification.

   

   Ensuite, nous devons spécifier le réseau virtuel qui fournira à l’instance DMS un accès au serveur unique source et au serveur flexible cible.

8. Dans la page Créer un service de migration, sélectionnez Suivant : Mise en réseau >>.

9. Sous l’onglet Mise en réseau, sélectionnez un réseau virtuel existant dans la liste ou indiquez le nom du nouveau réseau virtuel à créer, puis sélectionnez Vérifier + créer.

   Pour plus d’informations, consultez l’article Créer un réseau virtuel à l’aide du Portail Azure.

   

   Votre réseau virtuel doit être configuré avec l’accès au serveur unique source et au serveur flexible cible. Veillez donc à :

   • Créer une règle de pare-feu au niveau du serveur ou configurer des points de terminaison de service de réseau virtuel pour les serveurs Azure Database pour MySQL cibles afin d’autoriser le réseau virtuel pour Azure Database Migration Service à accéder aux bases de données source et cible.

   • Vérifier que les règles de groupe de sécurité réseau (NSG) de votre réseau virtuel ne bloquent pas le port de sortie 443 de ServiceTag pour ServiceBus, Storage et Azure Monitor. Pour plus d’informations sur le filtrage du trafic de groupe de sécurité réseau de réseau virtuel Azure, consultez Filtrer le trafic réseau avec les groupes de sécurité réseau.

   Si vous souhaitez ajouter des étiquettes au service, commencez par sélectionner Suivant : Étiquettes pour passer d’abord à l’onglet Étiquettes. L’ajout d’étiquettes au service est facultatif.

10. Accédez à l’onglet Vérifier + créer, passez en revue les configurations, affichez les conditions, puis sélectionnez Créer.

    

    Le déploiement de votre instance de DMS commence maintenant. Le message Le déploiement est en cours s’affiche pendant quelques minutes, puis le message devient Votre déploiement a été effectué.

11. Sélectionnez Accéder à la ressource.

    

12. Identifiez l’adresse IP de l’instance DMS depuis la page vue d’ensemble des ressources et créez une règle de pare-feu pour votre serveur unique source et votre serveur flexible cible qui répertorie l’adresse IP de l’instance DMS.

Créer un projet de migration

Pour créer un projet de migration, procédez comme suit.

1. Dans le portail Azure, sélectionnez Tous les services, recherchez Azure Database Migration Service, puis sélectionnez Azure Database Migration Services.

   

2. Dans les résultats de la recherche, sélectionnez l’instance DMS que vous avez créée, puis sélectionnez + Nouveau projet de migration.

   

3. Dans la page Nouveau projet de migration, spécifiez un nom pour le projet. Dans la zone de sélection Type de serveur source, sélectionnez Azure Database pour MySQL – Serveur unique. Dans la zone de sélection Type de serveur cible, sélectionnez Azure Database pour MySQL. Dans la zone de sélection Type d’activité de migration, sélectionnez Migration hors connexion, puis sélectionnez Créer et exécuter une activité.

   La sélection de Créer un projet uniquement comme type d’activité de migration ne crée que le projet de migration ; vous pouvez ensuite exécuter le projet de migration ultérieurement.

   

Configurer le projet de migration

Pour configurer votre projet de migration DMS, procédez comme suit.

1. Pour poursuivre la migration hors connexion, avant de configurer Sélectionner une source à l’écran, ouvrez un nouvel onglet de fenêtre et accédez à la page Vue d’ensemble de votre serveur source sur le Portail Azure, puis passez au panneau Paramètres du serveur. Configurez la valeur du paramètre de serveur read_only pour le serveur source sur ON.

   Le fait de définir le serveur source en mode lecture seule en mettant à jour le paramètre de serveur avant de commencer la migration empêche les opérations d’écriture/de suppression sur le serveur source pendant la migration, ce qui garantit l’intégrité des données de la base de données cible à mesure que la source est migrée.

   Par ailleurs, si vous effectuez une migration en ligne, vous devriez activer la case à cocher Activer la cohérence transactionnelle sur l’écran Sélectionner source. Pour plus d’informations sur la sauvegarde cohérente, consultez Migration de données MySQL vers Azure Database pour MySQL – Capture instantanée cohérente MySQL.

2. Revenez à l’écran de configuration de votre projet de migration et, dans l’écran Sélectionner une source, spécifiez les détails de connexion pour l’instance MySQL source.

   

3. Sélectionnez Suivant : Sélectionner la cible>> puis, dans l’écran Sélectionner la cible, spécifiez les détails de connexion du serveur flexible cible.

   

4. Sélectionnez Suivant : Sélectionner des bases de données>> puis, sous l’onglet Sélectionner des bases de données, sous [Préversion] Sélectionner des objets serveur, sélectionnez les objets serveur que vous souhaitez migrer.

   

5. Dans la section Sélectionner des bases de données, sous Base de données source, sélectionnez la ou les bases de données à migrer.

   Les objets non de table dans la ou les bases de données que vous avez spécifiées seront migrés, tandis que les éléments que vous n’avez pas sélectionnés seront ignorés.

6. Sélectionnez Suivant : Sélectionnez des bases de données>> pour accéder à l’onglet Sélectionner des tables.

   Avant de remplir l’onglet, DMS extrait les tables de la ou des bases de données sélectionnées sur la source et la cible, puis détermine si la table existe et contient des données.

7. Sélectionnez les tables que vous souhaitez migrer.

   Si vous sélectionnez une table dans la base de données source qui n’existe pas dans la base de données cible, la zone sous Migrer le schéma est sélectionnée par défaut. Pour les tables qui existent dans la base de données cible, une note indique que la table sélectionnée contient déjà des données et qu’elle sera tronquée. En outre, si le schéma d’une table sur le serveur cible ne correspond pas au schéma sur le serveur source, la table sera supprimée avant de continuer la migration.

   

   DMS valide vos entrées et, si la validation réussit, vous pourrez démarrer la migration.

8. Après avoir configuré la migration du schéma, sélectionnez Vérifier et démarrer la migration.

   Remarque

   Vous devez uniquement accéder à l’onglet Configurer les paramètres de migration si vous essayez de résoudre des problèmes de migrations défaillantes.

9. Dans l’onglet Résumé, dans la zone de texte Nom de l’activité, spécifiez un nom pour l’activité de migration, puis examinez le résumé pour vous assurer que les détails de la source et de la cible correspondent à ceux que vous avez spécifiés précédemment.

   

10. Sélectionnez Démarrer la migration.

    La fenêtre d’activité de migration s’affiche, et le champ État de l’activité présente la valeur Initialisation en cours. La valeur État passe à En cours d’exécution au démarrage des migrations des tables.

Surveiller la migration

1. Dans l’écran de l’activité de migration, sélectionnez Actualiser pour mettre à jour l’affichage et afficher la progression et le nombre de tables terminées.

2. Pour afficher l’état de chaque table pendant la migration, sélectionnez le nom de la base de données, puis sélectionnez Actualiser pour mettre à jour l’affichage.

3. Sélectionnez Actualiser pour mettre à jour l'affichage jusqu'à ce que l'État de la migration soit Terminé.

   

Effectuer des activités de post-migration

Lorsque la migration est terminée, veillez à effectuer les activités de post-migration suivantes.

• Effectuez des tests d’intégrité de l’application dans la base de données cible pour certifier la migration.

• Mettez à jour la chaîne de connexion pour qu’elle pointe vers le nouveau serveur flexible cible.

• Supprimez le serveur unique source une fois que êtes assuré de la continuité de l’application.

• Si vous avez appliqué un scale-up au serveur flexible cible pour une migration plus rapide, rétablissez-le en sélectionnant la taille de calcul et le niveau de calcul du serveur flexible cible en fonction du niveau tarifaire du serveur unique source et des VCores, en vous basant sur le tableau suivant.

  Niveau tarifaire du serveur unique	VCores du serveur unique	Taille de calcul du serveur flexible	Niveau de calcul du serveur flexible
  De base	1	Expansible	Standard_B1s
  De base	2	Expansible	Standard_B2s
  Usage général	4	Usage général	Standard_D4ds_v4
  Usage général	8	Usage général	Standard_D8ds_v4

  • Nettoyer les ressources Data Migration Service :

    1. Dans le portail Azure, sélectionnez Tous les services, recherchez Azure Database Migration Service, puis sélectionnez Azure Database Migration Services.
    2. Sélectionnez votre instance du service de migration dans les résultats de la recherche, puis sélectionnez Supprimer le service.
    3. Dans la boîte de dialogue de confirmation, dans la zone de texte TAPER LE NOM DU SERVICE DE MIGRATION DE BASE DE DONNÉES, spécifiez le nom du service, puis sélectionnez Supprimer.

Bonnes pratiques en matière de migration

Lorsque vous effectuez une migration, veillez à garder à l’esprit les meilleures pratiques suivantes.

• Lors de la découverte et de l’évaluation, tenez compte de la référence SKU du serveur, de l’utilisation du processeur, du stockage, des tailles de base de données et de l’utilisation des extensions comme étant certaines des données critiques facilitant les migrations.

• Planifiez le mode de migration pour chaque base de données. Pour les migrations plus simples et les bases de données plus petites, envisagez le mode hors connexion.

• Effectuez des migrations de test avant de migrer pour l’environnement de production.

  • Les migrations de test sont importantes pour vous assurer que vous couvrez tous les aspects de la migration de base de données, y compris les tests d’application. Si vous effectuez une migration vers une version plus élevée de MySQL, testez la compatibilité de l’application.
  • Une fois les tests terminés, vous pouvez migrer les bases de données de production. À ce stade, vous devez finaliser la journée et l’heure de la migration de production. Dans l’idéal, l’application est peu utilisée à ce moment-là. Toutes les parties prenantes qui doivent être impliquées doivent être disponibles et prêtes. La migration de production nécessite une surveillance étroite.

• Redirigez toutes les applications dépendantes pour accéder à la nouvelle base de données principale et ouvrez les applications pour une utilisation en production.

• Une fois que l’application commence à s’exécuter sur le serveur flexible cible, surveillez les performances de la base de données de près pour voir si une optimisation des performances est requise.

Contenu connexe

• Qu’est-ce que Azure Database pour MySQL – Serveur flexible ?
• Qu’est-ce que Azure Database Migration Service ?
• Résoudre les problèmes et erreurs courants d’Azure Database Migration Service (classique)
• Résoudre les erreurs DMS lors de la connexion aux bases de données source