Data Transmission Service (DTS) migre des données entre différentes sources. Il prend en charge la migration vers le cloud, la migration inter-instances au sein d'Alibaba Cloud, ainsi que le partitionnement et la mise à l'échelle des bases de données. La procédure suivante utilise un cluster dédié DTS avec ApsaraDB RDS for MySQL comme source et destination.
Prérequis
Avant de commencer, assurez-vous de disposer des éléments suivants :
Un cluster dédié DTS. Consultez la rubrique Créer un cluster dédié DTS
Des instances source et destination ApsaraDB RDS for MySQL. Consultez la rubrique Créer une instance ApsaraDB RDS for MySQL
Un espace de stockage disponible suffisant sur l'instance de destination pour accueillir l'intégralité des données source
L'accès à Internet activé pour l'instance source ou de destination, si l'instance et le cluster dédié DTS se trouvent dans des régions différentes
Facturation
Vous êtes facturé uniquement pour les ressources du cluster dédié DTS. La création d'une tâche de migration dans un cluster dédié n'entraîne aucun frais supplémentaire. Si vous migrez des données d'une base de données Alibaba Cloud vers un autre cloud, le trafic Internet est également facturé. Pour plus d'informations, consultez la rubrique Facturation des clusters dédiés DTS.
Types de migration
DTS prend en charge trois types de migration que vous pouvez combiner selon vos besoins :
| Type de migration | Fonctionnalité | Cas d'utilisation |
|---|---|---|
| Migration de schéma | Copie les schémas d'objets (tables, vues, déclencheurs, procédures stockées, fonctions) de la source vers la destination. Modifie l'attribut SECURITY de DEFINER à INVOKER pour les vues, les procédures stockées et les fonctions. Ne migre pas les comptes utilisateurs ; accordez séparément les autorisations de lecture et d'écriture nécessaires à INVOKER. | Incluez toujours cette option, sauf si le schéma de destination existe déjà. |
| Migration complète des données | Copie toutes les données existantes de la source vers la destination. | Utilisez cette option pour l'amorçage initial des données. N'écrivez pas dans la source pendant une migration complète uniquement. |
| Migration incrémentielle des données | Une fois la migration complète terminée, applique continuellement les modifications de la source vers la destination à l'aide des journaux binaires. Maintient la synchronisation entre la source et la destination sans interruption de service. | Sélectionnez cette option pour minimiser les temps d'arrêt et maintenir les services actifs pendant la migration. |
Combinaison recommandée : sélectionnez les trois types (migration de schéma + migration complète des données + migration incrémentielle des données) pour migrer les données sans interrompre votre application. Utilisez la migration complète uniquement (migration de schéma + migration complète des données) seulement pour les migrations ponctuelles où un temps d'arrêt est acceptable.
Opérations SQL prises en charge pour la migration incrémentielle des données
| Type d'opération | Opérations 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 |
Autorisations requises
Accordez les autorisations suivantes aux comptes de base de données DTS avant de démarrer la tâche :
| Base de données | Migration de schéma | Migration complète des données | Migration incrémentielle des données |
|---|---|---|---|
| Source ApsaraDB RDS for MySQL | SELECT | SELECT | Autorisations de lecture et d'écriture |
| Destination ApsaraDB RDS for MySQL | Autorisations de lecture et d'écriture | Autorisations de lecture et d'écriture | Autorisations de lecture et d'écriture |
Pour migrer les comptes, le compte source nécessite également l'autorisation SELECT sur mysql.user, mysql.db, mysql.columns_priv et mysql.tables_priv. Le compte de destination nécessite les autorisations CREATE USER et GRANT OPTION. Les comptes système (root, mysql.infoschema, mysql.session, mysql.sys) et les comptes déjà présents dans la destination ne peuvent pas être migrés.
Pour obtenir des instructions sur la création de comptes et l'octroi d'autorisations, consultez les rubriques Créer un compte sur une instance ApsaraDB RDS for MySQL et Modifier les autorisations d'un compte standard sur une instance ApsaraDB RDS for MySQL.
Limites
Lors de la migration de schéma, DTS migre les clés étrangères de la source vers la destination. Pendant la migration complète et incrémentielle des données, DTS désactive temporairement les vérifications de contrainte de clé étrangère et les opérations en cascade au niveau de la session. Si vous effectuez des opérations en cascade ou de suppression sur la source pendant la migration, des incohérences de données peuvent survenir.
| Catégorie | Limite |
|---|---|
| Source database | Le serveur source doit disposer d'une bande passante sortante suffisante. Une bande passante insuffisante réduit la vitesse de migration. |
| Les tables doivent posséder des clés primaires ou des contraintes UNIQUE avec tous les champs uniques. Sans ces contraintes, la base de données de destination peut contenir des enregistrements en double. | |
| Si vous sélectionnez des tables comme objets de migration et devez renommer des tables ou des colonnes dans la destination, une seule tâche prend en charge jusqu'à 1 000 tables. Si vous dépassez cette limite, une erreur de requête se produit. Répartissez les tables sur plusieurs tâches ou migrez la base de données entière. | |
Pour la migration incrémentielle des données : définissez binlog_format sur row, définissez binlog_row_image sur full et activez la journalisation binaire. Si la base de données MySQL autogérée s'exécute dans un cluster à double primaire, définissez log_slave_updates sur ON afin que DTS puisse lire tous les journaux binaires. |
|
| Pour une migration incrémentielle uniquement : conservez les journaux binaires pendant plus de 24 heures. Pour une migration complète des données combinée à une migration incrémentielle : conservez les journaux binaires pendant au moins 7 jours. Une fois la migration complète terminée, vous pouvez réduire la rétention à plus de 24 heures. Une rétention insuffisante empêche DTS d'obtenir les journaux binaires, ce qui peut entraîner l'échec de la tâche ou une perte de données. | |
| N'effectuez pas d'opérations DDL pendant la migration de schéma ou la migration complète des données. N'écrivez pas dans la base de données source pendant une migration complète uniquement. Cela provoquerait des incohérences de données. | |
| Autres | Utilisez la même version de moteur pour les bases de données MySQL source et de destination. |
| Exécutez les migrations pendant les heures creuses. La migration complète des données utilise les ressources de lecture et d'écriture des deux instances et augmente la charge du serveur. | |
| La migration complète des données provoque une fragmentation des tables de destination en raison des opérations INSERT concurrentes. Par conséquent, l'espace table de la destination est plus grand que celui de la source après la migration. | |
DTS utilise ROUND(COLUMN,PRECISION) pour lire les colonnes FLOAT et DOUBLE. La précision par défaut est de 38 chiffres pour FLOAT et de 308 chiffres pour DOUBLE. Vérifiez que ces paramètres de précision répondent à vos exigences. |
|
DTS retente automatiquement les tâches ayant échoué pendant un maximum de 7 jours. Avant de basculer les charges de travail vers la base de données de destination, arrêtez ou libérez la tâche de migration, ou exécutez REVOKE pour supprimer les autorisations d'écriture de DTS sur la destination. Sinon, la tâche reprise écrasera les données de destination avec les données source. |
|
| Cas particuliers | Pour MySQL autogéré : un basculement primaire/secondaire pendant une tâche de migration active entraîne l'échec de la tâche. |
| Pour MySQL autogéré : si aucune opération DML n'est exécutée sur la source pendant une période prolongée, le rapport de latence de migration peut être imprécis. Exécutez une opération DML sur la source pour actualiser la latence. Si vous migrez une base de données entière, créez une table de heartbeat qui écrit des données chaque seconde. | |
DTS exécute périodiquement CREATE DATABASE IF NOT EXISTS \test\`` sur la base de données source pour faire avancer la position du journal binaire. |
|
| Pour les destinations ApsaraDB RDS for MySQL : DTS crée automatiquement la base de données de destination, sauf si le nom de la base de données source n'est pas valide. Si le nom n'est pas valide, créez la base de données manuellement avant de configurer la tâche. |
Configurer une tâche de migration
La configuration comporte quatre étapes : connecter les bases de données source et de destination, sélectionner les objets de migration, configurer les paramètres avancés et démarrer la tâche.
Étape 1 : Connecter les bases de données source et de destination
Accédez à la page Cluster dédié.
Dans la barre de navigation supérieure, sélectionnez la région où réside votre cluster dédié DTS.
Localisez le cluster, puis dans la colonne Actions, choisissez Configure Task > Configure Data Migration Task.
Sur la page de configuration, lisez l'avis Limits en haut de la page avant de continuer.
-
Configurez les paramètres de la Source Database :
Paramètre Description Task Name Généré automatiquement. Spécifiez un nom descriptif pour identifier la tâche. Le nom n'a pas besoin d'être unique. Select an existing database connection (facultatif) Sélectionnez une connexion existante pour remplir automatiquement les paramètres source. Ignorez cette étape si vous configurez manuellement. Database Type Sélectionnez MySQL. Access Method Sélectionnez Alibaba Cloud Instance. Instance Region Défini par le cluster dédié DTS. Ne peut pas être modifié. Replicate Data Across Alibaba Cloud Accounts Sélectionnez No pour une migration au sein du même compte. RDS Instance ID L'ID de l'instance source ApsaraDB RDS for MySQL. La source et la destination peuvent être la même instance. Database Account Le compte disposant des autorisations listées dans la section Autorisations requises. Database Password Mot de passe du compte de base de données. Connection Method Sélectionnez Non-encrypted ou SSL-encrypted. Pour le chiffrement SSL, configurez SSL sur l'instance avant de démarrer cette tâche. -
Configurez les paramètres de la Destination Database :
Paramètre Description Select an existing DMS database instance (facultatif) Sélectionnez une connexion existante pour remplir automatiquement les paramètres de destination. Ignorez cette étape si vous configurez manuellement. Database Type Sélectionnez MySQL. Access Method Sélectionnez Alibaba Cloud Instance. Instance Region Défini par le cluster dédié DTS. Ne peut pas être modifié. RDS Instance ID L'ID de l'instance de destination ApsaraDB RDS for MySQL. Database Account Le compte disposant des autorisations listées dans la section Autorisations requises. Database Password Mot de passe du compte de base de données. Connection Method Sélectionnez Non-encrypted ou SSL-encrypted. Pour le chiffrement SSL, configurez SSL sur l'instance avant de démarrer cette tâche. -
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 ou aux règles de groupe de sécurité d'une instance ECS hébergeant une base de données autogérée. Pour les bases de données autogérées dans des centres de données sur site ou des clouds tiers, ajoutez manuellement les blocs CIDR du serveur DTS à la liste d'autorisation IP de la base de données. Consultez la rubrique Ajouter les blocs CIDR des serveurs DTS aux paramètres de sécurité des bases de données sur site.
AvertissementL'ajout de blocs CIDR de serveur DTS aux listes d'autorisation IP ou aux règles de groupe de sécurité introduit une exposition à la sécurité. Avant de continuer, renforcez la sécurité des comptes et des mots de passe, limitez les ports exposés, authentifiez les appels API, auditez régulièrement la liste d'autorisation IP et les règles de groupe de sécurité pour supprimer les blocs CIDR non autorisés, et envisagez d'utiliser Express Connect, VPN Gateway ou Smart Access Gateway pour connecter la base de données à DTS.
Étape 2 : Sélectionner les objets de migration
Configurez le type de migration, la gestion des conflits et les objets à migrer :
| Paramètre | Description |
|---|---|
| Migration Type | Sélectionnez la combinaison adaptée à votre objectif. Pour une migration complète uniquement : sélectionnez Schema Migration et Full Data Migration. Pour maintenir les services actifs pendant la migration : sélectionnez Schema Migration, Full Data Migration et Incremental Data Migration. |
| Processing Mode of Conflicting Tables | Precheck and Report Errors : vérifie si la destination contient des tables portant les mêmes noms que la source. La pré-vérification réussit uniquement s'il n'y a aucun conflit de nom. Utilisez le mappage de noms d'objets pour renommer les tables conflictuelles dans la destination. Ignore Errors and Proceed : ignore la vérification des conflits de noms. Si les schémas correspondent, DTS ignore les enregistrements avec des clés primaires en double. Si les schémas diffèrent, seules certaines colonnes sont migrées ou la tâche échoue. À utiliser avec prudence : des incohérences de données peuvent survenir. |
| Method to Migrate Triggers in Source Database | S'applique uniquement lorsque Schema Migration est sélectionné. Choisissez une méthode selon vos besoins. Consultez la rubrique Synchroniser ou migrer les déclencheurs depuis la base de données source. |
| Enable Migration Assessment | S'applique uniquement lorsque Schema Migration est sélectionné. Sélectionnez Yes pour vérifier si les schémas source et de destination (longueurs d'index, procédures stockées, tables dépendantes) répondent aux exigences de migration. Les résultats de l'évaluation sont visibles lors de la pré-vérification et n'affectent pas le succès ou l'échec de celle-ci. |
| Capitalization of Object Names in Destination Instance | Contrôle la casse des noms de base de données, de tables et de colonnes dans la destination. La valeur par défaut est DTS default policy. Consultez la rubrique Spécifier la casse des noms d'objets dans l'instance de destination. |
| Source Objects | Sélectionnez les objets dans la liste Source Objects et cliquez sur l'icône  pour les ajouter à Selected Objects. Granularité sélectionnable : colonnes, tables ou bases de données. La sélection de tables ou de colonnes exclut les vues, les déclencheurs et les procédures stockées de la migration. |
| Selected Objects | Cliquez avec le bouton droit sur un objet pour le renommer ou définir des conditions WHERE pour filtrer les lignes. Cliquez sur Batch Edit (en haut à droite) pour renommer plusieurs objets à la fois. Consultez les rubriques Mapper les noms d'objets et Utiliser des conditions SQL pour filtrer les données. Le renommage d'un objet peut empêcher la migration des objets dépendants. |
Étape 3 : Configurer les paramètres avancés
Cliquez sur Next: Advanced Settings pour configurer les paramètres suivants :
Vérification des données
Pour vérifier la cohérence des données après la migration, consultez la rubrique Activer la vérification des données.
Paramètres avancés
| Paramètre | Description |
|---|---|
| Select the dedicated cluster used to schedule the task | Votre cluster dédié DTS est sélectionné par défaut. |
| Set Alerts | Sélectionnez Yes pour recevoir des notifications en cas d'échec de la tâche ou si la latence de migration dépasse un seuil. Spécifiez le seuil d'alerte et les contacts. Consultez la rubrique Configurer la surveillance et les alertes lors de la création d'une tâche DTS. |
| Copy the temporary table of the Online DDL tool that is generated in the source table to the destination database | S'applique lors de l'utilisation de Data Management (DMS) ou de gh-ost pour les opérations DDL en ligne sur la source. Yes : migre les données de la table temporaire générées par DDL en ligne (peut prolonger le temps de migration pour les grands jeux de données). No, Adapt to DMS Online DDL : ignore les données de la table temporaire ; migre uniquement le DDL original. Les tables de la destination peuvent être verrouillées. No, Adapt to gh-ost : ignore les données de la table temporaire ; migre uniquement le DDL original. Utilisez des expressions régulières par défaut ou personnalisées pour filtrer les tables fantômes gh-ost. Les tables de la destination peuvent être verrouillées. Important
pt-online-schema-change n'est pas pris en charge. Son utilisation entraîne l'échec de la tâche. |
| Whether to Migrate Accounts | Sélectionnez Yes pour migrer les comptes de la base de données source. Consultez les exigences en matière d'autorisations dans la section Autorisations requises. |
| Method to Migrate Triggers in Source Database | Choisissez une méthode de migration des déclencheurs. Consultez la rubrique Synchroniser ou migrer les déclencheurs depuis la base de données source. |
| Retry Time for Failed Connections | Durée pendant laquelle DTS tente de reconnecter après un échec de connexion. Valeurs valides : 10 à 1 440 minutes. Par défaut : 720. Définissez une valeur d'au moins 30 minutes. Si la reconnexion réussit dans ce délai, DTS reprend la tâche. Si l'instance source ou de destination partagée est utilisée par plusieurs tâches, la valeur définie le plus récemment s'applique à toutes les tâches. Remarque
Lorsque DTS tente de reconnecter, vous êtes facturé pour l'instance DTS. Spécifiez cette valeur en fonction de vos besoins métier. Vous pouvez également libérer l'instance DTS dès que possible après la libération des instances source et de destination. |
| The wait time before a retry when other issues occur in the source and destination databases | Durée pendant laquelle DTS retente après des échecs d'opérations DDL ou DML. Valeurs valides : 1 à 1 440 minutes. Par défaut : 10. Définissez une valeur d'au moins 10 minutes. Cette valeur doit être inférieure à Retry Time for Failed Connections. |
Étape 4 : Exécuter la pré-vérification et démarrer la tâche
Cliquez sur Next: Save Task Settings and Precheck. Pour prévisualiser les paramètres de l'API utilisés pour configurer cette tâche, survolez le bouton et cliquez sur Preview OpenAPI parameters.
-
Attendez la fin de la pré-vérification. Si la pré-vérification échoue :
Pour les éléments ayant échoué : cliquez sur View Details, corrigez les problèmes, puis cliquez sur Precheck Again.
Pour les éléments d'alerte qui ne peuvent pas être ignorés : cliquez sur View Details, corrigez les problèmes, puis cliquez sur Precheck Again.
Pour les éléments d'alerte qui peuvent être ignorés : cliquez sur Confirm Alert Details > Ignore > OK > Precheck Again. Ignorer une alerte peut entraîner des incohérences de données.
Lorsque le taux de réussite atteint 100 %, cliquez sur Next: Select DTS Instance Type.
Dans la section New Instance Class, définissez la Instance Class pour la tâche. Le minimum est de 1 unité DTS (DU) et le maximum correspond au nombre d'unités DU disponibles restantes dans le cluster.
Lisez et cochez la case des Data Transmission Service (Pay-as-you-go) Service Terms.
Cliquez sur Start Task > OK.
Pour surveiller la progression, accédez à la page des détails du cluster et cliquez sur Cluster Task List dans le volet de navigation de gauche.
Étapes suivantes
Une fois la tâche démarrée et la migration incrémentielle en cours d'exécution :
Surveillez la latence de migration sur la page Cluster Task List. Si la latence est élevée en raison d'une inactivité sur la source, exécutez une opération DML pour l'actualiser.
Avant de basculer le trafic applicatif vers la base de données de destination, vérifiez la cohérence des données à l'aide de la vérification des données.
Arrêtez ou libérez la tâche de migration avant de basculer les charges de travail, ou exécutez
REVOKEpour supprimer les autorisations d'écriture de DTS sur la destination. Cela empêche une tâche reprise d'écraser les données de destination.