Data Transmission Service:Migrer des données depuis RDS for MySQL vers Lindorm

Limitations de la base de données source

• Le serveur hébergeant la base de données source doit disposer d'une bande passante sortante suffisante. Dans le cas contraire, la vitesse de migration des données sera affectée.

• Les tables à migrer doivent posséder des clés primaires et des champs uniques. Sans cela, des données en double peuvent apparaître dans la destination.

• Si vous effectuez une migration au niveau de la table et modifiez des objets (comme le mappage des noms de tables ou de colonnes), une seule tâche prend en charge un maximum de 1 000 tables. Si vous dépassez cette limite, répartissez les tables dans plusieurs tâches ou configurez la tâche pour migrer l'intégralité de la base de données.

• Si la source est MySQL 8.0.23 ou ultérieur et que les données incluent des colonnes invisibles, DTS ne peut pas lire ces colonnes, ce qui entraîne une perte de données. Pour rendre les colonnes invisibles visibles avant la migration, exécutez :

  ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;

  Pour plus d'informations, consultez Colonnes invisibles. Les tables sans clés primaires explicites génèrent automatiquement des clés primaires invisibles ; rendez-les également visibles. Consultez Clés primaires invisibles générées.

Incremental migration only:

• La journalisation binaire doit être activée avec les paramètres suivants. Sans ces paramètres, la vérification préalable échoue et la tâche ne peut pas démarrer. Exigences de rétention des journaux binaires : si les journaux binaires sont supprimés avant que DTS ne puisse les lire, la tâche peut échouer ou une incohérence des données peut survenir, et l'accord de niveau de service (SLA) du service DTS peut ne pas s'appliquer.

  • ApsaraDB RDS for MySQL : au moins 3 jours (7 jours recommandés). Consultez Configurer les paramètres selon lesquels le système supprime automatiquement les fichiers de journaux binaires d'une instance RDS.

  • MySQL autogéré : au moins 7 jours.

  Paramètre	Valeur requise	Effet si non défini
  binlog_format	ROW	Le réglage sur STATEMENT ou MIXED peut entraîner une incohérence des données dans la destination.
  binlog_row_image	full	Des images de lignes partielles peuvent entraîner une réplication incomplète des données.
  log_slave_updates	ON	Requis uniquement pour MySQL autogéré dans un cluster à double primaire. Sans cela, DTS ne peut pas obtenir tous les journaux binaires.

Migration complète uniquement :

• N'effectuez pas d'opérations DDL sur la source pendant la migration complète. Les opérations DDL peuvent entraîner l'échec de la tâche.

  Pendant la migration complète, DTS interroge la base de données source et crée des verrous de métadonnées, ce qui peut bloquer les opérations DDL sur la source.

• N'écrivez pas de nouvelles données sur la source si vous sélectionnez uniquement Full Data Migration. Pour maintenir la synchronisation entre la source et la destination tout au long de la migration, sélectionnez à la fois Full Data Migration et Incremental Data Migration.

• La migration complète des données est impossible si la fonctionnalité EncDB est activée sur l'instance RDS for MySQL source.

  Les instances RDS for MySQL avec le chiffrement transparent des données (TDE) activé prennent en charge la migration du schéma, la migration complète des données et la migration incrémentielle des données.

Autres limitations

• La migration du schéma vers Lindorm repose sur les capacités propres de Lindorm pour la création de schémas.

• Lindorm impose une limite par défaut sur le nombre de colonnes pour les index sur des colonnes autres que la clé primaire. DTS ne peut pas créer de tels index lors de la migration du schéma lorsque le nombre de colonnes dépasse cette limite. Pour utiliser de tels index, créez-les manuellement. Pour plus de détails, consultez ALTER SYSTEM.

• La migration des objets INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER et des clés étrangères n'est pas prise en charge.

• La migration du type de données BIT n'est pas prise en charge.

• Vous ne pouvez pas migrer uniquement les champs de clé primaire. Les données doivent contenir au moins un champ non clé primaire.

• Les données ne peuvent être écrites que dans le moteur de tables larges d'une instance Lindorm.

• Les chaînes vides de type VARBINARY sont traitées comme nulles par DTS et Lindorm.

• Si la précision d'un champ DECIMAL dans la destination diffère de celle de la source, la tâche échoue.

• Les données écrites dans Lindorm doivent respecter les limites sur les requêtes de données. Les requêtes dépassant ces limites entraînent l'échec de la tâche.

• La migration complète exécute des opérations INSERT concurrentes, ce qui provoque une fragmentation de l'espace de table dans la destination. L'espace de table de destination sera plus grand que celui de la source une fois l'initialisation complète terminée.

• N'exécutez pas d'outils DDL en ligne tels que pt-online-schema-change sur les objets de migration dans la source pendant la migration. Cela entraîne l'échec de la migration.

• Si des données sont écrites dans la destination par des sources autres que DTS pendant la migration, une incohérence des données peut survenir.

• Les données générées par les opérations de changement de journal binaire — telles que les données restaurées à partir d'une sauvegarde physique ou les opérations en cascade — ne sont pas migrées vers la destination.

  Si ces données ne sont pas migrées, vous pouvez relancer une migration complète tant que votre activité professionnelle n'est pas affectée.

• En cas d'échec d'une instance DTS, l'assistance DTS tente de la récupérer dans un délai de 8 heures. Les opérations de récupération peuvent inclure le redémarrage de l'instance et l'ajustement des paramètres de l'instance DTS (et non des paramètres de la base de données). Pour connaître les paramètres susceptibles d'être ajustés, consultez Modifier les paramètres de l'instance.

Cas particuliers

Source MySQL autogérée :

• Si un basculement primaire/secondaire se produit sur la source pendant l'exécution de la tâche de migration, la tâche échoue.

• DTS exécute périodiquement CREATE DATABASE IF NOT EXISTS sur la source pour faire avancer la position du fichier de journal binaire.

• Si aucune opération DML n'est effectuée sur la source pendant une période prolongée, les lectures de latence de migration peuvent être inexactes. Exécutez une opération DML sur la source pour actualiser la latence. Si vous sélectionnez une base de données entière comme objet de migration, créez une table heartbeat qui reçoit des mises à jour chaque seconde.

Source ApsaraDB RDS for MySQL :

• Incremental migration only: Une instance RDS for MySQL V5.6 en lecture seule ne peut pas être utilisée comme source car elle n'enregistre pas les journaux de transaction.

• DTS exécute périodiquement CREATE DATABASE IF NOT EXISTS sur la source pour faire avancer la position du fichier de journal binaire.

Étape 1 : Ouvrir la page Data Migration

Utilisez l'une des méthodes suivantes :

Étape 2 : Configurer les bases de données source et de destination

1. Cliquez sur Create Task.

2. Configurez les bases de données source et de destination à l'aide des paramètres suivants :

   Base de données source :

   Paramètre	Description
   Task Name	Nom de la tâche DTS. DTS génère un nom automatiquement. Spécifiez un nom descriptif pour faciliter l'identification de la tâche. Le nom n'a pas besoin d'être unique.
   Select Existing Connection	Si l'instance source est déjà enregistrée auprès de DTS, sélectionnez-la dans la liste déroulante — DTS renseigne automatiquement les paramètres de la base de données. Sinon, configurez manuellement les paramètres ci-dessous.
   Database Type	Sélectionnez MySQL.
   Access Method	Sélectionnez Alibaba Cloud Instance.
   Instance Region	Sélectionnez la région où réside l'instance RDS for MySQL source.
   Replicate Data Across Alibaba Cloud Accounts	Sélectionnez No si la source se trouve dans le même compte Alibaba Cloud.
   RDS Instance ID	Sélectionnez l'ID de l'instance RDS for MySQL source.
   Database Account	Saisissez le compte de base de données pour l'instance source. Pour les autorisations requises, consultez Autorisations du compte de base de données.
   Database Password	Saisissez le mot de passe du compte de base de données.
   Encryption	Sélectionnez Non-encrypted ou SSL-encrypted. Pour utiliser le chiffrement SSL, activez-le d'abord sur l'instance RDS for MySQL. Consultez Utiliser un certificat cloud pour activer le chiffrement SSL.

   Base de données de destination :

   Paramètre	Description
   Select Existing Connection	Si l'instance de destination est déjà enregistrée auprès de DTS, sélectionnez-la dans la liste déroulante. Sinon, configurez manuellement les paramètres ci-dessous.
   Database Type	Sélectionnez Lindorm.
   Access Method	Sélectionnez Alibaba Cloud Instance.
   Instance Region	Sélectionnez la région où réside l'instance Lindorm de destination.
   Instance ID	Sélectionnez l'ID de l'instance Lindorm de destination.
   Database Account	Saisissez le compte de base de données pour l'instance de destination.
   Database Password	Saisissez le mot de passe du compte de base de données.

3. Cliquez sur Test Connectivity and Proceed.

   Assurez-vous que les plages CIDR des serveurs DTS sont ajoutées aux paramètres de sécurité des bases de données source et de destination. Consultez Ajouter les adresses IP des serveurs DTS à une liste blanche . Si la source ou la destination est une base de données autogérée non accessible via Alibaba Cloud Instance , cliquez sur Test Connectivity dans la boîte de dialogue CIDR Blocks of DTS Servers .

Étape 3 : Configurer les objets à migrer

1. Sur la page Configure Objects, définissez les paramètres suivants :

   Si vous ne sélectionnez pas Incremental Data Migration , n'écrivez pas de nouvelles données sur la source pendant la migration afin de garantir la cohérence des données.

   Paramètre	Description
   Migration Types	Sélectionnez Full Data Migration pour une migration ponctuelle. Sélectionnez à la fois Full Data Migration et Incremental Data Migration pour maintenir la destination synchronisée avec la source tout au long de la migration.
   Processing Mode of Conflicting Tables	Conservez la valeur par défaut.
   Capitalization of Object Names in Destination Instance	Contrôle la mise en majuscule des noms de bases de données, de tables et de colonnes dans la destination. La valeur par défaut est DTS default policy. Pour plus d'informations, consultez Politique de mise en majuscule des noms d'objets dans la base de données de destination.
   Source Objects	Sélectionnez les bases de données ou les tables à migrer, puis cliquez sur pour les déplacer vers Selected Objects.
   Selected Objects	Si les noms de bases de données, de tables ou de colonnes dans l'instance Lindorm de destination diffèrent de ceux de la source, utilisez le mappage des noms d'objets. Pour plus de détails, consultez Mapper les noms d'objets. Pour appliquer des filtres au niveau des lignes, faites un clic droit sur une table et spécifiez les conditions WHERE. Consultez Spécifier les conditions de filtrage. Pour sélectionner les opérations SQL à inclure dans la migration incrémentielle, faites un clic droit sur un objet et sélectionnez les opérations.

2. Cliquez sur Next: Advanced Settings et configurez les éléments suivants :

   Paramètre	Description
   Dedicated Cluster for Task Scheduling	Par défaut, DTS utilise le cluster partagé. Pour une stabilité améliorée, achetez un cluster dédié. Consultez Qu'est-ce qu'un cluster dédié DTS.
   Retry Time for Failed Connections	Durée pendant laquelle DTS réessaie si la source ou la destination est indisponible. Valeurs valides : 10–1 440 minutes. Par défaut : 720 minutes. Définissez cette valeur sur plus de 30 minutes. Si DTS se reconnecte dans ce délai, il reprend la tâche ; sinon, la tâche échoue. Remarque : si plusieurs tâches partagent la même source ou destination, la valeur définie le plus récemment s'applique. Vous êtes facturé pour l'instance DTS pendant les tentatives de reconnexion.
   Retry Time for Other Issues	Durée pendant laquelle DTS réessaie les opérations DDL ou DML ayant échoué. Valeurs valides : 1–1 440 minutes. Par défaut : 10 minutes. Définissez cette valeur sur plus de 10 minutes. Cette valeur doit être inférieure à Retry Time for Failed Connections.
   Enable Throttling for Full Data Migration	Limiter le débit de la migration complète pour réduire la charge sur la source et la destination. Configurez Queries per second (QPS) to the source database, RPS of Full Data Migration et Data migration speed for full migration (MB/s). Disponible uniquement lorsque Full Data Migration est sélectionné.
   Enable Throttling for Incremental Data Migration	Limiter le débit de la migration incrémentielle. Configurez RPS of Incremental Data Migration et Data migration speed for incremental migration (MB/s). Disponible uniquement lorsque Incremental Data Migration est sélectionné.
   Environment Tag	Sélectionnez un tag pour identifier l'instance. Aucun tag n'est requis pour cet exemple.
   Whether to delete SQL operations on heartbeat tables of forward and reverse tasks	Contrôle si DTS écrit les opérations SQL de la table heartbeat dans la source pendant l'exécution de l'instance. Sélectionnez Yesparamètres de notification d'alerte pour ignorer l'écriture (une valeur de latence peut apparaître sur l'instance DTS). Sélectionnez No pour écrire les opérations heartbeat (cela peut affecter la sauvegarde physique et le clonage de la source).
   Configure ETL	Sélectionnez Yes pour configurer les règles d'extraction, de transformation et de chargement (ETL) dans l'éditeur de code. Consultez Configurer ETL dans une tâche de migration ou de synchronisation de données. Sélectionnez No pour ignorer la configuration ETL.
   Monitoring and Alerting	Sélectionnez Yes pour recevoir des alertes lorsque la tâche échoue ou que la latence de migration dépasse le seuil. Configurez le seuil d'alerte et les paramètres de notification. Consultez Configurer la surveillance et les alertes lors de la création d'une tâche DTS.

Étape 4 : Exécuter la vérification préalable

Cliquez sur Next: Save Task Settings and Precheck.

Pour afficher les paramètres OpenAPI pour cette configuration de tâche, survolez Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters avant de continuer.

DTS exécute une vérification préalable avant de démarrer la migration. Si la vérification préalable échoue :

• Cliquez sur View Details à côté de chaque élément ayant échoué, résolvez le problème, puis cliquez sur Precheck Again.

• Si une alerte de vérification préalable peut être ignorée, cliquez sur Confirm Alert Details, puis sur Ignore dans la boîte de dialogue, puis sur OK, puis sur Precheck Again. Ignorer les alertes peut entraîner une incohérence des données.

Étape 5 : Acheter et démarrer l'instance

1. Attendez que le Success Rate atteigne 100%, puis cliquez sur Next: Purchase Instance.

2. Sur la page Purchase Instance, configurez les éléments suivants :

   Paramètre	Description
   Resource Group	Groupe de ressources pour l'instance de migration. Par défaut : default resource group. Consultez Qu'est-ce que Resource Management ?
   Instance Class	DTS propose des classes d'instance qui varient en fonction de la vitesse de migration. Vous pouvez sélectionner une classe d'instance en fonction de votre scénario professionnel. Consultez Classes d'instance des instances de migration de données.

3. Lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms, puis cliquez sur Buy and Start. Cliquez sur OK dans le message de confirmation.

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

Si une tâche de migration de données ne peut pas être utilisée pour migrer des données incrémentielles, la tâche s'arrête automatiquement. Le statut Completed s'affiche.

Si une tâche de migration de données peut être utilisée pour migrer des données incrémentielles, la tâche ne s'arrête pas automatiquement. La tâche de migration incrémentielle des données s'exécute en continu. Le statut Running s'affiche.