Migration des données : d'ApsaraDB RDS for MySQL vers ApsaraDB for SelectDB - Data Transmission Service

Prérequis

Vous disposez d'une instance source ApsaraDB RDS for MySQL et d'une instance cible ApsaraDB for SelectDB.

Limitations

Type	Description
Base de données source	Bande passante : 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 diminuera. Objets de migration : Si toutes les tables à migrer possèdent une clé primaire ou une contrainte unique : Assurez-vous que les colonnes de la table sont uniques. Sinon, des données en double peuvent apparaître dans la base de données de destination. Si les objets de migration incluent des tables sans clé primaire ni contrainte unique : Lors de la configuration de l'instance, nous vous recommandons de sélectionner Schema Migration pour Migration Types et, à l'étape Configurations for Databases, Tables, and Columns, de définir le paramètre Engine de la table sur duplicate. Faute de quoi, l'instance risque d'échouer ou des pertes de données peuvent survenir. Remarque Pendant la migration du schéma, DTS ajoute une colonne supplémentaire aux tables de destination. Pour plus d'informations, consultez la section Informations sur les colonnes supplémentaires. Si vous migrez les données au niveau des tables et devez modifier les objets, par exemple en utilisant le mappage des noms d'objets, une seule tâche de migration de données peut migrer un maximum de 1 000 tables. Si cette limite est dépassée, la tâche signale une erreur lors de sa soumission. Dans ce cas, répartissez les tables sur plusieurs tâches de migration ou configurez une tâche pour migrer la base de données entière. Pour une migration incrémentielle, activez la journalisation binaire : Définissez binlog_format sur ROW et binlog_row_image sur FULL. Sans cela, la prévérification échouera et la tâche ne pourra pas démarrer. Important Si votre source MySQL auto-gérée est un cluster maître-maître (où chaque instance agit à la fois comme maître et esclave), activez le paramètre log_slave_updates. Cela garantit que DTS peut lire tous les journaux binaires. Pour les instances RDS for MySQL, conservez les journaux binaires locaux pendant au moins trois jours (sept jours recommandés). Pour les bases de données MySQL auto-gérées, conservez les journaux binaires locaux pendant au moins sept jours. Si DTS ne peut pas accéder aux journaux binaires, la tâche échoue. Dans les cas extrêmes, une incohérence ou une perte de données peut survenir. Les problèmes causés par des périodes de rétention des journaux binaires inférieures aux exigences de DTS ne sont pas couverts par le SLA de DTS. Remarque Pour définir la retention period des journaux binaires locaux sur une instance RDS for MySQL, consultez la page Suppression automatique des journaux locaux. Pendant les phases de migration du schéma et de migration complète des données, n'effectuez pas d'opérations DDL qui modifient le schéma de la base de données ou des tables. Cela entraînerait l'échec de la tâche de migration des données. Remarque Pendant la phase de migration complète, DTS interroge la base de données source. Cela crée un verrouillage des métadonnées, qui peut bloquer les opérations DDL sur la base de données source. Si vous effectuez uniquement une migration complète des données, n'écrivez pas de nouvelles données dans la base de données source. Sinon, une incohérence de données surviendra entre les bases de données source et de destination. Pour maintenir la cohérence des données en temps réel, sélectionnez la migration du schéma, la migration complète des données et la migration incrémentielle des données. DTS ne migre pas les données générées par des modifications qui n'écrivent pas dans les journaux binaires. Cela concerne par exemple les données restaurées à partir de sauvegardes physiques ou créées par des opérations en cascade. Remarque Si tel est le cas, relancez la migration complète dès que votre activité le permet. Si votre base de données MySQL source est en version 8.0.23 ou ultérieure et contient des colonnes masquées invisibles, DTS ne peut pas lire ces colonnes. Cela peut entraîner une perte de données. Remarque Exécutez `ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;` pour rendre la colonne masquée visible. Pour plus d'informations, consultez la documentation Colonnes invisibles.
Autres limitations	Vous ne pouvez migrer les données que vers des tables utilisant le modèle Unique ou Duplicate dans une instance ApsaraDB for SelectDB. Modèle Unique Si la table de destination est une table de modèle Unique, assurez-vous que toutes les clés uniques de la table de destination existent dans la table source et sont incluses dans les objets de migration. Sinon, une incohérence des données peut survenir. Modèle Duplicate Si la table de destination est une table de modèle Duplicate, des données en double peuvent apparaître dans la base de données de destination dans les cas suivants. Vous pouvez dédupliquer manuellement les données en vous basant sur des colonnes supplémentaires telles que _is_deleted, _version et _record_id. La tentative de reprise de l'instance de migration a été effectuée. L'instance de migration a été redémarrée. Vous avez effectué deux opérations DML ou plus sur la même ligne de données après le démarrage de l'instance de migration. Remarque Si la table de destination est une table de modèle Duplicate, DTS convertit les instructions UPDATE ou DELETE en instructions INSERT. DTS ne prend pas en charge la migration des index, partitions, vues, procédures, fonctions, déclencheurs ou clés étrangères. Lorsque vous configurez les paramètres dans la zone Selected Objects, vous ne pouvez actuellement définir que le paramètre `bucket_count` (nombre de buckets). Remarque Le paramètre `bucket_count` ne peut être défini que sur un entier positif. La valeur par défaut est auto. Pendant la migration des données, ne créez pas de cluster dans l'instance ApsaraDB for SelectDB de destination. Sinon, la tâche échouera. Redémarrez l'instance de migration pour reprendre la tâche ayant échoué. Les instances ApsaraDB for SelectDB prennent uniquement en charge les noms de bases de données et de tables commençant par une lettre. Si le nom d'une base de données ou d'une table à migrer ne commence pas par une lettre, utilisez le mappage des noms d'objets pour le renommer. Si le nom d'un objet de migration, tel qu'une base de données, une table ou une colonne, contient des caractères chinois, utilisez le mappage des noms d'objets pour le renommer, par exemple avec un nom en anglais. Sinon, la tâche peut échouer. DTS ne prend pas en charge la migration des opérations DDL qui modifient plusieurs colonnes à la fois ou qui effectuent des modifications consécutives sur la même table. Pendant la migration des données, n'ajoutez pas de nœud backend à la base de données ApsaraDB for SelectDB. Sinon, la tâche échouera. Redémarrez l'instance de migration pour reprendre la tâche ayant échoué. Dans un scénario de fusion multi-tables où vous migrez les données de plusieurs tables sources vers une seule table de destination, assurez-vous que toutes les tables sources ont le même schéma. Sinon, une incohérence des données ou un échec de la tâche peut survenir. Dans MySQL, M dans le type `VARCHAR(M)` spécifie la longueur en caractères. Dans ApsaraDB for SelectDB, N dans le type `VARCHAR(N)` spécifie la longueur en octets. Si vous n'utilisez pas la fonctionnalité de migration du schéma de DTS, nous vous recommandons de définir la longueur d'une colonne VARCHAR dans ApsaraDB for SelectDB à quatre fois sa longueur dans MySQL. Lorsque vous utilisez DMS ou gh-ost pour effectuer des opérations DDL en ligne sur la source, DTS migre uniquement les instructions DDL d'origine vers la destination. Dans ce scénario, DTS n'a pas besoin de migrer de grands volumes de données de tables temporaires, mais l'opération peut provoquer des verrous de table sur la destination. Remarque DTS ne prend pas en charge la migration des modifications DDL en ligne effectuées par des outils tels que pt-online-schema-change sur la source. Si la source présente de telles modifications, une perte de données ou un échec de la tâche peut survenir sur la destination. Évaluez les performances des bases de données source et de destination avant de migrer les données. Nous vous recommandons d'effectuer la migration des données pendant les heures creuses. Pendant la 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 peut augmenter leur charge. La migration complète des données exécute des opérations INSERT concurrentes, ce qui provoque une fragmentation des tables dans la base de données de destination. Par conséquent, l'espace disque utilisé dans l'instance de destination est supérieur à celui de l'instance source une fois la migration complète terminée. Pendant la migration des données, si des sources autres que DTS écrivent des données dans la base de données de destination, une incohérence des données entre les bases de données source et de destination peut survenir. Si votre instance RDS for MySQL a Always-Encrypted activé, la migration complète n'est pas prise en charge. Remarque Les instances RDS for MySQL avec Transparent Data Encryption (TDE) activé prennent en charge la migration du schéma, la migration complète et la migration incrémentielle. Pendant la migration incrémentielle, DTS utilise une stratégie de synchronisation par lots pour réduire la charge sur la destination. Par défaut, DTS écrit dans un seul objet de synchronisation au maximum une fois toutes les 5 secondes. Par conséquent, les tâches de migration DTS peuvent connaître une latence de synchronisation régulière, généralement inférieure à 10 secondes. Pour réduire cette latence de migration régulière, modifiez le paramètre d'instance DTS `selectdb.reservoir.timeout.milliseconds` dans la console afin d'ajuster l'intervalle de lot. La plage autorisée est [1000, 10000] millisecondes. Remarque Lorsque vous ajustez l'intervalle de lot, une valeur plus petite augmente la fréquence d'écriture de DTS. Cela peut augmenter la charge et le temps de réponse en écriture (RT) sur la destination, ce qui accroît à son tour la latence de synchronisation DTS. Ajustez la valeur en fonction de la charge sur la destination. Si une tâche échoue, l'équipe d'assistance DTS tentera de la restaurer dans un délai de huit heures. Lors de la restauration, ils peuvent redémarrer la tâche ou ajuster ses paramètres. Remarque Seuls les paramètres de la tâche DTS sont modifiés, pas les paramètres de la base de données. Les paramètres susceptibles d'être ajustés incluent ceux répertoriés dans Modification des paramètres de l'instance.
Cas particuliers	Pour les sources MySQL auto-gérées : Un basculement maître-esclave sur la base de données source entraîne l'échec de la tâche de migration. DTS calcule la latence en comparant l'horodatage du dernier enregistrement migré vers la base de données de destination avec l'heure actuelle. Si aucune opération DML n'est exécutée sur la source pendant une longue période, le rapport de latence devient imprécis. Si la latence semble trop élevée, exécutez une opération DML sur la source pour mettre à jour la valeur de latence. Remarque Si vous sélectionnez la migration de base de données complète, créez une table de heartbeat. Mettez-la à jour ou écrivez-y chaque seconde. DTS exécute périodiquement CREATE DATABASE IF NOT EXISTS `test` sur la base de données source pour faire avancer le décalage du journal binaire. Si votre source est Amazon Aurora MySQL ou une autre instance MySQL en cluster, assurez-vous que le nom de domaine ou l'adresse IP configuré pour la tâche — et sa résolution DNS — pointent toujours vers un nœud en lecture-écriture (RW). Sinon, la tâche de migration peut échouer. Pour les sources RDS for MySQL : Si vous avez besoin d'une migration incrémentielle, les instances RDS for MySQL qui n'enregistrent pas les journaux de transactions, telles que les instances en lecture seule RDS for MySQL 5.6, ne sont pas prises en charge en tant que sources. DTS exécute périodiquement CREATE DATABASE IF NOT EXISTS `test` sur la base de données source pour faire avancer le décalage du journal binaire.

Facturation

Type de migration	Frais de configuration de la tâche	Frais de trafic public
Migration du schéma et migration complète des données	Gratuit.	Gratuit dans cet exemple. Remarque Des frais de transfert de données Internet s'appliquent si la Access Method pour la base de données de destination est Public IP Address. Pour plus d'informations, consultez la Présentation de la facturation.
Migration incrémentielle des données	Facturé. Pour plus d'informations, consultez la Présentation de la facturation.

SQL pris en charge pour la migration incrémentielle

Type d'opération	Instruction SQL
DML	`INSERT`, `UPDATE` et `DELETE`
DDL	`ADD COLUMN` `MODIFY COLUMN` `CHANGE COLUMN` `DROP COLUMN` et `DROP TABLE` `TRUNCATE TABLE` RENAME TABLE Important Une opération RENAME TABLE peut provoquer une incohérence des données. Par exemple, si vous ne sélectionnez qu'une seule table comme objet de migration et renommez la table dans l'instance source pendant la migration, les données de cette table ne seront pas migrées vers la base de données de destination. Pour éviter ce problème, sélectionnez la base de données entière à laquelle appartient la table comme objet de migration lors de la configuration de la tâche de migration des données. Assurez-vous que les bases de données auxquelles appartient la table avant et après l'opération RENAME TABLE sont toutes deux incluses dans les objets de migration.

Exigences en matière d'autorisations pour les comptes de base de données

Base de données	Migration du schéma	Migration complète des données	Migration incrémentielle des données
Source ApsaraDB RDS for MySQL	Autorisation SELECT	Autorisation SELECT	Autorisations de lecture et d'écriture
Cible ApsaraDB for SelectDB	Autorisation d'accès au cluster (`Usage_priv`) et autorisations de lecture et d'écriture pour la base de données (`Select_priv`, `Load_priv`, `Alter_priv`, `Create_priv` et `Drop_priv`)

Pour créer un compte de base de données et accorder des autorisations :

Instance ApsaraDB RDS for MySQL : Consultez les pages Création d'un compte et Modification des autorisations du compte.
Instance ApsaraDB for SelectDB : Consultez les pages Gestion des autorisations de cluster et Gestion des autorisations de base.

Remarque

Si le compte de la base de données source a été créé en dehors de la console ApsaraDB RDS for MySQL, assurez-vous qu'il dispose des autorisations REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW et SELECT.

Procédure

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 console Data Transmission Service (DTS).
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 les pages Console en mode simple et Personnalisation de la disposition et du style de la console DMS.
1. Connectez-vous à la console Data Management (DMS).
2. Dans la barre de menu supérieure, choisissez Data + AI > Data Transmission (DTS) > Data Migration.
3. À droite de Data Migration Tasks, sélectionnez la région où se trouve l'instance de migration.
Cliquez sur Create Task pour accéder à la page de configuration de la tâche.

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

Section	Paramètre	Description
S.O.	Task Name	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	Select Existing Connection	Pour utiliser une instance de base de données qui a été ajoutée au système (créée ou enregistrée), sélectionnez l'instance de base de données souhaitée dans la liste déroulante. Les informations de la base de données ci-dessous seront automatiquement configurées. Remarque Dans la console DMS, ce paramètre est nommé Select a DMS database instance.. Si vous n'avez pas enregistré l'instance de base de données auprès du système, ou si vous n'avez pas besoin d'utiliser une instance enregistrée, configurez manuellement les informations de la base de données 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 source ApsaraDB RDS for MySQL.
	Replicate Data Across Alibaba Cloud Accounts	Cet exemple suppose une migration de données au sein d'un seul compte Alibaba Cloud. Sélectionnez No.
	RDS Instance ID	Sélectionnez l'ID de l'instance source ApsaraDB RDS for MySQL.
	Database Account	Saisissez le compte de base de données de l'instance source ApsaraDB RDS for MySQL. Pour plus d'informations sur les autorisations requises, consultez la section Exigences en matière d'autorisations pour les comptes de base de données.
	Database Password	Saisissez le mot de passe correspondant au compte de base de données.
	Encryption	Sélectionnez Non-encrypted ou SSL-encrypted selon vos besoins. Si vous sélectionnez SSL-encrypted, vous devez activer le chiffrement SSL pour l'instance RDS for MySQL au préalable. Pour plus d'informations, consultez la page Utilisation d'un certificat cloud pour activer rapidement le chiffrement SSL.
Destination Database	Select Existing Connection	Pour utiliser une instance de base de données qui a été ajoutée au système (créée ou enregistrée), sélectionnez l'instance de base de données souhaitée dans la liste déroulante. Les informations de la base de données ci-dessous seront automatiquement configurées. Remarque Dans la console DMS, ce paramètre est nommé Select a DMS database instance.. Si vous n'avez pas enregistré l'instance de base de données auprès du système, ou si vous n'avez pas besoin d'utiliser une instance enregistrée, configurez manuellement les informations de la base de données ci-dessous.
	Database Type	Sélectionnez ApsaraDB for SelectDB.
	Access Method	Sélectionnez Alibaba Cloud Instance.
	Instance Region	Sélectionnez la région où réside l'instance ApsaraDB for SelectDB de destination.
	Replicate Data Across Alibaba Cloud Accounts	Cet exemple suppose une migration de données au sein d'un seul compte Alibaba Cloud. Sélectionnez No.
	Instance ID	Sélectionnez l'ID de l'instance ApsaraDB for SelectDB de destination.
	Database Account	Saisissez le compte de base de données de l'instance ApsaraDB for SelectDB de destination. Pour plus d'informations sur les autorisations requises, consultez la section Exigences en matière d'autorisations pour les comptes de base de données.
	Database Password	Saisissez le mot de passe du compte de base de données.

Une fois la configuration terminée, cliquez sur Test Connectivity and Proceed en bas de la page.
Remarque
- Assurez-vous que les blocs CIDR d'adresses IP des serveurs DTS sont ajoutés aux paramètres de sécurité des bases de données source et de destination pour autoriser l'accès depuis les serveurs DTS. Cela peut être fait automatiquement ou manuellement. Pour plus d'informations, consultez la page Ajout des blocs CIDR d'adresses IP des serveurs DTS à une liste blanche.
- Si la base de données source ou de destination est une base de données auto-gérée (où la Access Method n'est pas Alibaba Cloud Instance), vous devez également cliquer sur Test Connectivity dans la boîte de dialogue CIDR Blocks of DTS Servers.

Configurez les objets de la tâche.

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

Paramètre	Description
Migration Types	Pour une migration complète des données uniquement, sélectionnez à la fois Schema Migration et Full Data Migration. Pour effectuer une migration des données sans interruption de service, sélectionnez Schema Migration, Full Data Migration et Incremental Data Migration. Important Lorsque vous migrez des données de MySQL vers ApsaraDB for SelectDB, les types de données sont convertis. Si vous ne sélectionnez pas Schema Migration, vous devez créer au préalable des tables utilisant le modèle Unique Key ou Duplicate Key dans l'instance ApsaraDB for SelectDB de destination. Pour plus d'informations, consultez les sections Mappages de types de données, Colonnes supplémentaires et Modèles de données. Si vous ne sélectionnez pas Incremental Data Migration, n'écrivez pas de données dans l'instance source pendant la migration des données afin de garantir la cohérence des données.
Processing Mode of Conflicting Tables	Precheck and Report Errors : DTS vérifie si une table portant le même nom existe dans la base de données de destination. Si aucune table portant le même nom n'existe, la prévérification réussit. Si une table portant le même nom existe, la prévérification signale une erreur et la tâche de migration des données ne démarre pas. Remarque Si vous ne pouvez pas supprimer ou renommer la table dans la base de données de destination, vous pouvez modifier le nom de la table dans la base de données de destination. Pour plus d'informations, consultez la page Mappage des noms d'objets de schéma. Ignore Errors and Proceed : DTS ignore la vérification des tables portant le même nom dans la base de données de destination. Avertissement Si vous sélectionnez Ignore Errors and Proceed, une incohérence des données peut survenir et présenter des risques pour votre activité. Exemples : Si les schémas de table sont cohérents 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, DTS ne conserve pas l'enregistrement de destination. L'enregistrement source remplace l'enregistrement de destination. Si les schémas de table sont incohérents, seules les données de certaines colonnes 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, DTS default policy est sélectionné. Vous pouvez également choisir de conserver 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 la page Sensibilité à la casse des noms d'objets dans la base de données de destination.
Source Objects	Dans la zone Source Objects, cliquez sur les objets à migrer, puis cliquez sur pour les déplacer vers la zone Selected Objects. Remarque Vous pouvez sélectionner des bases de données ou des tables comme objets de migration.
Selected Objects	Pour modifier les noms des objets de migration dans l'instance de destination, cliquez avec le bouton droit sur un objet de migration dans la section Selected Objects. Pour plus d'informations, consultez la page Mappage des noms d'objets de schéma. Si vous sélectionnez Schema Migration pour Migration Types, sélectionnez des tables et devez configurer le nombre de buckets (le paramètre `bucket_count`), cliquez avec le bouton droit sur une table dans la section Selected Objects. Dans la zone Parameter Settings, définissez Enable Parameter Settings sur Yes, spécifiez la Value en fonction de vos besoins métier, puis cliquez sur OK. Remarque Pour sélectionner les opérations SQL pour la migration incrémentielle au niveau de la base de données ou de la table, cliquez avec le bouton droit sur un objet de migration dans la section Selected Objects et sélectionnez les opérations SQL que vous souhaitez migrer dans la boîte de dialogue qui s'affiche. Pour définir des conditions WHERE afin de filtrer les données, cliquez avec le bouton droit sur une table dans la section Selected Objects et spécifiez les conditions de filtrage dans la boîte de dialogue qui s'affiche. Pour plus d'informations, consultez la page Filtrage des données. Si vous utilisez la fonctionnalité de mappage des noms d'objets, d'autres objets dépendant de l'objet remappé peuvent ne pas être migrés.

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é. Vous n'avez pas besoin d'en sélectionner un. Si vous souhaitez des tâches plus stables, vous pouvez acheter un cluster dédié pour exécuter les tâches de migration DTS.
Retry Time for Failed Connections	Après le démarrage de la tâche de migration, si la connexion à la base de données source ou de destination échoue, DTS signale une erreur et commence immédiatement à retenter la connexion. La durée de nouvelle tentative par défaut est de 720 minutes. Vous pouvez personnaliser la durée de nouvelle tentative avec une valeur comprise entre 10 et 1440 minutes. Nous vous recommandons de définir la durée sur plus de 30 minutes. Si DTS se reconnecte aux bases de données source et de destination dans la durée spécifiée, la tâche de migration reprend automatiquement. Sinon, 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ètre de la dernière tâche créée. Comme vous êtes facturé pour la tâche pendant la période de nouvelle tentative de connexion, nous vous recommandons de personnaliser la durée de nouvelle tentative en fonction de vos besoins métier, 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.
Retry Time for Other Issues	Après le démarrage de la tâche de migration, si un problème autre que 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 commence immédiatement à retenter l'opération. La durée de nouvelle tentative par défaut est de 10 minutes. Vous pouvez personnaliser la durée de nouvelle tentative avec une valeur comprise entre 1 et 1440 minutes. Nous vous recommandons de définir la durée sur plus de 10 minutes. Si les opérations associées réussissent dans la durée de nouvelle tentative spécifiée, la tâche de migration reprend automatiquement. Sinon, la tâche échoue. Important La valeur de Retry Time for Other Issues doit être inférieure à la valeur de Retry Time for Failed Connections.
Enable Throttling for Full Data Migration	Pendant 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 Queries per second (QPS) to the source database, RPS of Full Data Migration et Data migration speed for full migration (MB/s) pour réduire la charge sur la base de données de destination. Remarque Cet élément de configuration n'est disponible que si vous sélectionnez Full Data Migration pour Migration Types. Vous pouvez également ajuster la vitesse de migration complète une fois l'instance de migration en cours d'exécution.
Enable Throttling for Incremental 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 RPS of Incremental Data Migration et Data migration speed for incremental migration (MB/s) pour réduire la charge sur la base de données de destination. Remarque Cet élément de configuration n'est disponible que si vous sélectionnez Incremental Data Migration pour Migration Types. Vous pouvez également ajuster la vitesse de migration incrémentielle une fois l'instance de migration en cours d'exécution.
Environment Tag	Vous pouvez sélectionner une balise d'environnement pour identifier l'instance en fonction de vos besoins métier. Ce paramètre n'est pas requis dans cet exemple.
Whether to delete SQL operations on heartbeat tables of forward and reverse tasks	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 amener l'instance DTS à signaler un retard. 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.
Configure ETL	En fonction de vos besoins métier, choisissez de configurer ou non la fonctionnalité ETL pour traiter les données. Yes : Configure la fonctionnalité ETL. Vous devez également saisir des instructions de traitement des données dans la zone de texte. No : Ne configure pas la fonctionnalité ETL.
Monitoring and Alerting	Choisissez de définir ou non des alertes et de recevoir des notifications d'alerte en fonction de vos besoins métier. No : Ne définit pas d'alerte. Yes : Configurez les alertes en définissant un seuil d'alerte et des notifications d'alerte. Si une migration échoue ou si la latence dépasse le seuil, le système envoie une notification d'alerte.

Facultatif : Une fois les configurations précédentes terminées, cliquez sur Next: Configure Database and Table Fields pour définir les paramètres Primary Key Column, Distribution Key et Engine pour les tables de destination.
Remarque
- Cette étape n'est disponible que si vous sélectionnez Schema Migration pour Migration Types lors de la configuration des objets de la tâche. Vous pouvez définir Definition Status sur All et modifier les paramètres.
- Pour Primary Key Column, vous pouvez sélectionner plusieurs colonnes pour former une clé primaire composite. Vous devez également sélectionner une ou plusieurs colonnes dans Primary Key Column comme Distribution Key.
- Pour une table sans clé primaire ni contrainte unique, vous devez sélectionner duplicate pour Engine. Sinon, l'instance risque d'échouer ou des pertes de données peuvent survenir.

Enregistrez la tâche et lancez une prévérification.
- 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 Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters dans la bulle qui s'affiche.
- Si vous n'avez pas besoin d'afficher ou avez terminé d'afficher les paramètres de l'API, cliquez sur Next: Save Task Settings and Precheck en bas de la page.
Remarque
- Avant le démarrage de la tâche de migration, DTS effectue une prévérification. La tâche ne démarre qu'après avoir réussi la prévérification.
- Si la prévérification échoue, cliquez sur View Details à côté de l'élément de vérification ayant échoué, corrigez le problème en suivant les instructions, puis relancez la prévérification.
- Si un avertissement est signalé lors de la prévérification :
  
  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 en suivant les instructions, puis relancez la prévérification.
  
  Pour les éléments de vérification qui peuvent être ignorés, vous pouvez cliquer sur Confirm Alert Details, Ignore, OK et Precheck Again pour ignorer l'élément d'avertissement et relancer la prévérification. 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é.

Achetez une instance.

Lorsque le Success Rate est de 100 %, cliquez sur Next: Purchase Instance.

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

Catégorie	Paramètre	Description
New Instance Class	Resource Group Settings	Sélectionnez le groupe de ressources auquel appartient l'instance. La valeur par défaut est le groupe de ressources par défaut. Pour plus d'informations, consultez la page Qu'est-ce que Resource Management ?
New Instance Class	Instance Class	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 en fonction de votre scénario métier. Pour plus d'informations, consultez la page Spécifications de liaison pour la migration de données.

Une fois la configuration terminée, lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms.
Cliquez sur Buy and Start. Dans la boîte de dialogue OK qui s'affiche, cliquez sur OK.

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 Status passe à Completed.
- 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. Tant que la tâche de migration incrémentielle est en cours d'exécution, le Status de la tâche est Running.

Mappages de types de données

Catégorie	Type MySQL	Type SelectDB
NUMERIC	TINYINT	TINYINT
	TINYINT UNSIGNED	SMALLINT
	SMALLINT	SMALLINT
	SMALLINT UNSIGNED	INT
	MEDIUMINT	INT
	MEDIUMINT UNSIGNED	BIGINT
	INT	INT
	INT UNSIGNED	BIGINT
	BIGINT	BIGINT
	BIGINT UNSIGNED	LARGEINT
	BIT(M)	INT
	DECIMAL	DECIMAL Remarque ZEROFILL n'est pas pris en charge.
	NUMERIC	DECIMAL
	FLOAT	FLOAT
	DOUBLE	DOUBLE
	BOOL BOOLEAN	BOOLEAN
DATE AND TIME	DATE	DATEV2
	DATETIME[(fsp)]	DATETIMEV2
	TIMESTAMP[(fsp)]	DATETIMEV2
	TIME[(fsp)]	VARCHAR
	YEAR[(4)]	INT
STRING	CHAR VARCHAR	VARCHAR Important Lors de la migration des données vers ApsaraDB for SelectDB, les types de données CHAR et VARCHAR(n) sont convertis en VARCHAR(4*n) pour éviter toute perte de données. Si vous ne spécifiez pas de longueur de données, la valeur par défaut est VARCHAR(65533). Si la longueur des données dépasse 65 533, le type de données devient STRING.
	BINARY VARBINARY	STRING
	TINYTEXT TEXT MEDIUMTEXT LONGTEXT	STRING
	TINYBLOB BLOB MEDIUMBLOB LONGBLOB	STRING
	ENUM	STRING
	SET	STRING
	JSON	STRING

Colonnes supplémentaires

Remarque

Ce tableau décrit les colonnes supplémentaires pour les tables cibles utilisant le modèle de clé Duplicate. Ces colonnes sont soit ajoutées automatiquement par DTS, soit doivent être ajoutées manuellement.

Paramètre	Type	Valeur par défaut	Description
_is_deleted	Int	0	Indique si l'enregistrement est supprimé. Insertion : 0 Mise à jour : 0 Suppression : 1
_version	Bigint	0	Pour la migration complète des données, la valeur est 0. Pour la migration incrémentielle des données, la valeur correspond à l'horodatage (en secondes) de l'entrée correspondante dans le journal binaire de la base de données source.
_record_id	Bigint	0	Pour la migration complète des données, la valeur est 0. Pour la migration incrémentielle des données, la valeur correspond à l'ID unique de l'enregistrement issu du journal incrémentiel. Remarque L'ID est unique et s'incrémente automatiquement.

Prérequis

Limitations

Modèle Unique

Modèle Duplicate