Data Transmission Service:Migrer Amazon Aurora MySQL vers PolarDB for MySQL

Prérequis

• Assurez-vous que DTS peut se connecter à la base de données source Amazon Aurora MySQL.

  Nous vous recommandons de définir l'option Public access sur Yes dans les paramètres réseau et de sécurité de votre base de données source. Cela vous permet de définir la méthode Access Method sur Public IP Address lors de la configuration de la tâche.

  Remarque

  Pour connecter votre base de données Amazon Aurora MySQL à DTS via une passerelle VPN, consultez la rubrique Connecter un VPC Alibaba Cloud à un VPC AWS.

• Vous avez créé un cluster Alibaba Cloud PolarDB for MySQL. Pour plus de détails, consultez la rubrique Achat personnalisé.

• L'espace de stockage du cluster Alibaba Cloud PolarDB for MySQL doit être supérieur à l'espace de stockage utilisé par le cluster Amazon Aurora MySQL.

Notes

• Lors d'une migration complète des données, DTS consomme des ressources de lecture et d'écriture sur les bases de données source et de destination, ce qui augmente leur charge. Si vos bases de données présentent des performances médiocres, des spécifications faibles ou des charges de travail élevées (par exemple, si la base de données source contient de nombreuses requêtes SQL lentes ou des tables sans clés primaires, ou si des interblocages se produisent dans la base de données de destination), cette augmentation de la charge peut solliciter excessivement vos bases de données, voire provoquer des interruptions de service. Effectuez la migration des données pendant les heures creuses, par exemple lorsque l'utilisation du CPU des deux bases de données est inférieure à 30 %.

• Si une table source ne possède ni clé primaire ni contrainte unique, des données en double peuvent apparaître dans la base de données de destination.

• Pour les colonnes FLOAT ou DOUBLE, DTS lit les valeurs à l'aide de la fonction ROUND(COLUMN,PRECISION). Si aucune précision n'est explicitement définie, DTS utilise une précision de 38 chiffres pour FLOAT et de 308 chiffres pour DOUBLE. Assurez-vous que cette précision par défaut répond aux exigences de votre activité.

• Si le nom de la base de données source ne respecte pas les conventions de nommage de PolarDB for MySQL, vous devez créer la base de données dans PolarDB for MySQL avant de configurer la tâche de migration.

  Remarque

  Pour plus d'informations sur les conventions de nommage de PolarDB for MySQL et sur la création d'une base de données, consultez la rubrique Créer une base de données.

• En cas d'échec d'une tâche de migration, DTS tente automatiquement de la reprendre. Avant de basculer vos services vers l'instance de destination, vous devez arrêter ou libérer la tâche. Cela empêche une tâche reprise d'écraser les données de l'instance de destination avec celles de la base de données source.

Facturation

Types de migration

• Migration de structure

  DTS migre la structure des objets à migrer vers Alibaba Cloud PolarDB for MySQL. Actuellement, DTS prend en charge la migration de structure pour les tables, les vues, les déclencheurs, les procédures stockées et les fonctions stockées. La migration de structure pour les événements n'est pas prise en charge.

  Remarque

  • Lors de la migration de structure, DTS convertit DEFINER en INVOKER dans les vues, les procédures stockées et les fonctions stockées.

  • Étant donné que DTS ne migre pas les informations utilisateur, vous devez accorder au compte invoquant les autorisations de lecture et d'écriture sur les vues, les procédures stockées et les fonctions stockées de la base de données de destination.

• Migration complète des données

  DTS migre toutes les données existantes des objets sélectionnés depuis Amazon Aurora for MySQL vers Alibaba Cloud PolarDB for MySQL.

  Remarque

  La migration complète des données utilise des opérations INSERT concurrentes, ce qui peut entraîner une fragmentation des tables dans l'instance de destination. Par conséquent, l'espace de tablespace dans l'instance de destination peut être plus grand que dans l'instance source.

• Migration incrémentielle des données

  Après la migration complète des données, DTS lit le journal binaire (binlog) depuis Amazon Aurora for MySQL pour synchroniser les modifications incrémentielles des données vers Alibaba Cloud PolarDB for MySQL. Ce processus assure une migration fluide de la base de données et minimise les temps d'arrêt des applications.

Autorisations des comptes de base de données

Pour créer un compte de base de données et accorder les privilèges requis :

• Pour Amazon Aurora MySQL, consultez la rubrique Créer un compte pour une base de données MySQL auto-gérée et configurer la journalisation binaire.

• Pour Alibaba Cloud PolarDB for MySQL, consultez la rubrique Créer et gérer des comptes de base de données.

Prérequis

1. Connectez-vous à la console Amazon Aurora.

2. Dans le volet de navigation de gauche, cliquez sur Database.

3. Cliquez sur l'ID de base de données du nœud dont le Role est Writer instance.

4. Sous l'onglet Connectivity & security, cliquez sur le nom du groupe de sécurité VPC.

5. Sur la page Security Groups, cliquez sur l'ID de groupe de sécurité cible.

6. Sous l'onglet Inbound rules, cliquez sur Edit inbound rules.

7. Sur la page Edit inbound rules, cliquez sur Add rule, ajoutez les blocs CIDR des serveurs DTS dans la région de la base de données de destination, puis cliquez sur Save rules. Pour plus d'informations sur les blocs CIDR DTS, consultez la rubrique Ajouter les adresses IP des serveurs DTS à une liste blanche.

   Remarque

   • Ajoutez uniquement les blocs CIDR des serveurs DTS situés dans la région de la base de données de destination. Par exemple, si votre base de données source se trouve dans la région Singapour et votre base de données de destination dans la région Chine (Hangzhou), vous devez uniquement ajouter les blocs CIDR des serveurs DTS de la région Chine (Hangzhou).

   • Vous pouvez ajouter plusieurs blocs CIDR à une seule règle.

   • Pour plus d'informations, consultez la documentation officielle AWS ou contactez le support AWS.

8. Connectez-vous à la base de données Amazon Aurora MySQL et définissez la période de rétention des journaux binaires. Ignorez cette étape si la migration incrémentielle des données n'est pas requise.

   call mysql.rds_set_configuration('binlog retention hours', 24);

   Remarque

   • Cette commande définit la période de rétention des journaux binaires à 24 heures. La période de rétention maximale est de 168 heures (7 jours).

   • La fonctionnalité de journal binaire doit être activée pour Amazon Aurora MySQL, et le paramètre binlog_format doit être défini sur ROW. Si vous utilisez MySQL 5.6 ou une version ultérieure, le paramètre binlog_row_image doit être défini sur FULL. Pour plus d'informations, reportez-vous à la documentation officielle Amazon ou contactez le support technique Amazon.

Procédure (nouvelle console)

1. Accédez à la page de liste des tâches de migration pour la région de destination en utilisant l'une des méthodes suivantes.

   Depuis la console DTS

   1. Connectez-vous à la .

   2. Dans le volet de navigation de gauche, cliquez sur Data Migration.

   3. Dans le coin supérieur gauche de la page, sélectionnez la région où se trouve l'instance de migration.

   Depuis la console DMS

   Remarque

   Les opérations réelles peuvent varier selon le mode et la disposition de la console DMS. Pour plus d'informations, consultez Console en mode simple et Personnaliser la disposition et le style de la console DMS.

   1. Connectez-vous à la .

   2. Dans la barre de menu supérieure, choisissez Data + AI > Data Transmission (DTS) > Data MigrationData Migration > Data + AI > Data Transmission (DTS).

   3. À droite de Data Migration Tasks, sélectionnez la région où se trouve l'instance de migration.

2. Cliquez sur Create Task pour accéder à la page de configuration de la tâche.

3. Configurez les bases de données source et de destination.

   Avertissement

   Après avoir sélectionné les instances source et de destination, nous vous recommandons de lire attentivement les limites affichées en haut de la page. Dans le cas contraire, la tâche pourrait échouer ou entraîner une incohérence des données.

   Catégorie	Paramètre	Description
   N/A	Data Migration	DTS génère automatiquement un nom de tâche. Nous vous recommandons de spécifier un nom descriptif pour faciliter l'identification. Le nom n'a pas besoin d'être unique.
   Source Database	Create Task	Vous pouvez choisir d'utiliser ou non une instance existante, selon vos besoins. Si vous utilisez une instance existante, les informations de base de données ci-dessous sont renseignées automatiquement. Vous n'avez pas besoin de les saisir à nouveau. Si vous n'utilisez pas d'instance existante, vous devez configurer les informations de base de données ci-dessous. Remarque Dans la console DMS, vous pouvez cliquer sur Task Name pour enregistrer une base de données dans DMS. Pour plus d'informations, consultez ApsaraDB Data Ingestion et Enregistrer une base de données hébergée sur un service cloud tiers ou une base de données autogérée. Dans la console DTS, vous pouvez enregistrer une base de données dans DTS sur la page Database Connections ou sur la nouvelle page de configuration. Pour plus d'informations, consultez Gérer les connexions aux bases de données.
   	Select a DMS database instance.	Sélectionnez MySQL.
   	Access Method	Sélectionnez Database Type.
   	Instance Region	Sélectionnez la région où se trouve la base de données Amazon Aurora MySQL. Remarque Si la région où se trouve votre base de données Amazon Aurora MySQL n'est pas disponible dans la liste déroulante, sélectionnez la région la plus proche.
   	Domain Name or IP	Saisissez le point de terminaison de la base de données Amazon Aurora MySQL. Remarque Vous pouvez obtenir le point de terminaison de la base de données depuis la page Public IP Address de votre base de données Amazon Aurora MySQL.
   	Port	Saisissez le port de service de la base de données Amazon Aurora MySQL. Le port par défaut est 3306.
   	Basic Information	Saisissez le compte de base de données pour la base de données Amazon Aurora MySQL. Pour plus d'informations sur les autorisations requises, consultez Autorisations requises pour les comptes de base de données.
   	Database Password	Saisissez le mot de passe du compte de base de données.
   	Encryption	Sélectionnez Database Account ou SSL-encrypted selon vos besoins. Si le chiffrement SSL est désactivé pour votre base de données Amazon Aurora MySQL, sélectionnez Non-encrypted. Si le chiffrement SSL est activé pour votre base de données Amazon Aurora MySQL, sélectionnez Non-encrypted. Vous devez également télécharger le CA Certificate et saisir le CA Certificate Password.
   SSL-encrypted	Select a DMS database instance.	Vous pouvez choisir d'utiliser ou non une instance existante, selon vos besoins. Si vous utilisez une instance existante, les informations de base de données ci-dessous sont renseignées automatiquement. Vous n'avez pas besoin de les saisir à nouveau. Si vous n'utilisez pas d'instance existante, vous devez configurer les informations de base de données ci-dessous. Remarque Dans la console DMS, vous pouvez cliquer sur Add DMS Database Instance pour enregistrer une base de données dans DMS. Pour plus d'informations, consultez ApsaraDB Data Ingestion et Enregistrer une base de données hébergée sur un service cloud tiers ou une base de données autogérée. Dans la console DTS, vous pouvez enregistrer une base de données dans DTS sur la page Destination Database ou sur la nouvelle page de configuration. Pour plus d'informations, consultez Gérer les connexions aux bases de données.
   	Database Type	Sélectionnez Add DMS Database Instance.
   	Database Connections	Sélectionnez Alibaba Cloud Instance.
   	PolarDB for MySQL	Sélectionnez la région où se trouve l'instance PolarDB for MySQL de destination.
   	Access Method	Sélectionnez l'ID de l'instance PolarDB for MySQL de destination.
   	Database Account	Saisissez le compte de base de données pour l'instance PolarDB for MySQL de destination. Pour plus d'informations sur les autorisations requises, consultez Autorisations requises pour les comptes de base de données.
   	Instance Region	Saisissez le mot de passe du compte de base de données.
   	PolarDB Cluster ID	Sélectionnez un type de connexion selon vos besoins. Pour plus d'informations sur la fonctionnalité de chiffrement SSL, consultez Activer le chiffrement SSL.

4. Une fois la configuration terminée, cliquez sur Test Connectivity and Proceed en bas de la page. Dans la boîte de dialogue CIDR Blocks of DTS Servers qui s'affiche, cliquez sur Test Connectivity.

   Remarque

   Assurez-vous que les plages d'adresses IP du service DTS sont ajoutées automatiquement ou manuellement aux paramètres de sécurité des bases de données source et de destination afin d'autoriser l'accès depuis les serveurs DTS. Pour plus d'informations, consultez Ajouter les adresses IP des serveurs DTS à une liste d'autorisation.

5. Configurez les objets de la tâche.

   1. Sur la page Configure Objects, configurez les objets que vous souhaitez migrer.

      Paramètre	Description
      Database Password	Si vous devez uniquement effectuer une migration complète, sélectionnez à la fois Encryption et Test Connectivity and Proceed. Pour réaliser une migration sans interruption de service, sélectionnez CIDR Blocks of DTS Servers, Test Connectivity et Incremental Data Migration. Remarque Si vous ne sélectionnez pas Migration Types, assurez-vous qu'une base de données et des tables destinées à recevoir les données existent dans la base de données de destination. Vous pouvez également utiliser la fonctionnalité de mappage des noms d'objets dans la zone Schema Migration selon vos besoins. Si vous ne sélectionnez pas Full Data Migration, n'écrivez aucune nouvelle donnée dans l'instance source pendant la migration afin de garantir la cohérence des données.
      Method to Migrate Triggers in Source Database	Sélectionnez une méthode de migration des déclencheurs en fonction de vos exigences. Si les objets à migrer n'incluent pas de déclencheurs, vous pouvez ignorer cette étape. Pour plus d'informations, consultez Configurer la méthode de synchronisation ou de migration des déclencheurs. Remarque Ce paramètre est disponible uniquement lorsque vous sélectionnez Schema Migration pour les Migration Types.
      Schema Migration	Selected Objects : vérifie si des tables portant le même nom existent dans la base de données de destination. En l'absence de tables homonymes, la vérification préalable est validée. Si des tables portant le même nom existent, une erreur est signalée lors de la vérification préalable et la tâche de migration des données ne démarre pas. Remarque Si une table de la base de données de destination porte le même nom mais ne peut pas être facilement supprimée ou renommée, vous pouvez modifier le nom de la table dans la base de données de destination. Pour plus d'informations, consultez Mappage des noms d'objets. Incremental Data Migration : ignore la vérification des tables portant le même nom. Avertissement La sélection de l'option Ignore Errors and Proceed peut entraîner une incohérence des données et des risques opérationnels. Par exemple : Si les schémas de table sont identiques et qu'un enregistrement de la base de données de destination possède la même valeur de clé primaire qu'un enregistrement de la base de données source : Lors de la migration complète, DTS conserve l'enregistrement dans la base de données de destination. L'enregistrement provenant de la base de données source n'est pas migré. Lors de la migration incrémentielle, DTS ne conserve pas l'enregistrement dans la base de données de destination. L'enregistrement provenant de la base de données source écrase celui de la base de données de destination. Si les schémas de table sont différents, seules certaines colonnes de données peuvent être migrées, ou la migration peut échouer. Agissez avec prudence.
      Capitalization of Object Names in Destination Instance	Vous pouvez configurer la politique de sensibilité à la casse pour les noms des objets migrés, tels que les bases de données, les tables et les colonnes, dans l'instance de destination. Par défaut, l'option DTS default policy est sélectionnée. Vous pouvez également choisir de maintenir la sensibilité à la casse conforme à la politique par défaut de la base de données source ou de destination. Pour plus d'informations, consultez Sensibilité à la casse des noms d'objets dans la base de données de destination.
      Processing Mode of Conflicting Tables	Sélectionnez un ou plusieurs objets dans la section Precheck and Report Errors. Cliquez sur l'icône et ajoutez les objets à la section Ignore Errors and Proceed. Remarque Le niveau de granularité pour la sélection des objets de migration est le schéma, la table et la colonne. Si vous ne sélectionnez que des tables ou des colonnes comme objets de migration, les autres objets tels que les vues, les déclencheurs et les procédures stockées ne seront pas migrés vers la base de données de destination.
      Selected Objects	Pour modifier le nom d'un seul objet de migration dans l'instance cible, cliquez avec le bouton droit sur l'objet dans la zone Selected Objects. Pour plus d'informations, consultez Mapper les noms individuels de schéma, de table et de colonne. Pour modifier les noms de plusieurs objets de migration dans l'instance cible, cliquez sur Selected Objects dans le coin supérieur droit de la zone Source Objects. Pour plus d'informations, consultez Mapper plusieurs noms de schéma, de table et de colonne. Remarque Si vous utilisez la fonctionnalité de mappage des noms d'objets, la migration d'autres objets dépendant de l'objet mappé peut échouer. Pour filtrer les données à l'aide d'une clause WHERE, cliquez avec le bouton droit sur la table à migrer dans la zone Source Objects et définissez les conditions de filtrage dans la boîte de dialogue qui s'affiche. Pour obtenir des instructions, consultez Configurer les conditions de filtrage. Pour sélectionner les opérations SQL à migrer au niveau de la base de données ou de la table, cliquez avec le bouton droit sur l'objet dans la zone Selected Objects et sélectionnez les opérations SQL souhaitées dans la boîte de dialogue qui s'affiche.

   2. Cliquez sur Next: Advanced Settings pour configurer les paramètres avancés.

      Paramètre	Description
      Dedicated Cluster for Task Scheduling	Par défaut, DTS planifie les tâches sur un cluster partagé. Aucune sélection n'est requise. Si vous souhaitez une exécution plus stable des tâches, vous pouvez acheter un cluster dédié pour exécuter les tâches de migration DTS.
      Select the engine type of the destination database	Sélectionnez le type de moteur pour la base de données de destination. Batch Edit : moteur de stockage par défaut. Selected Objects : moteur de stockage de base de données pour le traitement transactionnel en ligne (OLTP).
      Selected Objects	Si vous utilisez Data Management (DMS) ou gh-ost pour effectuer des modifications DDL en ligne dans la base de données source, vous pouvez choisir de migrer ou non les données issues des tables temporaires générées par ces modifications DDL en ligne. Important Les tâches DTS ne prennent pas en charge l'utilisation d'outils tels que pt-online-schema-change pour effectuer des modifications DDL en ligne. Dans le cas contraire, la tâche DTS échouera. Les méthodes de traitement pour chaque phase sont les suivantes : Les phases Schema Migration et Full Data Migration n'autorisent pas les opérations DDL modifiant la structure de la base de données ou de la table. Elles ne sont donc pas contrôlées par la stratégie DDL en ligne. Migration du schéma : non contrôlée par la stratégie DDL en ligne. Les tables temporaires associées sont créées. InnoDB : non contrôlée par la stratégie DDL en ligne. La migration des tables temporaires n'est pas incluse dans les objets de migration complète. Toutes les tables dont les noms correspondent à l'expression régulière (^_(.+)_(?:gho|new)$ ou ^_(.+)_(?:ghc|del|old)$) sont filtrées. X-Engine : contrôlée par la stratégie DDL en ligne. Copy the temporary table of the Online DDL tool that is generated in the source table to the destination database. : migre les modifications de données provenant des tables temporaires (par exemple, _table_name_gho) générées par les opérations DDL en ligne. Schema Migration et Full Data Migration : filtre les modifications de données provenant des tables temporaires (par exemple, _table_name_gho) générées par des outils tels que gh-ost, selon des règles d'expression régulière. Schema Migration : migre les données des tables temporaires générées par les modifications DDL en ligne. Remarque Si les modifications DDL en ligne génèrent un grand volume de données dans les tables temporaires, cela peut entraîner une latence de la tâche. Full Data Migration : ne migre pas les données des tables temporaires générées par les modifications DDL en ligne. Seules les instructions DDL d'origine exécutées via Data Management (DMS) sont migrées. Remarque Cette option entraîne le verrouillage des tables dans la base de données de destination. Incremental Data Migration : ne migre pas les données des tables temporaires générées par les modifications DDL en ligne. Cette option prend en charge des règles de filtrage personnalisées. DTS filtre les modifications de données provenant des tables temporaires (par exemple, _table_name_gho) générées par des outils tels que gh-ost, selon des règles d'expression régulière. Vous pouvez modifier les expressions régulières par défaut utilisées pour faire correspondre les tables fantômes et inutiles selon vos besoins : Table fantôme : ^_(.+)_(?:gho|new)$ Table inutile : ^_(.+)_(?:ghc|del|old)$ Remarque Cette option entraîne le verrouillage des tables dans la base de données de destination.
      Yes	Une fois la tâche de migration démarrée, si la connexion à la base de données source ou de destination échoue, DTS signale une erreur et tente immédiatement de rétablir la connexion. La durée de nouvelle tentative par défaut est de 720 minutes. Vous pouvez personnaliser cette durée entre 10 et 1440 minutes. Il est recommandé de définir une durée supérieure à 30 minutes. Si DTS parvient à se reconnecter aux bases de données source et de destination dans le délai spécifié, la tâche de migration reprend automatiquement. Dans le cas contraire, la tâche échoue. Remarque Pour plusieurs instances DTS partageant la même source ou la même destination, la durée de nouvelle tentative réseau est déterminée par le paramétrage de la dernière tâche créée. Étant donné que la tâche est facturée pendant la période de nouvelle tentative de connexion, il est recommandé de personnaliser la durée de nouvelle tentative en fonction de vos besoins opérationnels, ou de libérer l'instance DTS dès que possible après la libération des instances de base de données source et de destination.
      No, Adapt to DMS Online DDL	Une fois la tâche de migration démarrée, si un problème autre qu'un problème de connectivité, tel qu'une exception d'exécution DDL ou DML, survient dans la base de données source ou de destination, DTS signale une erreur et tente immédiatement de relancer l'opération. La durée de nouvelle tentative par défaut est de 10 minutes. Vous pouvez personnaliser cette durée entre 1 et 1440 minutes. Il est recommandé de définir une durée supérieure à 10 minutes. Si les opérations concernées aboutissent dans le délai de nouvelle tentative spécifié, la tâche de migration reprend automatiquement. Dans le cas contraire, la tâche échoue. Important La valeur de No, Adapt to gh-ost doit être inférieure à la valeur de Retry Time for Failed Connections.
      No, Adapt to DMS Online DDL	Lors de la migration complète, DTS consomme des ressources de lecture et d'écriture sur les bases de données source et de destination, ce qui peut augmenter la charge de la base de données. Si nécessaire, vous pouvez activer la limitation de débit pour la tâche de migration complète. Vous pouvez définir les paramètres No, Adapt to gh-ost, RPS of Full Data Migration et Retry Time for Other Issues afin de réduire la charge sur la base de données de destination. Remarque Cet élément de configuration est disponible uniquement si vous sélectionnez Retry Time for Other Issues pour les Retry Time for Failed Connections. Vous pouvez également ajuster la vitesse de migration complète une fois l'instance de migration en cours d'exécution.
      Enable Throttling for Full Data Migration	Si nécessaire, vous pouvez également choisir de définir des limites de vitesse pour la tâche de migration incrémentielle. Vous pouvez définir les paramètres Queries per second (QPS) to the source database et Data migration speed for incremental migration (MB/s) afin de réduire la charge sur la base de données de destination. Remarque Cet élément de configuration est disponible uniquement si vous sélectionnez Data migration speed for full migration (MB/s) pour les Full Data Migration. Vous pouvez également ajuster la vitesse de migration incrémentielle une fois l'instance de migration en cours d'exécution.
      Migration Types	Vous pouvez sélectionner un tag d'environnement pour identifier l'instance. Cela n'est pas requis pour cet exemple.
      Enable Throttling for Incremental Data Migration	Choisissez d'écrire ou non les informations SQL de heartbeat dans la base de données source lorsque l'instance DTS est en cours d'exécution. Yes : les informations SQL de heartbeat ne sont pas écrites dans la base de données source. Cela peut entraîner un retard signalé par l'instance DTS. No : écrit les informations SQL de heartbeat dans la base de données source. Cela peut interférer avec des fonctionnalités telles que la sauvegarde physique et le clonage de la base de données source.
      Incremental Data Migration	En fonction de vos besoins opérationnels, choisissez de configurer ou non la fonctionnalité ETL pour traiter les données. Migration Types : configure la fonctionnalité ETL. Vous devez également saisir des instructions de traitement des données dans la zone de texte. Environment Tag : ne configure pas la fonctionnalité ETL.
      Whether to delete SQL operations on heartbeat tables of forward and reverse tasks	Choisissez de définir ou non des alertes et de recevoir des notifications d'alerte en fonction de vos besoins opérationnels. Yes : ne définit pas d'alerte. Yes : configurez les alertes en définissant un seuil d'alerte et des notifications d'alerte. En cas d'échec de la migration ou si la latence dépasse le seuil, le système envoie une notification d'alerte.

   3. Cliquez sur Configure ETL pour configurer une tâche de validation des données.

      Pour plus d'informations sur la fonctionnalité de validation des données, consultez Configurer la validation des données.

6. Enregistrez la tâche et exécutez une vérification préalable.

   • Pour afficher les paramètres de configuration de cette instance lors de l'appel de l'opération API, placez le pointeur sur le bouton Yes et cliquez sur No dans la bulle qui s'affiche.

   • Si vous n'avez pas besoin d'afficher les paramètres API ou si vous avez terminé leur consultation, cliquez sur Monitoring and Alerting en bas de la page.

   Remarque

   • Avant le démarrage de la tâche de migration, DTS effectue une vérification préalable. La tâche ne démarre qu'après avoir réussi cette vérification.

   • Si la vérification préalable échoue, cliquez sur No à côté de l'élément de vérification ayant échoué, corrigez le problème selon les instructions, puis relancez la vérification préalable.

   • Si un avertissement est signalé lors de la vérification préalable :

     • Pour les éléments de vérification qui ne peuvent pas être ignorés, cliquez sur View Details à côté de l'élément ayant échoué, corrigez le problème selon les instructions, puis relancez la vérification préalable.

     • Pour les éléments de vérification pouvant être ignorés, vous pouvez cliquer sur Next: Data Validation, Next: Save Task Settings and Precheck, Preview OpenAPI parameters et Next: Save Task Settings and Precheck pour ignorer l'élément d'avertissement et relancer la vérification préalable. Si vous choisissez d'ignorer un avertissement, cela peut entraîner des problèmes tels qu'une incohérence des données et présenter des risques pour votre activité.

7. Achetez l'instance.

   1. Lorsque le View Details atteint 100 %, cliquez sur View Details.

   2. Sur la page Confirm Alert Details, sélectionnez la spécification de liaison pour l'instance de migration des données. Pour plus d'informations, consultez le tableau suivant.

      Catégorie	Paramètre	Description
      Ignore	OK	Sélectionnez le groupe de ressources auquel l'instance appartient. La valeur par défaut est « default resource group ». Pour plus d'informations, consultez Qu'est-ce que la gestion des ressources ?
      	Precheck Again	DTS propose des spécifications de migration avec différents niveaux de performance. La spécification de liaison affecte la vitesse de migration. Vous pouvez sélectionner une spécification adaptée à votre scénario opérationnel. Pour plus d'informations, consultez Spécifications de liaison pour la migration des données.

   3. Une fois la configuration terminée, lisez et acceptez les Success Rate.

   4. Cliquez sur Next: Purchase Instance. Dans la boîte de dialogue Purchase qui s'affiche, cliquez sur New Instance Class.

      Vous pouvez consulter la progression de la tâche de migration sur la page de liste Data Migration Tasks.

      Remarque

      • Si la tâche de migration n'inclut pas de migration incrémentielle, elle s'arrête automatiquement une fois la migration complète terminée. Après l'arrêt de la tâche, son Instance Class passe à Data Transmission Service (Pay-as-you-go) Service Terms.

      • Si la tâche de migration inclut une migration incrémentielle, elle ne s'arrête pas automatiquement. La tâche de migration incrémentielle continue de s'exécuter. Pendant l'exécution de la tâche de migration incrémentielle, le Buy and Start de la tâche est OK.

Procédure (ancienne console)

1. Connectez-vous à la console DTS.

   Remarque

   Si vous êtes automatiquement redirigé vers la console Data Management (DMS), cliquez sur l'icône située dans le coin inférieur droit, puis sur pour revenir à la console DTS classique.

2. Dans le volet de navigation de gauche, cliquez sur OK.

3. En haut de la page Migration Tasks, sélectionnez la région du cluster de destination.

4. Dans le coin supérieur droit de la page, cliquez sur Data Migration Tasks.

5. Configurez les bases de données source et cible.

   

   Catégorie	Paramètre	Description
   N/A	Nom de la tâche	DTS génère automatiquement un nom de tâche. Spécifiez un nom descriptif pour faciliter l'identification. Le nom n'a pas besoin d'être unique.
   Informations sur la base de données source	Type d'instance	Sélectionnez Status.
   	Région	Si vous définissez Completed sur Status, ce paramètre n'est pas requis.
   	Type de base de données	Sélectionnez Running.
   	Nom d'hôte ou adresse IP	Saisissez l'endpoint de la base de données Amazon Aurora MySQL. Remarque Vous pouvez obtenir l'endpoint de la base de données sur la page Data Migration de votre base de données Amazon Aurora MySQL. Dans la console Amazon RDS, sélectionnez l'instance writer cible et cliquez sur l'onglet Connection and Security. Vous trouverez l'endpoint dans la section Endpoints and Ports (le format de l'endpoint est xxx.rds.amazonaws.com et le port est 3306).
   	Port	Saisissez le port de service de la base de données Amazon Aurora MySQL. La valeur par défaut est Create Data Migration Task.
   	Compte de base de données	Saisissez le compte de la base de données Amazon Aurora MySQL. Pour connaître les autorisations requises, consultez la section Autorisations requises pour les comptes de base de données.
   	Mot de passe de la base de données	Saisissez le mot de passe du compte de base de données. Remarque Après avoir configuré la base de données source, cliquez sur Self-managed database with a public IP address à côté de Instance Type pour tester la connexion. Si le test réussit, l'état Self-managed database with a public IP address s'affiche. Si l'état MySQL s'affiche, cliquez sur Basic Information à côté de 3306 et ajustez les paramètres en fonction des résultats.
   Informations sur la base de données cible	Type d'instance	Sélectionnez Test Connectivity.
   	Région	Sélectionnez la région où se trouve votre instance PolarDB for MySQL.
   	ID de l'instance PolarDB	Sélectionnez l'ID de votre instance PolarDB for MySQL.
   	Compte de base de données	Saisissez le compte de votre instance PolarDB for MySQL. Pour connaître les autorisations requises, consultez la section Autorisations requises pour les comptes de base de données.
   	Mot de passe de la base de données	Saisissez le mot de passe du compte de base de données. Remarque Après avoir configuré la base de données de destination, cliquez sur Database Password à côté de Passed pour tester la connexion. Si le test réussit, l'état Failed s'affiche. Si l'état Diagnose s'affiche, cliquez sur Failed à côté de Apsara PolarDB et ajustez les paramètres en fonction des résultats.

6. Une fois la configuration terminée, cliquez sur Test Connectivity dans le coin inférieur droit de la page.

   Si la base de données source ou cible est une instance de base de données Alibaba Cloud, telle qu'une instance RDS for MySQL ou ApsaraDB for MongoDB, DTS ajoute automatiquement les blocs CIDR d'adresses IP du service DTS pour la région correspondante à la liste d'autorisation d'adresses IP de l'instance. Si la base de données source ou cible est une base de données gérée par l'utilisateur sur une instance ECS, DTS ajoute automatiquement les blocs CIDR d'adresses IP du service DTS pour la région correspondante aux règles de sécurité de l'instance ECS. Vous devez également vous assurer que la base de données gérée par l'utilisateur autorise l'accès depuis l'instance ECS. Si la base de données est déployée sous forme de cluster sur plusieurs instances ECS, vous devez ajouter manuellement les blocs CIDR d'adresses IP du service DTS pour la région correspondante aux règles de sécurité de chaque instance ECS. Si la base de données source ou cible est une base de données gérée par l'utilisateur dans un centre de données ou une autre base de données cloud, vous devez ajouter manuellement les blocs CIDR d'adresses IP du service DTS pour la région correspondante afin d'autoriser l'accès depuis les serveurs DTS. Pour connaître les blocs CIDR d'adresses IP, consultez la section Blocs CIDR des serveurs DTS.

   Avertissement

   L'ajout des blocs CIDR publics des serveurs DTS, qu'il soit automatique ou manuel, peut introduire des risques de sécurité. En utilisant ce produit, vous reconnaissez et acceptez ces risques potentiels. Il vous incombe de mettre en œuvre des mesures de sécurité de base, notamment l'utilisation de mots de passe robustes, la restriction des ports ouverts, l'utilisation de l'authentification pour les appels API internes, la révision régulière et la restriction des segments réseau inutiles, ou la connexion via des réseaux privés tels qu'Express Connect, VPN Gateway ou Smart Access Gateway.

7. Sélectionnez les types et objets de migration.

   

   Paramètre	Description
   Type de migration	Pour effectuer uniquement une migration complète, sélectionnez à la fois Database Password et Passed. Pour effectuer une migration avec un temps d'arrêt minimal, sélectionnez Failed, Diagnose et Failed. Remarque Pour garantir la cohérence des données, n'écrivez pas de nouvelles données dans la base de données Amazon Aurora MySQL pendant la migration si vous ne sélectionnez pas Authorize Whitelist and Go to Next Step.
   Objets de migration	Dans la zone Schema Migration, sélectionnez les objets à migrer, puis cliquez sur pour les déplacer vers la zone Full Data Migration. Remarque Vous pouvez sélectionner des objets au niveau de la base de données, de la table et de la colonne. Par défaut, les noms des objets sont identiques dans les bases de données source et cible. Pour renommer un objet dans la base de données cible, utilisez la fonctionnalité de mappage des noms d'objets. Pour plus d'informations, consultez la section Mappage des noms d'objets. Le mappage des noms d'objets peut entraîner l'échec de la migration des objets dépendants.
   Mapper le nom de l'objet	Permet de renommer un objet migré dans l'instance cible. Pour plus d'informations, consultez la section Mappage des noms d'objets.
   Durée de nouvelle tentative en cas d'échec de connexion	La durée par défaut est de 12 heures, mais vous pouvez la personnaliser. Si DTS se reconnecte aux bases de données dans le délai spécifié, la tâche reprend automatiquement. Sinon, la tâche échoue. Remarque Des frais sont facturés pour la durée d'exécution de la tâche lors des nouvelles tentatives de connexion. Nous vous recommandons de personnaliser la durée de nouvelle tentative en fonction de vos besoins métier ou d'arrêter l'instance DTS après la libération des instances de base de données source et cible.
   Répliquer les tables temporaires générées par DMS online DDL	Si la base de données source utilise Data Management (DMS) pour effectuer des modifications DDL en ligne, vous pouvez choisir de migrer ou non les données des tables temporaires créées par les modifications DDL en ligne. Schema Migration : Migre les données des tables temporaires générées par les modifications DDL en ligne. Remarque Si les tables temporaires générées par les modifications DDL en ligne contiennent une grande quantité de données, cela peut augmenter la latence de migration. Full Data Migration : Ne migre pas les données des tables temporaires générées par les modifications DDL en ligne. Seules les données DDL originales de la base de données source sont migrées. Remarque Cette option provoque des verrous de table sur la base de données cible.

8. Une fois la configuration terminée, cliquez sur Precheck and Start dans le coin inférieur droit de la page.

   Remarque

   • Avant le démarrage de la tâche de migration, DTS exécute une pré-vérification. La tâche ne peut démarrer qu'après avoir réussi cette pré-vérification.

   • Si la pré-vérification échoue, cliquez sur l'icône à côté de l'élément ayant échoué pour afficher les détails.

     • Corrigez les problèmes comme indiqué et relancez la pré-vérification.

     • Si vous n'avez pas besoin de corriger les éléments d'avertissement, vous pouvez sélectionner Incremental Data Migration puis cliquer sur Ignore Warnings and Rerun Precheck pour relancer la pré-vérification.

9. Une fois la tâche passée avec succès à la pré-vérification, cliquez sur Incremental Data Migration.

10. Dans la boîte de dialogue Confirm Settings qui s'affiche, sélectionnez une Migration Objects et cochez la case Data Transmission Service (pay-as-you-go) Service Terms.

11. Cliquez sur Selected Objects pour commencer la migration.

    • Migration du schéma + Migration complète des données

      Laissez la tâche se terminer automatiquement. L'arrêter manuellement peut entraîner une incomplétude des données.

    • Migration du schéma + Migration complète des données + Migration incrémentielle des données

      La tâche de migration ne s'arrête pas automatiquement. Vous devez l'arrêter manuellement.

      Important

      Choisissez un moment approprié pour arrêter la tâche manuellement, par exemple pendant les heures creuses ou lorsque vous êtes prêt à basculer votre activité vers le cluster de destination.

      1. Attendez que la tâche de migration entre dans la phase Yes et que l'état indique No. Ensuite, cessez d'écrire des données dans la base de données source pendant plusieurs minutes. Pendant ce temps, l'état de Ignore peut afficher une latence.

      2. Attendez que l'état Next indique à nouveau Instance Class. Ensuite, arrêtez manuellement la tâche de migration. Cochez la case de la tâche de migration cible et cliquez sur Buy and Start dans la barre d'opérations groupées en bas de la page.

12. Basculez vos charges de travail vers l'instance PolarDB for MySQL.