Tutoriel : Migrer un serveur MySQL vers un serveur flexible Azure Database pour MySQL en ligne à l’aide de DMS via le portail Azure

2025-05-05

Remarque

Cet article contient des références au terme esclave, un terme que Microsoft n’utilise plus. Lorsque le terme sera supprimé du logiciel, nous le supprimerons de cet article.

Vous pouvez migrer votre serveur MySQL de services cloud ou local vers un serveur flexible Azure Database pour MySQL à 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 en ligne d’un exemple de base de données d’un serveur MySQL local vers Azure Database pour MySQL – Serveur flexible (les deux exécutant la version 5.7) à l’aide d’une activité de migration DMS.

Remarque

La migration en ligne Database Migration Service (DMS) est désormais en disponibilité générale. DMS prend en charge la migration vers des versions MySQL 5.7 et 8.0, et prend également en charge la migration de serveurs MySQL de version inférieure (v5.6 et versions ultérieures) vers des serveurs de version supérieure. 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 à :

Implémenter les meilleures pratiques pour créer un serveur flexible afin d’accélérer les chargements de données à l’aide de DMS.
Créer et configurer un serveur flexible cible.
Créer une instance DMS.
Créer un projet de migration MySQL dans DMS.
Migrer un schéma MySQL à l’aide de DMS.
Exécuter la migration.
Surveiller la migration.
Effectuer des étapes de post-migration.
Implémenter les meilleures pratiques pour effectuer une migration.

Prérequis

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

Créez une instance MySQL existante ou utilisez-en une existante (le serveur source).
Pour effectuer la migration en ligne de manière correcte, vérifiez que les conditions préalables suivantes sont remplies :
- Utilisez l’outil en ligne de commande MySQL de votre choix pour vérifier que log_bin est activé sur le serveur source en exécutant la commande : SHOW VARIABLES LIKE 'log_bin'. Si log_bin n’est pas activé, veillez à l’activer avant de démarrer la migration.
- Vérifiez que l’utilisateur dispose des autorisations « REPLICATION CLIENT » et « REPLICATION SLAVE » sur le serveur source pour la lecture et l’application du journal binaire.
- Si vous ciblez une migration en ligne, vous devrez configurer l’expiration binlog sur le serveur source pour veiller à ce que les fichiers binlog ne soient pas purgés avant que le réplica valide les modifications. Nous vous recommandons au moins deux jours pour commencer. Le paramètre dépend de la version de votre serveur MySQL. Pour MySQL 5.7, le paramètre est expire_logs_days (par défaut, il est défini sur 0, pas de purge automatique). Pour MySQL 8.0, c’est binlog_expire_logs_seconds (par défaut, il est défini sur 30 jours). Une fois un basculement réussi, vous pouvez réinitialiser la valeur.
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.
DMS ne prend pas en charge la migration de la clause DEFINER pour les objets. Tous les types d’objets ayant des définitions sur la source sont rejetés et, après la migration, le paramètre de definer par défaut pour tous les objets qui prennent en charge une clause de definer et qui sont créés pendant la migration du schéma, est 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.
La prise en charge de la migration en ligne est limitée au format binlog ROW.
Le service Azure Database pour MySQL – Serveur flexible ne prend pas en charge des bases de données de cas mixtes, celles se situant sur la source ne sont pas incluses pour une migration en ligne.
La migration en ligne prend désormais en charge la réplication d'instructions DDL lors de la migration vers un serveur cible du Serveur flexible Azure Database pour MySQL v8.0.
- La réplication des instructions est prise en charge pour les bases de données, les tables et les objets de schéma (vues, routines, déclencheurs) sélectionnés pour la migration de schéma lors de la configuration d’une activité de migration Azure DMS. Les instructions de définition et d’administration des données pour les bases de données, les tables et les objets de schéma qui ne sont pas sélectionnés ne seront pas répliqués. La sélection d’un serveur entier pour la migration répliquera les instructions pour la totalité des tables, des bases de données et des objets de schéma créés sur le serveur source une fois la charge initiale terminée.
- La réplication des instructions Azure DMS prend en charge toutes les instructions de définition des données répertoriées ici, à l’exception des commandes suivantes :
  - Instructions LOGFILE GROUP
  - Instructions SERVER
  - Instructions SPATIAL REFERENCE SYSTEM
  - Instructions TABLESPACE
- La réplication des instructions Azure DMS prend en charge toutes les instructions Administration des données : gestion des comptes répertoriées ici, à l’exception des commandes suivantes :
  - SET DEFAULT ROLE
  - DÉFINIR LE MOT DE PASSE
- La réplication des instructions Azure DMS prend en charge toutes les instructions Administration des données : maintenance des tables répertoriées ici, à l’exception des commandes suivantes :
  - REPAIR TABLE
  - ANALYZE TABLE
  - CHECKSUM TABLE
- L’instruction Azure DMS ou la réplication binlog ne prend pas en charge la syntaxe suivante : « CREATE TABLE b as SELECT * FROM a; ». La réplication de ce DDL entraîne l’erreur suivante : « Seules les instructions BINLOG INSERT, COMMIT et ROLLBACK sont autorisées après CREATE TABLE avec l’instruction START TRANSACTION ».
La durée de migration peut être affectée par la maintenance du calcul sur le serveur principal, ce qui peut réinitialiser la progression.

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 de la configuration du serveur MySQL source.

¹ Pour la migration, en guise de bonne pratique, sélectionnez calcul à usage général 16 vCores ou version ultérieure pour le serveur flexible cible pour des migrations plus rapides. Effectuez un scale-back à la taille de calcul souhaitée pour le serveur cible une fois la migration terminée.
La version MySQL du serveur flexible cible doit être supérieure ou égale à celle du serveur MySQL 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, sélectionnez Accès privé ; sinon, sélectionnez Accès public configurer les règles de pare-feu pour autoriser l’accès au serveur flexible cible.

Créer et configurer le serveur flexible cible

Avec ces bonnes 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.
Configurez le nouveau serveur flexible cible comme suit :
- L’utilisateur effectuant la migration doit disposer des autorisations suivantes :
  - Vérifiez que l’utilisateur dispose de l’autorisation « REPLICATION_APPLIER » ou « BINLOG_ADMIN » sur le serveur cible pour l’application du journal bin.
  - Vérifiez que l’utilisateur dispose de l’autorisation « REPLICATION SLAVE » sur le serveur cible.
  - Vérifiez que l’utilisateur dispose des autorisations « REPLICATION CLIENT » et « REPLICATION SLAVE » sur le serveur source pour la lecture et l’application du journal binaire.
  - Pour créer des tables sur la cible, l’utilisateur doit disposer du privilège « CREATE ».
  - Si vous migrez une table avec les options de partition « DATA DIRECTORY » ou « INDEX DIRECTORY », l’utilisateur doit disposer du privilège « FILE ».
  - 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 ».
- 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.

Configurer DMS

Avec votre serveur flexible cible déployé et configuré, vous devez ensuite configurer DMS pour migrer votre serveur MySQL source vers un serveur flexible.

Inscrire le fournisseur de ressources

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

Avant de créer votre première instance DMS, connectez-vous au Portail Azure, puis recherchez et sélectionnez Abonnements.
Sélectionnez l’abonnement que vous souhaitez utiliser pour créer l’instance DMS, puis sélectionnez Fournisseurs de ressources.
Recherchez le terme « Migration » puis, pour Microsoft.DataMigration, sélectionnez Inscrire.

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

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.
Dans l’écran Azure Database Migration Service, sélectionnez Créer.
Dans la page Sélectionner le scénario de migration et Database Migration Service, sous Scénario de migration, sélectionnez MySQL comme type de serveur source, puis sélectionnez Azure Database pour MySQL comme type de serveur cible, puis sélectionnez Sélectionner.
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.
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.
À droite de Niveau tarifaire, sélectionnez Configurer le niveau.
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 flexible cible.
Dans la page Créer un service de migration, sélectionnez Suivant : Mise en réseau >>.
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 MySQL source et au serveur flexible cible. Veillez donc à :
- Créez une règle de pare-feu au niveau du serveur ou configurez la mise en réseau pour le serveur MySQL source et 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.
Remarque

Pour ajouter des étiquettes au service, passez à l’onglet Étiquettes en sélectionnant Suivant : Étiquettes. L’ajout d’étiquettes au service est facultatif.
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é.
Sélectionnez Accéder à la ressource.
Identifiez l’adresse IP de l’instance DMS depuis la page de vue d’ensemble des ressources et créez une règle de pare-feu pour votre serveur MySQL source et votre serveur flexible cible en plaçant l’adresse IP de l’instance DMS dans la liste d’autorisation.

Créer un projet de migration

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

Dans le portail Azure, sélectionnez Tous les services, recherchez Azure Database Migration Service, puis sélectionnez Azure Database Migration Services.
Dans les résultats de la recherche, sélectionnez l’instance DMS que vous avez créée, puis sélectionnez + Nouveau projet de migration.
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 MySQL. Dans la zone de sélection Type de serveur cible, sélectionnez Serveur flexible Azure Database pour MySQL. Dans la zone de sélection Type d’activité de migration, sélectionnez Migration de données en ligne, 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.

Dans l’écran Sélectionner une source , nous devons nous assurer que DMS se trouve dans le réseau virtuel qui dispose d’une connectivité au serveur source. Ici, vous allez entrer le nom du serveur source, le port du serveur, le nom d’utilisateur et le mot de passe sur votre serveur source.
Sélectionnez Suivant : Sélectionner la cible>>, puis, dans l’écran Sélectionner une cible , localisez le serveur en fonction de l’abonnement, de l’emplacement et du groupe de ressources. Le nom d’utilisateur est renseigné automatiquement, puis fournissez le mot de passe du serveur flexible cible.
Sélectionnez Suivant : Sélectionner la bases de données>>, puis, sous l’onglet Sélectionner des bases de données, sous Options de migration du serveur, sélectionnez Migrer toutes les bases de données applicables ou, sous Sélectionner des bases de données, sélectionnez les objets serveur que vous souhaitez migrer.

Une option Migrer toutes les bases de données applicables est désormais disponible. Lorsque cette option est sélectionnée, toutes les bases de données et tables créées par l’utilisateur sont migrées. Étant donné que le service Azure Database pour MySQL – Serveur flexible ne prend pas en charge des bases de données de cas mixtes, celles se situant sur la source ne sont pas incluses pour une migration en ligne.
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. Vous ne pouvez sélectionner que les bases de données source et cible dont les noms correspondent à celles sur le serveur source et cible.

Si vous sélectionnez une base de données sur le serveur source qui n’existe pas sur le serveur cible, elle est créée sur le serveur cible.
Sélectionnez Suivant : Sélectionnez des tables>> 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.
Sélectionnez les tables que vous souhaitez migrer.

Si la table source sélectionnée n’existe pas sur le serveur cible, le processus de migration en ligne garantit que le schéma de table et les données sont migrés vers le serveur cible.

DMS valide vos entrées et, si la validation réussit, vous pourrez démarrer la migration.
Après avoir configuré la migration du schéma, sélectionnez Vérifier et démarrer la migration.

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.
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.
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

Quand l’activité de chargement initial est terminée, accédez à l’onglet Chargement initial pour afficher l’état d’achèvement et le nombre de tables terminées.

Quand l’activité de Chargement initial est terminée, vous accédez automatiquement à l’onglet Répliquer les modifications des données. Vous pouvez suivre la progression de la migration à mesure que l’écran est actualisé automatiquement toutes les 30 secondes.
Sélectionnez Actualiser pour mettre à jour l’affichage et afficher les secondes en retard sur la source si nécessaire.
Surveillez la valeur Secondes en retard sur la source et dès qu’elle approche 0, passez au basculement en accédant à l’onglet du menu Démarrer le basculement en haut de l’écran d’activité de migration.
Suivez les étapes de la fenêtre de basculement avant d’être prêt à effectuer un basculement.
Après avoir effectué toutes les étapes, sélectionnez Confirmer, puis Appliquer.

Effectuer des activités de post-migration

Quand 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.
Si vous avez augmenté la taille du serveur flexible cible pour une migration plus rapide, réduisez-la en sélectionnant la taille et le niveau de calcul du serveur flexible en fonction de la configuration du serveur MySQL source.
- Pour nettoyer les ressources DMS, 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. 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 de l’instance, puis sélectionnez Supprimer.

Bonnes pratiques en matière de migration

Quand vous effectuez une migration, veillez à tenir compte des bonnes 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.
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. Comme meilleure pratique, il est recommandé de commencer par exécuter une migration entièrement à des fins de test. Une fois qu’une migration nouvellement démarrée entre dans la phase Répliquer des modifications des données avec un décalage minimal, utilisez uniquement votre cible de serveur flexible pour l’exécution de charges de travail de test. Utilisez cette cible pour tester l’application afin de garantir les performances et les résultats attendus. 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. Pour une migration en ligne, la réplication doit être effectuée avant d’effectuer le basculement, afin d’éviter toute perte de données.
Redirigez toutes les applications dépendantes pour accéder à la nouvelle base de données primaire et rendre le serveur source en lecture seule. Ouvrez ensuite 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.