Utilisez Data Transmission Service (DTS) pour migrer des données entre des instances ApsaraDB RDS for MySQL. DTS prend en charge la migration de schéma, la migration complète des données et la migration incrémentielle des données. La sélection des trois types de migration permet de maintenir les services en cours d'exécution sans interruption pendant la migration.
Cette rubrique couvre la migration entre des instances RDS appartenant au même compte Alibaba Cloud. Pour effectuer une migration entre différents comptes, consultez Configurer une tâche de migration DTS entre des comptes Alibaba Cloud. Avant d'utiliser DTS, assurez-vous que le service dispose des permissions nécessaires pour accéder aux ressources Alibaba Cloud. Consultez les rubriques Qu'est-ce que DTS ? et Autoriser DTS à accéder aux ressources Alibaba Cloud.
Prérequis
Avant de commencer, assurez-vous que :
Les instances source et destination ApsaraDB RDS for MySQL sont créées. Consultez la rubrique Créer une instance ApsaraDB RDS for MySQL.
L'espace de stockage disponible de l'instance de destination est supérieur à celui de l'instance source.
Types de migration
| Type de migration | Description |
|---|---|
| Schema migration | Migre les schémas des objets sélectionnés (tables, vues, déclencheurs, procédures stockées, fonctions stockées) de la source vers la destination. Pendant la migration, DTS modifie l'attribut SECURITY de DEFINER à INVOKER pour les vues, les procédures stockées et les fonctions, et définit le DEFINER sur le compte de base de données de destination. DTS ne migre pas les informations utilisateur. Pour appeler une vue, une procédure stockée ou une fonction stockée sur la destination, accordez les permissions de lecture et d'écriture à INVOKER. |
| Full data migration | Migre toutes les données historiques des objets sélectionnés de la source vers la destination. |
| Incremental data migration | Une fois la migration complète des données terminée, migre les modifications en cours de la source vers la destination. Utilisez cette option pour maintenir les services en cours d'exécution sans interruption pendant la migration. |
Pendant la migration de schéma, le
routine_body
des procédures stockées et des fonctions, ainsi que le
select_statement
des vues ne peuvent pas être modifiés. L'attribut SECURITY et le DEFINER ne peuvent pas être modifiés pendant la migration.
Facturation
| Type de migration | Frais de configuration de l'instance | Frais de trafic Internet |
|---|---|---|
| Migration de schéma et migration complète des données | Gratuit | Facturé lorsque la valeur de Access Method est définie sur Public IP Address. Consultez la rubrique Présentation de la facturation. |
| Migration incrémentielle des données | Facturé. Consultez la rubrique Présentation de la facturation. |
Opérations SQL prises en charge pour la migration incrémentielle
| Type d'opération | Instructions SQL |
|---|---|
| DML | INSERT, UPDATE, DELETE |
| DDL | ALTER TABLE, ALTER VIEW, CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW, DROP INDEX, DROP TABLE, RENAME TABLE, TRUNCATE TABLE |
Les opérations RENAME TABLE peuvent entraîner une incohérence des données. Si vous sélectionnez une table comme objet de migration et que vous la renommez pendant la migration, les données de cette table ne seront pas migrées vers la destination. Pour éviter cela, sélectionnez la base de données contenant la table comme objet de migration et assurez-vous que la base de données est incluse dans le périmètre de migration avant et après l'opération RENAME TABLE.
Limites
Examinez les limites suivantes avant de configurer une tâche de migration. La plupart des limites s'appliquent au moment de la création de la tâche et ne peuvent pas être modifiées par la suite.
Pendant la migration de schéma, DTS migre les clés étrangères de la base de données source vers la base de données de destination.
Pendant la migration complète des données et la migration incrémentielle des données, DTS désactive temporairement la vérification des contraintes et les opérations en cascade sur les clés étrangères au niveau de la session. Si vous effectuez des opérations de mise à jour et de suppression en cascade sur la base de données source pendant la migration des données, une incohérence des données peut se produire.
Exigences relatives à la base de données source
| Limite | Solution de contournement |
|---|---|
| Le serveur hébergeant la base de données source doit disposer d'une bande passante sortante suffisante. Une bande passante insuffisante réduit la vitesse de migration. | Planifiez la migration pendant les heures creuses et activez la limitation du débit dans les paramètres avancés. |
| Les tables à migrer doivent comporter des contraintes PRIMARY KEY ou UNIQUE avec tous les champs uniques. Sans ces contraintes, la destination peut contenir des enregistrements en double. | Ajoutez une clé primaire ou une contrainte unique à la table avant la migration. |
| Si vous sélectionnez des tables comme objets de migration et que vous devez renommer des tables ou des colonnes dans la destination, une seule tâche prend en charge jusqu'à 1 000 tables. | Pour plus de 1 000 tables, configurez plusieurs tâches ou migrez la base de données entière à la place. |
Pour la migration incrémentielle des données : la journalisation binaire doit être activée, binlog_format doit être défini sur row et binlog_row_image doit être défini sur full. Si ces conditions ne sont pas remplies, la pré-vérification échoue. |
Activez la journalisation binaire et définissez les paramètres requis avant de démarrer la tâche. Pour une base de données MySQL gérée par l'utilisateur dans un cluster à deux nœuds principaux, définissez également log_slave_updates sur ON. |
| Pour la migration incrémentielle des données : les journaux binaires doivent être conservés pendant au moins 7 jours. Une conservation plus courte peut empêcher DTS d'obtenir les journaux, ce qui entraîne une incohérence ou une perte de données, et le SLA de DTS peut ne pas être garanti. | Étendez la période de conservation des journaux binaires à au moins 7 jours avant de démarrer la migration. |
| Pendant la migration de schéma et la migration complète des données, n'exécutez pas d'instructions DDL pour modifier les schémas de base de données ou de tables. Cela entraînerait l'échec de la tâche. | Planifiez et effectuez toutes les modifications de schéma avant de démarrer la tâche de migration. |
| Si vous exécutez uniquement la migration complète des données (sans migration incrémentielle), n'écrivez pas de données dans la source pendant la migration. | Sélectionnez conjointement la migration de schéma, la migration complète des données et la migration incrémentielle des données pour maintenir la cohérence des données. |
| Les modifications de données issues d'opérations de journal binaire — telles que les données restaurées à partir d'une sauvegarde physique ou les opérations en cascade — ne sont pas enregistrées et ne seront pas migrées tant que l'instance est en cours d'exécution. | Exécutez à nouveau une migration complète des données une fois l'exécution de l'instance terminée, si votre activité le permet. |
| Pour MySQL 8.0.23 ou version ultérieure : les colonnes invisibles entraînent une perte de données car DTS ne peut pas obtenir ces données. | Exécutez ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; pour rendre les colonnes visibles avant la migration. Consultez la documentation Invisible Columns. Les tables sans clés primaires génèrent automatiquement des clés primaires invisibles ; rendez-les également visibles. Consultez la documentation Generated Invisible Primary Keys. |
Limites générales
| Limite | Solution de contournement |
|---|---|
| Les versions des bases de données MySQL source et de destination doivent être identiques. | Vérifiez la compatibilité des versions avant de démarrer la migration. |
| DTS ne migre pas les données lorsqu'un analyseur défini à l'aide de commentaires est utilisé. | Supprimez les analyseurs basés sur des commentaires avant la migration. |
| Pour les bases de données de destination MySQL 8.0.23 ou version ultérieure : les colonnes de destination invisibles entraînent l'échec de la tâche et une perte de données. | Exécutez ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; sur la destination avant de démarrer la tâche. |
Si vous n'utilisez pas la migration de schéma DTS, assurez-vous manuellement de la compatibilité des types de champs. Par exemple, si un champ source est de type text mais que le champ de destination est de type varchar(255), les données peuvent être tronquées. |
Utilisez la migration de schéma DTS ou vérifiez et alignez manuellement les types de champs dans la destination avant la migration. |
| Si les données de migration incluent des caractères sur 4 octets (caractères rares ou emojis), la base de données et les tables de destination doivent utiliser le jeu de caractères UTF8mb4. | Si vous utilisez la migration de schéma DTS, définissez character_set_server dans la destination sur UTF8mb4. Si vous n'utilisez pas la migration de schéma, définissez le jeu de caractères manuellement avant la migration. |
| La migration complète des données consomme des ressources de lecture et d'écriture sur la source et la destination, ce qui peut augmenter la charge du serveur. | Planifiez la migration pendant les heures creuses et activez la limitation du débit dans les paramètres avancés. |
| Pendant la migration complète des données, les opérations INSERT concurrentes provoquent une fragmentation des tables dans la destination. Après la migration, l'espace de table de la destination sera plus grand que celui de la source. | Exécutez OPTIMIZE TABLE sur la destination après la migration si la taille de l'espace de table est préoccupante. |
Pour les colonnes FLOAT ou DOUBLE : DTS utilise ROUND(COLUMN,PRECISION). Si aucune précision n'est spécifiée, DTS utilise par défaut 38 chiffres pour FLOAT et 308 chiffres pour DOUBLE. |
Vérifiez que les valeurs de précision par défaut répondent à vos exigences avant de démarrer la tâche. |
| DTS tente de reprendre les tâches ayant échoué pendant une durée maximale de 7 jours. Si elles ne sont pas arrêtées avant le basculement des charges de travail, une tâche reprise peut écraser les données de destination avec les données source. | Arrêtez ou libérez toutes les tâches ayant échoué avant de basculer les charges de travail vers la destination. Vous pouvez également exécuter REVOKE pour révoquer les permissions d'écriture des comptes DTS sur la destination. |
| Si les instructions DDL échouent lors de leur exécution sur la destination, la tâche DTS continue. | Affichez les instructions DDL ayant échoué dans les journaux de tâche. Consultez la rubrique Afficher les journaux de tâche. |
| Si les noms de colonnes au sein d'une même table MySQL de destination ne diffèrent que par la casse, les résultats peuvent être inattendus car les noms de colonnes MySQL ne sont pas sensibles à la casse. | Normalisez la casse des noms de colonnes dans la destination avant la migration. |
| Une fois la migration terminée (l'état Status de l'instance passe à Completed), les données écrites pendant un basculement de haute disponibilité (HA) peuvent exister uniquement en mémoire, ce qui entraîne une perte de données. | Exécutez analyze table <table name> sur la destination après la migration pour vérifier que les données ont été écrites avec succès. |
| Les instances RDS MySQL activées pour EncDB ne prennent pas en charge la migration complète des données. | Désactivez EncDB ou utilisez une autre approche de migration. Remarque : les instances RDS MySQL activées pour TDE prennent en charge la migration de schéma, la migration complète des données et la migration incrémentielle des données. |
| Si une tâche DTS échoue, l'assistance technique DTS tentera de la restaurer dans un délai de 8 heures. Pendant la restauration, la tâche peut être redémarrée et les paramètres de tâche (et non les paramètres de base de données) peuvent être modifiés. | Aucune action requise ; cette opération est gérée par l'assistance DTS. |
Cas particuliers
| Scénario | Limite | Solution de contournement |
|---|---|---|
| Source MySQL gérée par l'utilisateur | Un basculement principal/secondaire pendant l'exécution de la tâche entraîne l'échec de celle-ci. | Évitez les basculements pendant la migration. |
| Source MySQL gérée par l'utilisateur | DTS exécute CREATE DATABASE IF NOT EXISTS \ test\`` dans la source selon une planification pour faire avancer la position du journal binaire. Si aucune opération DML n'est exécuté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 valeur de latence. Si vous migrez une base de données entière, créez une table de heartbeat qui reçoit des données chaque seconde. |
| Source ApsaraDB RDS for MySQL | Une instance ApsaraDB RDS for MySQL V5.6 en lecture seule qui n'enregistre pas les journaux de transaction ne peut pas être utilisée comme source pour la migration incrémentielle des données. | Utilisez une autre instance source ou un autre type de migration. |
| Source ApsaraDB RDS for MySQL | DTS exécute CREATE DATABASE IF NOT EXISTS \ test\`` dans la base de données source selon une planification pour faire avancer la position du fichier de journal binaire. |
Aucune action requise ; cette opération est gérée automatiquement par DTS. |
| Destination ApsaraDB RDS for MySQL | DTS crée automatiquement la base de données de destination. Toutefois, si le nom de la base de données source n'est pas conforme aux conventions de nommage d'ApsaraDB RDS for MySQL, la création automatique échoue. | Créez manuellement la base de données dans l'instance de destination avant de configurer la tâche de migration. Consultez la rubrique Gérer les bases de données. |
Pour migrer les comptes de la base de données source, examinez d'abord les prérequis et les exigences. Consultez la rubrique Migrer les comptes de base de données.
Configurer une tâche de migration
Les étapes suivantes vous guident dans la création et l'exécution d'une tâche de migration DTS.
Étape 1 : Accéder à la page Data Migration
Utilisez l'une des méthodes suivantes :
Console DTS
Connectez-vous à la console DTS.DTS console
Dans le volet de navigation de gauche, cliquez sur Data Migration.
Dans le coin supérieur gauche, sélectionnez la région où réside l'instance de migration.
Console DMS
Les étapes réelles peuvent varier en fonction du mode et de la disposition de la console DMS. Consultez
et
Customize the layout and style of the DMS console
.
Connectez-vous à la console DMS.DMS console
Dans la barre de navigation supérieure, placez le pointeur sur Data + AI > DTS (DTS) > Data Migration.
Dans la liste déroulante située à droite de Data Migration Tasks, sélectionnez la région où réside l'instance de migration.
Étape 2 : Créer une tâche
Cliquez sur Create Task pour accéder à la page de configuration de la tâche.
Facultatif : Si Back to Previous Version n'apparaît pas dans le coin supérieur droit, cliquez sur New Configuration Page pour basculer vers la nouvelle page de configuration.
Les paramètres spécifiques diffèrent entre les versions nouvelle et précédente de la page de configuration. Utilisez la nouvelle version.
Étape 3 : Configurer les bases de données source et de destination
Après avoir configuré les bases de données source et de destination, lisez les Limits affichées en haut de la page. Ignorer ces limites peut entraîner l'échec de la tâche ou provoquer une incohérence des données.
Configurez les paramètres suivants :
| Section | Parameter | Description |
|---|---|---|
| N/A | Data Migration | Le nom de la tâche DTS. DTS génère automatiquement un nom. Spécifiez un nom descriptif pour faciliter l'identification. L'unicité n'est pas requise. |
| Data + AI | Select a DMS database instance. | Dans cet exemple, aucune instance de base de données n'est sélectionnée. Configurez les informations de la base de données ci-dessous. |
| DTS (DTS) | Sélectionnez Data Migration. | |
| Data Migration Tasks | Sélectionnez Create Task. | |
| Back to Previous Version | La région où réside l'instance ApsaraDB RDS for MySQL source. | |
| New Configuration Page | Sélectionnez Limits pour une migration au sein du même compte. Pour migrer entre différents comptes, sélectionnez Task Namealert notification settings. Consultez Configurer une tâche DTS entre des comptes Alibaba Cloud. | |
| Source Database | L'ID de l'instance ApsaraDB RDS for MySQL source. Les instances source et de destination peuvent être identiques ou différentes — DTS prend en charge les migrations au sein d'une même instance et entre instances. | |
| Database Type | Le compte de base de données pour l'instance source. Consultez la section relative aux autorisations de cette rubrique pour connaître les autorisations requises. | |
| MySQL | Le mot de passe utilisé pour accéder à l'instance source. | |
| Connection Method | Sélectionnez Alibaba Cloud Instance ou Instance Region selon vos besoins. Pour utiliser le chiffrement SSL, activez d'abord SSL sur l'instance RDS MySQL. Consultez Utiliser un certificat cloud pour activer le chiffrement SSL. | |
| Destination Database | Select a DMS database instance. | Dans cet exemple, aucune instance de base de données n'est sélectionnée. Configurez les informations de la base de données ci-dessous. |
| Database Type | Sélectionnez Yes. | |
| Access Method | Sélectionnez Database Account. | |
| Database Password | La région où réside l'instance ApsaraDB RDS for MySQL de destination. | |
| Cross-account | Sélectionnez No pour une migration au sein du même compte. | |
| SSL-encrypted | L'ID de l'instance ApsaraDB RDS for MySQL de destination. | |
| Database Account | Le compte de base de données pour l'instance de destination. Consultez la section relative aux autorisations de cette rubrique pour connaître les autorisations requises. | |
| Database Password | Le mot de passe utilisé pour accéder à l'instance de destination. | |
| MySQL | Sélectionnez Non-encrypted ou Alibaba Cloud Instance selon vos besoins. Si vous utilisez le chiffrement SSL, activez-le d'abord sur l'instance de destination. |
Étape 4 : Tester la connectivité et continuer
Cliquez sur Test Connectivity and Proceed.
DTS ajoute automatiquement ses blocs CIDR de serveur à la liste d'autorisation IP des instances de base de données Alibaba Cloud (telles que ApsaraDB RDS for MySQL et ApsaraDB for MongoDB) ainsi qu'aux règles de groupe de sécurité des instances Elastic Compute Service (ECS). Pour les bases de données gérées par l'utilisateur hébergées sur plusieurs instances ECS, ajoutez manuellement les blocs CIDR DTS aux règles de groupe de sécurité de chaque instance ECS. Pour les bases de données gérées par l'utilisateur dans des centres de données ou provenant de fournisseurs de cloud tiers, ajoutez manuellement les blocs CIDR DTS à la liste d'autorisation de la base de données. Consultez Add the CIDR blocks of DTS servers.
L'ajout de blocs CIDR DTS à une liste d'autorisation de base de données ou aux règles de groupe de sécurité ECS introduit des risques de sécurité. Avant d'utiliser DTS, prenez conscience de ces risques et adoptez des mesures préventives, telles que : renforcer la sécurité des noms d'utilisateur et des mots de passe, limiter les ports exposés, authentifier les appels API, auditer régulièrement la liste d'autorisation et les règles de groupe de sécurité, et supprimer les blocs CIDR non autorisés. Pour une connectivité plus sécurisée, connectez votre base de données à DTS via Express Connect, VPN Gateway ou Smart Access Gateway.
Étape 5 : Configurer les objets de migration
Sur la page Configure Objects, définissez les paramètres suivants :
| Parameter | Description |
|---|---|
| Instance Region | Sélectionnez les types de migration selon vos besoins :<br>- Pour une migration complète uniquement : sélectionnez Cross-account et Full Data Migration.<br>- Pour maintenir les services en cours d'exécution pendant la migration : sélectionnez RDS Instance ID, Full Data Migration et Incremental Data Migration.<br><br> Remarque
Si Connection Method n'est pas sélectionné, créez manuellement la base de données et la table cibles dans la destination avant de démarrer, et activez le mappage des noms d'objets dans Non-encrypted. Si SSL-encrypted n'est pas sélectionné, n'écrivez pas dans la base de données source pendant la migration afin de maintenir la cohérence des données. |
| Test Connectivity and Proceed | La méthode de migration des déclencheurs. Configurez selon vos besoins. Disponible uniquement lorsque Configure Objects et Migration Types sont tous deux sélectionnés. Consultez Synchroniser ou migrer les déclencheurs depuis la base de données source. |
| Enable Migration Assessment | Indique s'il faut évaluer la compatibilité du schéma (longueur des index, procédures stockées, tables dépendantes, etc.) avant la migration. Disponible uniquement lorsque Schema Migration est sélectionné. La sélection de Schema Migration peut prolonger la durée de la prévérification. Les résultats de l'évaluation sont visibles lors de la prévérification mais n'affectent pas les résultats de celle-ci. |
| Processing Mode of Conflicting Tables | Comment gérer les tables de la destination qui partagent les mêmes noms que les tables sources :<br>- Precheck and Report Errors : échoue la prévérification si des noms de tables identiques existent. Pour résoudre ce problème, renommez les tables de destination en utilisant le mappage des noms d'objets. Consultez Mapper les noms d'objets.<br>- Schema Migration : ignore la vérification des conflits de noms.<br><br> Avertissement
Si Selected Objects est sélectionné : lors de la migration complète des données, DTS ignore les enregistrements conflictuels (les enregistrements existants dans la destination sont conservés) ; lors de la migration incrémentielle des données, les enregistrements conflictuels écrasent les enregistrements de destination. Si les schémas diffèrent, seules certaines colonnes peuvent être migrées ou la tâche peut échouer. |
| Capitalization of Object Names in Destination Instance | La casse des noms de base de données, de tables et de colonnes dans la destination. La valeur par défaut est Method to Migrate Triggers in Source Database. Consultez Spécifier la casse des noms d'objets dans l'instance de destination. |
| Schema Migration | Sélectionnez des objets dans la section Incremental Data Migration et cliquez sur l'icône de flèche pour les déplacer vers Selected Objects. Granularité sélectionnable : colonnes, tables ou bases de données. La sélection de tables ou de colonnes exclut d'autres objets tels que les vues, les déclencheurs et les procédures stockées. |
| Schema Migration | Pour renommer un seul objet dans la destination, faites un clic droit dessus dans la section Selected Objects. Pour un renommage en masse, cliquez sur Batch Edit. Consultez Mapper les noms d'objets.<br><br> Remarque
Le renommage d'un objet peut empêcher la migration des objets dépendants. Pour filtrer les lignes par condition, faites un clic droit sur une table et spécifiez les conditions WHERE. Consultez Spécifier les conditions de filtrage. Pour limiter les opérations DML ou DDL incrémentielles à des objets spécifiques, faites un clic droit sur l'objet et sélectionnez les opérations à inclure. |
Cliquez sur Next: Advanced Settings.
Étape 6 : Configurer les paramètres avancés
| Parameter | Description |
|---|---|
| Dedicated Cluster for Task Scheduling | Par défaut, DTS planifie la tâche sur le cluster partagé. Achetez un cluster dédié pour une meilleure stabilité des tâches. Consultez Qu'est-ce qu'un cluster dédié DTS ?. |
| Ignore Errors and Proceed | S'applique lors de l'utilisation de DMS ou gh-ost pour les opérations DDL en ligne sur la source. Options :<br>- Yes : migre les données de la table temporaire (peut provoquer une latence).<br>- No, Adapt to DMS Online DDL : migre uniquement les opérations DDL originales de DMS ; les tables de destination peuvent être verrouillées.<br>- DTS default policy : migre uniquement les opérations DDL originales de gh-ost ; les tables de destination peuvent être verrouillées. Utilisez l'expression régulière par défaut ou personnalisée pour filtrer les tables fantômes gh-ost.<br><br> Important
N'utilisez pas pt-online-schema-change pour les DDL en ligne sur la source — cela provoque l'échec de la tâche DTS. |
| Source Objects | Indique s'il faut migrer les informations de compte de la base de données source. Si Source Objects, sélectionnez les comptes à migrer et vérifiez les autorisations pour les comptes source et de destination. |
| Retry Time for Failed Connections | Durée pendant laquelle DTS effectue des tentatives après un échec de connexion. Valeurs valides : 10–1 440 minutes. Par défaut : 720 minutes. Définissez une valeur d'au moins 30 minutes. Si la reconnexion réussit dans ce délai, DTS reprend la tâche. Sinon, la tâche échoue.<br><br> Remarque
Lorsque plusieurs tâches partagent la même base de données source ou de destination et ont des plages de temps de nouvelle tentative différentes, la valeur spécifiée en dernier est prioritaire. DTS facture l'instance pendant la nouvelle tentative. Définissez le temps de nouvelle tentative en fonction de vos besoins métier et libérez l'instance rapidement lorsqu'elle n'est plus nécessaire. |
| Retry Time for Other Issues | Durée pendant laquelle DTS effectue des tentatives après des échecs d'opérations DDL ou DML. Valeurs valides : 1–1 440 minutes. Par défaut : 10 minutes. Définissez une valeur d'au moins 10 minutes. Cette valeur doit être inférieure à Selected Objects. |
| Enable Throttling for Full Data Migration | Indique s'il faut limiter l'utilisation des ressources lors de la migration complète des données pour réduire la charge sur les serveurs de base de données. Configurez Next: Advanced Settings, RPS of Full Data Migration et Copy the temporary table of the Online DDL tool that is generated in the source table to the destination database.. Disponible uniquement lorsque Full Data Migration est sélectionné. |
| Enable Throttling for Incremental Data Migration | Indique s'il faut limiter l'utilisation des ressources lors de la migration incrémentielle des données. Configurez No, Adapt to gh-ost et Whether to Migrate Accounts. Disponible uniquement lorsque Incremental Data Migration est sélectionné. |
| Environment Tag | Un tag facultatif pour identifier l'instance DTS. |
| Whether to delete SQL operations on heartbeat tables of forward and reverse tasks | Indique s'il faut écrire les opérations SQL de la table de heartbeat dans la base de données source pendant l'exécution de l'instance :<br>- Yes : les opérations de heartbeat ne sont pas écrites dans la source. Une valeur de latence peut s'afficher pour l'instance DTS.<br>- No : les opérations de heartbeat sont écrites dans la source. La sauvegarde physique et le clonage de la source peuvent être affectés. |
| Queries per second (QPS) to the source database | Indique s'il faut activer l'extraction, la transformation et le chargement (ETL). Sélectionnez Yes pour saisir des instructions de traitement des données. Consultez Configurer ETL dans une tâche de migration ou de synchronisation de données. Pour plus de détails sur ETL, consultez Qu'est-ce que ETL ?. |
| Data migration speed for full migration (MB/s) | Indique s'il faut configurer des alertes. Si Yes, définissez le seuil d'alerte et les paramètres de notification. DTS envoie des alertes lorsque la tâche échoue ou que la latence de migration dépasse le seuil. Consultez Configurer la surveillance et les alertes lors de la création d'une tâche DTS. |
Étape 7 : Configurer la vérification des données
Cliquez sur Next Step: Data Verification pour configurer une tâche de vérification des données. Consultez Configure a data verification task.
Étape 8 : Enregistrer les paramètres et exécuter une prévérification
Pour afficher un aperçu des paramètres API pour cette configuration, placez le pointeur sur Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters.
Pour continuer, cliquez sur Next: Save Task Settings and Precheck.
DTS exécute une prévérification avant le démarrage de la tâche. La tâche ne peut démarrer qu'après avoir réussi la prévérification.
Si la prévérification échoue, cliquez sur View Details à côté de chaque élément ayant échoué. Corrigez les problèmes en fonction des résultats de la vérification, puis cliquez sur Precheck Again.
-
Si une alerte est déclenchée :
Pour les alertes qui ne peuvent pas être ignorées : cliquez sur View Details, corrigez les problèmes, puis cliquez sur Precheck Again.
Pour les alertes qui peuvent être ignorées : cliquez sur Confirm Alert Details > Ignore > OK, puis cliquez sur Precheck Again.
RemarqueIgnorer les alertes peut provoquer une incohérence des données et exposer votre activité à des risques potentiels.
Étape 9 : Acheter une instance de migration
Attendez que le Success Rate atteigne 100 %, puis cliquez sur Next: Purchase Instance.
-
Sur la page Purchase Instance, configurez les éléments suivants :
Section Parameter Description New Instance Class RPS of Incremental Data Migration Le groupe de ressources pour l'instance de migration. Par défaut : Data migration speed for incremental migration (MB/s). Consultez Qu'est-ce que Resource Management ?. Incremental Data Migration La classe d'instance détermine la vitesse de migration. Sélectionnez en fonction de votre scénario. Consultez Classes d'instances des instances de migration de données. Lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms en cochant la case correspondante.
Cliquez sur Buy and Start. Dans la boîte de dialogue de confirmation, cliquez sur OK.
Suivez la progression de la migration sur la page Data Migration.
Étapes suivantes
Une fois la migration terminée (l'état de l'instance, indiqué dans le champ Status, passe à Completed) :
Exécutez la commande
analyze table <table name>sur l'instance de destination pour vérifier que les données ont été écrites correctement.Arrêtez ou libérez l'instance de migration DTS avant de basculer les charges de travail vers la base de données de destination.