Partager via

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

  • Article

Notes

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

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 allez apprendre à :

  • 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 ou utilisez une instance existante d’Azure Database pour MySQL – Serveur unique (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é, créez un réplica en lecture pour votre instance de serveur unique, puis supprimez-le. Cette opération définit le paramètre log_bin sur ON et vous pouvez ensuite déclencher l’opération de 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, configurez le paramètre binlog_expire_logs_seconds 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. 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. De plus, les déclencheurs sont uniquement migrés pendant le basculement et vous devez être en mesure de voir les déclencheurs créés après le basculement.
    • 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.

  • 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
      • SET PASSWORD
    • 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

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

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

    Capture d’écran de la sélection d’abonnements dans Place de marché Azure.

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

    Capture d’écran de la sélection d’un fournisseur de ressources.

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

    Capture d’écran de l’inscription de votre fournisseur de ressources.

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.

    Capture d’écran de la recherche d’Azure Database Migration Service.

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

    Capture d’écran de la création d’une instance Azure Database Migration Service.

  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.

    Capture d’écran de la sélection du scénario de migration.

  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.

    Capture d’écran de la sélection de 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.

    Capture d’écran de la sélection du niveau tarifaire.

    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.

    Capture d’écran de la sélection de Mise en réseau.

    [!IMPORTANT]
    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.

    Notes

    Pour ajouter des étiquettes au service, passez à l’onglet Étiquettes en sélectionnant Suivant : É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.

    Capture d’écran d’une sélection de Vérifier + 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.

    Capture d’écran de la sélection de 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.

    Capture d’écran de la localisation de toutes les instances d’Azure Database Migration Service.

  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.

    Capture d’écran de la sélection d’un 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 – Serveur flexible. Dans la zone de sélection Type d’activité de migration, sélectionnez Migration de données en ligne, puis Créer et exécuter une activité.

    Notes

    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.

    Capture d’écran de la création d’un nouveau projet de migration.

Configurer le projet de migration

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

  1. Dans l’écran Sélectionner une source, recherchez 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 source.

    Capture d’écran de l’ajout de détails de la source.

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

    Capture d’écran de la sélection d’une cible.

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

    Remarque

    Il existe désormais une option Migrer toutes les bases de données applicables. Lorsqu’elle est sélectionnée, cette option migre toutes les bases de données et tables créées par l’utilisateur. É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.

    Capture d’écran de la sélection d’une base de données.

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

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

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

    Capture d’écran d’une sélection de tables.

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

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

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

    Capture d’écran de la sélection d’un résumé.

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

    Capture d’écran d’un état En cours d’exécution.

Surveiller la migration

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

    Capture d'écran d'une migration de charge initiale terminée.

    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.

  2. Sélectionnez Actualiser pour mettre à jour l’affichage et afficher les secondes en retard sur la source si nécessaire.

    Capture d’écran de la supervision d’une migration.

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

  4. Suivez les étapes de la fenêtre de basculement avant d’être prêt à effectuer un basculement.

  5. Après avoir effectué toutes les étapes, sélectionnez Confirmer, puis Appliquer.

    Capture d’écran de l’exécution d’un basculement.

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.

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

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

Contenu connexe