Tous les produits
Search
Centre de documentation

ApsaraDB RDS:Migrer une base de données MySQL auto-gérée vers une instance ApsaraDB RDS for MySQL

Dernière mise à jour :Aug 19, 2026

Utilisez Data Transmission Service (DTS) pour migrer votre base de données MySQL auto-gérée—qu'elle soit hébergée sur site, sur une instance Elastic Compute Service (ECS) ou sur un autre cloud—vers ApsaraDB RDS for MySQL avec une interruption minimale, voire nulle.

Ce guide aborde les points suivants :

  • Choix d'une solution de migration

  • Préparation de la base de données source et de l'instance RDS de destination

  • Configuration et exécution de la tâche de migration

  • Vérification des données et basculement de votre application

Choisir une solution de migration

DTS prend en charge trois types de migration que vous pouvez combiner pour élaborer une solution :

Type de migration Fonctionnalité
Schema migration Copie la structure des bases de données, des tables, des vues, des déclencheurs, des procédures stockées et des fonctions. DTS convertit DEFINER en INVOKER dans les vues et les procédures stockées.
Full data migration Copie toutes les données existantes de la base de données source vers l'instance RDS de destination.
Incremental data migration Une fois la migration complète des données lancée, copie continuellement les nouvelles modifications de la base de données source, permettant ainsi une migration avec une interruption quasi nulle.

Combinez ces types en fonction de votre tolérance aux interruptions :

Solution Interruption Cohérence des données Limitations Coût Idéal pour
Schema + full + incremental (recommandé) Nulle Cohérente une fois la migration terminée, même si des écritures se poursuivent pendant la migration La migration incrémentielle s'exécute jusqu'à ce que vous l'arrêtiez manuellement Payant (incrémentiel) Environnements de production, exigence d'interruption nulle
Schema + full Durée de la migration complète Cohérente uniquement si la source est en lecture seule pendant la migration ; incohérente si des écritures ont lieu La source doit être mise au repos pour garantir la cohérence des données Gratuit Environnements de test, interruption acceptable

Facturation

La migration du schéma, la migration complète des données et le trafic sur le réseau public sont gratuits. Les éléments suivants sont facturés :

  • Incremental data migration : Facturé pendant l'exécution. Non facturé en cas de pause ou d'échec.

  • Data verification : Facturé en fonction du volume de données vérifié. Consultez les frais de vérification des données.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

  • Une base de données MySQL source exécutant la version 5.1, 5.5, 5.6, 5,7 ou 8,0

  • Une instance RDS for MySQL de destination disposant de plus d'espace de stockage disponible que la base de données source

Limitations

Examinez les limitations suivantes avant de configurer la tâche de migration.

Exigences relatives à la base de données source :

  • Toutes les tables à migrer doivent posséder une clé primaire ou une contrainte unique avec des valeurs uniques. Sinon, l'instance RDS de destination peut contenir des données en double.

  • Évitez les opérations DDL (modifications de schéma) pendant la migration du schéma et la migration complète des données. La tâche de migration échoue si des opérations DDL sont détectées.

  • Si vous n'effectuez que la migration du schéma et la migration complète (sans migration incrémentielle), évitez d'écrire dans la base de données source pendant la migration afin de maintenir la cohérence des données.

  • Le serveur de la base de données source doit disposer d'une bande passante sortante suffisante. Une bande passante insuffisante réduit la vitesse de migration.

  • Pour la migration incrémentielle des données, la journalisation binaire doit être activée et configurée correctement (voir Configurer la journalisation binaire).

  • Si la base de données source est un cluster à double maître, évitez les basculements primaire/secondaire pendant l'exécution de la tâche de migration. La tâche échoue en cas de basculement.

  • Si la base de données source exécute MySQL 8.0.23 ou une version ultérieure et contient des colonnes invisibles (y compris des clés primaires invisibles générées automatiquement pour les tables sans clé primaire), rendez-les visibles avant la migration :

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

    Consultez Invisible Columns et Generated Invisible Primary Keys pour plus de détails.

Contenu qui ne peut pas être migré :

  • Analyseurs définis à l'aide de la syntaxe de commentaire

  • Données issues des opérations de sauvegarde physique et de récupération ou des opérations de cascade de clés étrangères (non enregistrées dans les journaux binaires)

  • Index et partitions

Autres limitations :

  • Les versions MySQL source et de destination doivent correspondre.

  • Si les données à migrer contiennent des caractères sur quatre octets (caractères rares ou emojis), l'instance RDS de destination et ses tables doivent utiliser le jeu de caractères utf8mb4. Pour la migration du schéma, définissez character_set_server sur utf8mb4 sur l'instance RDS de destination.

  • Si des mappages de noms de colonnes sont configurés, une seule tâche de migration prend en charge jusqu'à 1 000 tables. Créez plusieurs tâches pour les migrations plus importantes.

  • DTS utilise ROUND(COLUMN, PRECISION) pour récupérer les valeurs des colonnes FLOAT et DOUBLE. Si aucune précision n'est spécifiée, FLOAT prend par défaut 38 chiffres et DOUBLE prend par défaut 308 chiffres. Vérifiez que ces paramètres de précision répondent à vos exigences.

  • DTS réessaie les tâches ayant échoué pendant une durée maximale de 7 jours. Avant de basculer les charges de travail vers la destination, arrêtez ou libérez toutes les tâches ayant échoué, ou révoquez les autorisations d'écriture de DTS sur la destination, afin d'éviter que des données obsolètes n'écrasent les nouvelles données.

  • Si une tâche DTS ne parvient pas à s'exécuter, l'assistance technique DTS tentera de restaurer la tâche dans un délai de 8 heures. Pendant la restauration, la tâche peut être redémarrée et ses paramètres peuvent être modifiés.

  • DTS crée automatiquement la base de données de destination si le nom de la base de données source respecte les conventions de nommage d'ApsaraDB RDS for MySQL. Si ce n'est pas le cas, créez la base de données manuellement avant de configurer la tâche de migration.

  • Les opérations DDL en ligne sur la base de données source utilisant pt-online-schema-change ne sont pas prises en charge et entraîneront l'échec de la tâche. Utilisez DMS ou gh-ost à la place.

  • DTS exécute périodiquement CREATE DATABASE IF NOT EXISTS sur la base de données source (en créant une base de données test) pour faire avancer la position du journal binaire.

  • Après un basculement HA dans l'instance RDS de destination, exécutez ANALYZE TABLE <table_name> pour confirmer que les données sont écrites sur le disque et non uniquement en mémoire.

  • Si le chiffrement transparent des données (TDE) est activé sur la base de données source, les trois types de migration sont pris en charge. Si la fonctionnalité EncDB est activée, la migration complète des données n'est pas prise en charge.

  • Dans la migration incrémentielle des données, une instance ApsaraDB RDS for MySQL V5.6 en lecture seule ne peut pas être utilisée comme base de données source car elle n'enregistre pas les journaux de transactions.

Phase 1 : Préparer la migration

Étape 1 : Autoriser DTS à accéder aux ressources cloud

  1. Ouvrez la page d'autorisation rapide avec votre compte Alibaba Cloud et cliquez sur Authorize.

  2. Si vous voyez les messages EntityAlreadyExists.Role et EntityAlreadyExists.Role.Policy, l'autorisation est déjà effectuée.

screenshot_2025-03-21_13-37-47

Étape 2 : Créer des comptes de base de données

Compte pour la base de données source

Exécutez les instructions suivantes sur la base de données source :

-- Replace dts_user and Your_Password123 with actual values.
CREATE USER 'dts_user'@'%' IDENTIFIED BY 'Your_Password123';

-- Required for schema migration and full data migration.
GRANT SELECT ON *.* TO 'dts_user'@'%';

-- Required for incremental data migration.
GRANT REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW ON *.* TO 'dts_user'@'%';

-- Required for DTS to create a heartbeat table to advance the binary log position.
GRANT CREATE ON *.* TO 'dts_user'@'%';

FLUSH PRIVILEGES;

Le tableau suivant résume les autorisations minimales requises pour chaque type de migration :

Type de migration Autorisations requises
Migration du schéma SELECT
Migration complète des données SELECT
Migration incrémentielle des données SELECT ; REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW ; CREATE (pour la table de heartbeat)

Compte pour l'instance RDS de destination

  1. Dans la console RDS, sélectionnez la région et cliquez sur l'ID de l'instance RDS de destination.

  2. Dans le volet de navigation de gauche, cliquez sur Accounts, puis sur Create Account.

  3. Définissez Account Type sur Privileged Account et complétez les autres paramètres.

Le compte de destination nécessite des autorisations de lecture et d'écriture sur l'instance RDS de destination.

Étape 3 : Configurer l'accès à la base de données source

Sélectionnez la méthode d'accès correspondant au déploiement de votre base de données source :

Base de données source Méthode d'accès Configuration
Sur site avec une adresse IP publique Public IP Ajouter les blocs CIDR du serveur DTS à la liste d'autorisation IP de la base de données source
Sur site sans adresse IP publique Cloud Enterprise Network (CEN), Database Gateway ou VPN Gateway/Express Connect/Smart Access Gateway (SAG) Ajouter les blocs CIDR du serveur DTS à la liste d'autorisation IP et compléter la configuration d'accès réseau pour la méthode choisie
Base de données sur une instance ECS ECS instance Aucune configuration requise

Configurer la journalisation binaire pour la migration incrémentielle des données

Ignorez cette étape si vous n'effectuez pas de migration incrémentielle des données.

La journalisation binaire doit être activée sur la base de données source pour la migration incrémentielle des données. Configurez les paramètres suivants, puis redémarrez MySQL pour que les modifications prennent effet.

Paramètres de journalisation binaire

Paramètre Valeur requise Notes
log_bin mysql_bin (ou tout autre chemin) Active la journalisation binaire
binlog_format row Requis pour que DTS capture les modifications au niveau des lignes
binlog_row_image full Requis pour MySQL 5.6 et versions ultérieures
server_id Tout entier supérieur à 1 Doit être unique dans une topologie de réplication
expire_logs_days 7 ou plus Versions MySQL antérieures à 8.0. Par défaut : 0 (n'expire jamais)
binlog_expire_logs_seconds 604800 ou plus (7 jours) MySQL 8.0 et versions ultérieures. Par défaut : 2592000 (30 jours)
log_slave_updates ON Uniquement pour les clusters à double maître

Conservez les journaux binaires pendant au moins 7 jours. Si la période de rétention est trop courte, DTS peut ne pas parvenir à obtenir les journaux binaires requis, ce qui peut entraîner une incohérence ou une perte de données.

Configurer sur Linux

  1. Modifiez /etc/my.cnf :

    log_bin=mysql_bin
    binlog_format=row
    
    # MySQL earlier than 8.0:
    # expire_logs_days=7
    
    # MySQL 8.0 and later:
    # binlog_expire_logs_seconds=604800
    
    server_id=2
    binlog_row_image=full
    
    # Dual-primary clusters only:
    # log_slave_updates=ON
  2. Redémarrez MySQL :

    /etc/init.d/mysqld restart

Configurer sur Windows

  1. Modifiez my.ini :

    log_bin=mysql_bin
    binlog_format=row
    
    # MySQL earlier than 8.0:
    # expire_logs_days=7
    
    # MySQL 8.0 and later:
    # binlog_expire_logs_seconds=604800
    
    server_id=2
    binlog_row_image=full
    
    # Dual-primary clusters only:
    # log_slave_updates=ON
  2. Redémarrez MySQL :

    net stop mysql
    net start mysql

Phase 2 : Configurer la tâche de migration

  1. Connectez-vous à la console DTS, cliquez sur Data Migration dans le volet de navigation de gauche, puis cliquez sur Create Task.

  2. Configurez la base de données source et l'instance RDS de destination.

    Base de données source

    Paramètre Valeur
    Database Type MySQL
    Access Method Sélectionnez la méthode configurée à l'étape 3 (par exemple, Public IP)
    Instance Region Région où se trouve la base de données source
    Domain Name or IP Endpoint public ou adresse IP de la base de données source
    Port Port de service de la base de données source. Par défaut : 3306
    Database Account Compte créé à l'étape 2
    Database Password Mot de passe du compte
    Encryption Non-encrypted si SSL n'est pas activé ; SSL-encrypted si SSL est activé (téléchargez un CA Certificate et définissez la CA Key)

    Instance RDS de destination

    Paramètre Valeur
    Database Type MySQL
    Access Method Alibaba Cloud Instance
    Instance Region Région de l'instance RDS de destination
    Replicate Data Across Alibaba Cloud Accounts No
    RDS Instance ID ID de l'instance RDS de destination
    Database Account Compte privilégié créé à l'étape 2
    Database Password Mot de passe du compte
    Encryption Non-encrypted ou SSL-encrypted. Si SSL-encrypted, activez le chiffrement SSL sur l'instance RDS de destination au préalable
  3. Cliquez sur Test Connectivity and Proceed. Dans la boîte de dialogue, cliquez sur Test Connectivity. Si le test échoue, corrigez le problème en vous basant sur le message d'erreur avant de continuer.

  4. Configurez les objets à migrer.

    Configurer les objets

    Dans l'onglet Configure Objects, définissez les types de migration et sélectionnez les objets à migrer : Cliquez sur Next: Advanced Settings.

    Paramètre Description
    Migration Types Sélectionnez Schema Migration et Full Data Migration pour une migration complète. Ajoutez Incremental Data Migration pour minimiser l'interruption.
    Source Objects Sélectionnez les bases de données, tables ou colonnes à migrer, puis cliquez sur Rightwards arrow pour les ajouter à Selected Objects.
    Selected Objects Cliquez avec le bouton droit sur un objet pour le renommer ou configurer un filtre WHERE. Cliquez sur Batch Edit pour renommer plusieurs objets à la fois.
    Processing Mode of Conflicting Tables Precheck and Report Errors (par défaut) : fait échouer la pré-vérification si la destination contient déjà des tables portant les mêmes noms. Ignore Errors and Proceed : ignore cette vérification ; lors de la migration complète, les enregistrements existants sont conservés ; lors de la migration incrémentielle, les enregistrements existants sont écrasés.
    Method to Migrate Triggers in Source Database Disponible lorsque Schema Migration et Incremental Data Migration sont tous deux sélectionnés. Consultez Synchroniser ou migrer les déclencheurs.
    Whether to migrate Event Indique s'il faut migrer les événements de la base de données source. Si vous sélectionnez Yes, vous devez effectuer les opérations suivantes. Pour plus d'informations, consultez Synchroniser ou migrer les événements.
    Enable Migration Assessment Disponible lorsque Schema Migration est sélectionné. Vérifie si les schémas source et de destination (longueurs des index, procédures stockées, tables dépendantes) sont compatibles. Les résultats sont affichés lors de la pré-vérification mais n'affectent pas le résultat de celle-ci.
    Capitalization of Object Names in Destination Instance Contrôle la casse des noms de bases de données, de tables et de colonnes dans la destination. Par défaut sur DTS default policy. Consultez Spécifier la casse des noms d'objets.

    (Facultatif) Configurations avancées

    (Facultatif) Dans l'onglet Advanced Configurations, ajustez les paramètres selon vos besoins : Cliquez sur Next: Data verification.

    Paramètre Description
    Dedicated Cluster for Task Scheduling Par défaut, les tâches s'exécutent sur le cluster partagé. Achetez un cluster dédié pour une stabilité améliorée.
    Copy the temporary table of the Online DDL tool Si vous utilisez DMS ou gh-ost pour les DDL en ligne sur la source : Yes migre les données de la table temporaire (peut augmenter la latence) ; No, Adapt to DMS Online DDL migre uniquement les opérations DDL d'origine ; No, Adapt to gh-ost migre uniquement les DDL d'origine de gh-ost.
    Whether to Migrate Accounts Migre les informations de compte depuis la source. Si activé, sélectionnez les comptes à migrer et vérifiez les autorisations des comptes.
    Retry Time for Failed Connections Durée pendant laquelle DTS réessaie après un échec de connexion. Plage : 10–1 440 minutes. Par défaut : 720 minutes. Définissez au moins 30 minutes.
    Retry Time for Other Issues Durée pendant laquelle DTS réessaie après des échecs DDL ou DML. Plage : 1–1 440 minutes. Par défaut : 10 minutes. Doit être inférieur à Retry Time for Failed Connections.
    Enable Throttling for Full Data Migration Limite les QPS vers la base de données source, les RPS pour la migration complète et la vitesse de migration (Mo/s). Utilisez cette option pour réduire la charge sur les serveurs de base de données.
    Enable Throttling for Incremental Data Migration Limite les RPS et la vitesse de migration (Mo/s) pour la migration incrémentielle.
    Configure ETL Active le traitement extract, transform, and load (ETL). Consultez Configurer ETL.
    Monitoring and Alerting Envoie des alertes lorsque la tâche échoue ou que la latence dépasse un seuil. Consultez Configurer la surveillance et les alertes.
    Whether to delete SQL operations on heartbeat tables Yes : n'écrit pas le SQL de heartbeat dans la source (la latence de migration peut être affichée). No : écrit le SQL de heartbeat dans la source (peut affecter la sauvegarde physique et le clonage).

    (Facultatif) Vérification des données

    (Facultatif) Dans l'onglet Data Verification, configurez la vérification des données : Si vous configurez la vérification complète des données, définissez les paramètres suivants : Si vous configurez la vérification incrémentielle des données, définissez le paramètre Incremental Verification Benchmark pour filtrer les opérations DML à vérifier. Pour configurer des alertes pour la vérification des données, définissez Full Data Verification Alert ou Incremental Data Verification Alert sur Yes, puis sélectionnez et configurez les règles d'alerte. Pour recevoir des notifications d'alerte, abonnez-vous aux messages d'alerte dans CloudMonitor. Consultez Configurer des règles d'alerte pour les tâches DTS.

    Méthode de vérification Coût Description
    Full Data Verification Facturé Compare les données entre la source et la destination après la migration complète
    Incremental Data Verification Facturé Compare les données pendant la migration incrémentielle
    Schema Verification Gratuit Vérifie la compatibilité du schéma entre la source et la destination

    Sélectionnez une ou plusieurs méthodes de vérification des données en fonction de vos besoins métier.

    1. Vérification complète des données

      Configurez les paramètres suivants si vous sélectionnez la vérification complète des données.

      Paramètre Description
      Full Data Verification Full field validation by row sampling : échantillonne un pourcentage de lignes (10–100 %) pour une comparaison complète des champs. Verify based on the number of table rows : compare uniquement le nombre de lignes (gratuit).
      Full Data Verification Time Rule Seule l'option Start Now est prise en charge.
      Timeout Settings for Full Data Verification Définissez un délai d'expiration (1–72 heures) pour terminer automatiquement la tâche de vérification si elle s'exécute trop longtemps.
      Full calibration reference Default : utilise l'union de la source et de la destination comme référence. Source Database : vérifie que la destination correspond à la source. Destination Database : vérifie que la source correspond à la destination.

      Vérification incrémentielle des données

Phase 3 : Exécuter la pré-vérification et démarrer la migration

  1. Cliquez sur Next: Save Task Settings and Precheck. DTS valide votre configuration et votre environnement.

  2. Attendez que la pré-vérification soit terminée :

    • Si le Success Rate atteint 100%, l'environnement est prêt. Examinez tous les avertissements pour confirmer qu'ils ne présentent aucun risque, puis ignorez-les et poursuivez.

    • Si la pré-vérification échoue, cliquez sur View Details, corrigez le problème et relancez la pré-vérification.

  3. Cliquez sur Next: Purchase Instance.

  4. Sélectionnez un Resource Group (par défaut : default resource group) et la spécification d'instance DTS appropriée.

  5. Acceptez les Data Transmission Service (Pay-As-You-Go) Terms of Service, cliquez sur Purchase and Start, puis sur Confirm. La tâche de migration démarre automatiquement.

Phase 4 : Vérifier les données et effectuer le basculement

  1. Surveillez l'état de la tâche de migration :

    • Les tâches sans migration incrémentielle des données affichent Status: Completed une fois terminées.

    • Les tâches avec migration incrémentielle des données affichent Status: Running et ne se terminent pas automatiquement.

  2. Une fois la migration complète terminée et la latence de la migration incrémentielle proche de zéro, vérifiez la cohérence des données : Option 1 — Vérification automatique : Configurer une tâche de vérification des données dans DTS. Option 2 — Vérification manuelle : Exécutez les requêtes suivantes sur la base de données source et sur l'instance RDS de destination, puis comparez les résultats :

    -- Compare row counts
    SELECT COUNT(*) FROM <your_table>;
    
    -- Compare key business metrics
    SELECT SUM(amount) FROM orders WHERE create_time >= '2024-01-01';
  3. Effectuez le basculement de votre application pendant les heures creuses :

    1. Arrêtez votre application.

    2. Confirmez que la latence de la migration incrémentielle a atteint zéro.

    3. Mettez à jour les chaînes de connexion de base de données de votre application vers l'endpoint de l'instance RDS de destination.

    4. Libérez la tâche de migration une fois le basculement terminé.

Opérations SQL prises en charge pour la migration incrémentielle des données

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
Important

Les opérations RENAME TABLE peuvent provoquer une incohérence des données. Si vous renommez une table pendant la migration et que vous avez sélectionné cette table (plutôt que sa base de données parente) comme objet de migration, les données de la table renommée ne seront pas migrées. Pour éviter cela, sélectionnez la base de données comme objet de migration et assurez-vous que les noms de base de données avant et après le renommage sont inclus dans le périmètre de migration.

FAQ

Q : Pourquoi DTS échoue-t-il à se connecter avec l'erreur « Host 'XXX' is not allowed to connect to this MySQL server » ?

Il s'agit d'une erreur de connexion Java Database Connectivity (JDBC). Vérifiez que les identifiants du compte sont corrects et que le compte dispose des autorisations requises. L'utilisation d'un compte privilégié pour tester la connexion peut aider à isoler le problème.

Q : Pourquoi ne puis-je pas sélectionner une instance RDS dans la région Chine (Fuzhou) lors de la création d'une tâche de migration ?

DTS ne prend pas en charge les instances dans la région Chine (Fuzhou). Comme alternative, sauvegardez une base de données MySQL 5.7 ou 8,0 auto-gérée vers le cloud.