Data Transmission Service:Migrate data from an ApsaraDB RDS for MySQL instance to an ApsaraDB for ClickHouse cluster

Cluster de destination

• Le cluster ApsaraDB for ClickHouse de destination doit exécuter la version 20.8 ou ultérieure. Consultez Créer un cluster.

• L'espace de stockage du cluster de destination doit être supérieur à l'espace utilisé par l'instance RDS MySQL source.

Autorisations du compte de la base de données source

Le compte de la base de données source doit disposer d'autorisations de lecture sur les objets à migrer. Si le compte n'a pas été créé via la console RDS, accordez-lui manuellement les autorisations suivantes :

GRANT REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW, SELECT ON *.* TO '<account>'@'%';

Consultez Créer un compte et Modifier les autorisations d'un compte.

Autorisations du compte du cluster de destination

Exigences relatives aux journaux binaires (migration incrémentielle uniquement)

Si vous prévoyez d'inclure une migration de données incrémentielle, configurez les éléments suivants sur l'instance MySQL source.

Activer la conservation des journaux binaires

La période de conservation minimale dépend du type de source :

• ApsaraDB RDS for MySQL : Conservez les journaux binaires pendant au moins 3 jours (7 jours recommandés).

• MySQL géré par l'utilisateur : Conservez les journaux binaires pendant au moins 7 jours.

Une conservation inférieure au minimum requis peut entraîner l'échec de la tâche de migration ou une perte de données. Pour définir la période de conservation d'une instance RDS MySQL, consultez Configurer les paramètres selon lesquels le système supprime automatiquement les fichiers de journal binaire d'une instance RDS.

Configurer le format des journaux binaires

Définissez les paramètres suivants sur l'instance MySQL source :

Ces paramètres permettent à DTS de lire les données de modification au niveau des lignes. S'ils ne sont pas correctement définis, la vérification préalable échoue et la tâche de migration ne démarre pas.

Si la source est une base de données MySQL gérée par l'utilisateur déployée dans un cluster à double primaire, définissez également log_slave_updates = ON afin que DTS puisse obtenir tous les journaux binaires.

Restrictions de la base de données source

• Limite de migration au niveau des tables : Une seule tâche de migration prend en charge un maximum de 1 000 tables lorsque le mappage des noms d'objets est utilisé. Si vous dépassez cette limite, répartissez les tables sur plusieurs tâches ou migrez la base de données entière.

• Colonnes invisibles (MySQL 8.0.23 et versions ultérieures) : DTS ne peut pas lire les colonnes invisibles, ce qui entraîne une perte de données. Pour rendre une colonne visible, exécutez ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;. Les tables sans clés primaires explicites génèrent automatiquement des clés primaires invisibles ; rendez-les également visibles. Consultez Invisible Columns et Generated Invisible Primary Keys.

• RDS MySQL V5.6 en lecture seule : Ce type d'instance n'enregistre pas les journaux de transaction et ne peut pas servir de source pour la migration incrémentielle.

• Instances activées avec EncDB : La migration complète des données n'est pas prise en charge. Les instances activées avec Transparent Data Encryption (TDE) prennent en charge la migration du schéma, la migration complète des données et la migration incrémentielle des données.

• Restrictions DDL pendant la migration : N'exécutez pas d'instructions DDL pendant l'exécution de la migration du schéma ou de la migration complète des données. Pour une migration complète uniquement, n'écrivez pas dans la base de données source pendant la migration.

• Restaurations de sauvegarde physique et opérations en cascade : Les données de changement générées par les restaurations de sauvegarde physique ou les opérations en cascade sur la source ne sont ni enregistrées ni migrées vers la destination pendant l'exécution de l'instance de migration. Le cas échéant, vous pouvez relancer une migration complète des données, à condition que votre activité professionnelle ne soit pas affectée.

Autres restrictions

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

• L'opération RENAME TABLE ne peut pas être migrée.

• Si la base de données source comporte des opérations de modification DDL en ligne en mode table temporaire, telles que des scénarios de fusion multi-tables, une perte de données dans la base de données de destination ou un échec de l'instance de migration peut survenir.

• Si la source contient des modifications DDL en ligne effectuées avec pt-online-schema-change, une perte de données ou un échec de la migration peut survenir. Si vous migrez une ou plusieurs tables au lieu d'une base de données entière, n'utilisez pas pt-online-schema-change pour effectuer des opérations DDL en ligne sur les objets de migration dans la base de données source, sinon la migration échouera. Les modifications DDL en ligne effectuées avec DMS ou gh-ost sont prises en charge : DTS migre l'instruction DDL d'origine sans copier les données de la table temporaire, mais cela peut provoquer le verrouillage des tables dans la destination. Vous pouvez utiliser Data Management (DMS) pour effectuer des opérations DDL en ligne.

• Si les instructions DDL dans la source ne suivent pas la syntaxe MySQL standard, la tâche de migration peut échouer ou des données peuvent être perdues.

• Le nombre de bases de données à migrer ne doit pas dépasser 256 (limite de ClickHouse).

• Les noms des bases de données, des tables et des colonnes doivent respecter les conventions de nommage d'ApsaraDB for ClickHouse.

• Pendant la migration du schéma, DTS ajoute les champs _sign, _is_deleted et _version aux tables de destination. Si vous ignorez la migration du schéma, créez manuellement les tables de destination et incluez ces champs. Consultez Annexe : informations sur les tables et les champs.

• N'écrivez aucune donnée provenant de sources autres que DTS dans la base de données de destination pendant l'exécution de la migration.

• Si une tâche DTS ne parvient pas à s'exécuter, le support 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 les paramètres de la tâche DTS peuvent être modifiés. Remarque : seuls les paramètres de la tâche DTS peuvent être modifiés ; les paramètres des bases de données ne le sont pas. Les paramètres susceptibles d'être modifiés incluent, sans s'y limiter, ceux de la section Modifier les paramètres de l'instance.

Contraintes spécifiques à ClickHouse

• Plage de données de type heure : Les types d'heure de ClickHouse ont des limites de plage. Les données source en dehors de ces plages sont écrites incorrectement. Consultez Annexe : informations sur l'heure.

• Clé de partition : Ne peut pas être un champ nullable. Types pris en charge : BIGINT, INT, TIMESTAMP, DATETIME, DATE.

• Nombre maximal de bases de données : 256.

Cas particuliers

Sources MySQL gérées par l'utilisateur

• Si vous effectuez un basculement primaire/secondaire sur la base de données source pendant l'exécution de la tâche de migration des données, la tâche échoue.

• DTS calcule la latence de migration en fonction de l'horodatage des dernières données migrées dans la destination et de l'horodatage actuel dans la source. Si aucune opération DML n'est effectuée sur la source pendant une longue période, la latence de migration peut être inexacte. Pour mettre à jour la latence, effectuez une opération DML sur la source. Si vous sélectionnez une base de données entière comme objet de migration, vous pouvez créer une table de heartbeat mise à jour chaque seconde.

• DTS exécute CREATE DATABASE IF NOT EXISTS \ test\`` dans la base de données source de manière planifiée pour faire avancer la position du fichier de journal binaire.

Sources ApsaraDB RDS for MySQL

• Dans la migration incrémentielle des données, une instance ApsaraDB RDS for MySQL V5.6 en lecture seule ne peut pas servir de base de données source.

• DTS exécute CREATE DATABASE IF NOT EXISTS \ test\`` dans la base de données source de manière planifiée pour faire avancer la position du fichier de journal binaire.

Étape 1 : Ouvrir la page Migration des données

Utilisez l'une des méthodes suivantes pour accéder à la page Migration des données.

Étape 2 : Configurer la tâche

Cliquez sur Create Task pour ouvrir la page de configuration de la tâche. Configurez les paramètres décrits dans le tableau suivant.

Étape 3 : Tester la connectivité

Cliquez sur Test Connectivity and Proceed en bas de la page.

Ajoutez les blocs CIDR du serveur DTS aux paramètres de sécurité des bases de données source et de destination. Consultez Ajouter les blocs CIDR des serveurs DTS . Si la source ou la destination est une base de données gérée par l'utilisateur n'utilisant pas la méthode d'accès Alibaba Cloud Instance , cliquez sur Test Connectivity dans la boîte de dialogue CIDR Blocks of DTS Servers .

Étape 4 : Sélectionner les objets à migrer

Sur la page Configure Objects, configurez les paramètres suivants.

Étape 5 : Configurer les paramètres avancés

Cliquez sur Next: Advanced Settings et configurez les paramètres suivants.

Étape 6 : Configurer les champs de table ClickHouse

Cliquez sur Next: Configure Database and Table Fields pour définir le Type, la Primary Key Column, la Sort Key, la Distribution Key et la Partition Key pour chaque table de destination dans ClickHouse.

• DTS fournit une configuration par défaut. Pour examiner ou modifier toutes les tables, définissez Definition Status sur All.

• La Primary Key Column et la Sort Key prennent en charge les clés composites : sélectionnez plusieurs champs dans la liste déroulante.

• La Partition Key doit être constituée d'une ou plusieurs colonnes de la Primary Key Column. Seuls les types BIGINT, INT, TIMESTAMP, DATETIME et DATE sont pris en charge. Les champs nullable ne peuvent pas être utilisés comme clé de partition. Il est permis de laisser la clé de partition vide.

• La Distribution Key n'accepte qu'un seul champ.

Pour plus de détails sur les clés primaires, les clés de tri et les clés de partition dans ClickHouse, consultez CREATE TABLE.

Étape 7 : Exécuter une vérification préalable

Cliquez sur Next: Save Task Settings and Precheck.

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

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

1. Cliquez sur View Details à côté de l'élément ayant échoué.

2. Corrigez le problème en fonction des résultats de la vérification.

3. Cliquez sur Precheck Again.

Si un élément d'alerte peut être ignoré : cliquez sur Confirm Alert Details > Ignore > OK > Precheck Again. Ignorer les alertes peut entraîner une incohérence des données.

Étape 8 : Acheter l'instance et démarrer la migration

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

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

   Section	Paramètre	Description
   New Instance Class	Resource Group	Le groupe de ressources pour l'instance de migration. Par défaut : default resource group. Consultez Qu'est-ce que Resource Management ?
   	Instance Class	La classe d'instance détermine la vitesse de migration. Consultez Classes d'instances des instances de migration des données.

3. Lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms.

4. Cliquez sur Buy and Start > OK.

Interroger correctement les données migrées

DTS utilise le moteur ReplicatedReplacingMergeTree et ajoute les champs _sign, _is_deleted et _version aux tables de destination. Sans le mot-clé FINAL, les requêtes peuvent renvoyer des lignes dupliquées ou supprimées. Utilisez toujours FINAL et filtrez sur _sign :

SELECT * FROM <table_name> FINAL WHERE _sign > 0;

La condition WHERE _sign > 0 filtre les lignes marquées comme supprimées.

Exigences relatives aux tables pour la création manuelle

Si vous ignorez la migration du schéma, créez les tables de destination avant de démarrer la tâche. Les tables doivent répondre à ces exigences.

• Community Edition : Créez une table locale et une table distribuée. Le nom de la table distribuée doit correspondre au nom de la table source. Le nom de la table locale doit être <distributed_table_name>_local.

• Enterprise Edition : Créez une table portant le même nom que la table source.

Champs gérés par DTS

DTS ajoute automatiquement les champs suivants aux tables de destination lors de la migration du schéma.

Logique de calcul de la clé de partition