ApsaraDB for ClickHouse:Migrate from self-managed to Cloud ClickHouse

Pendant la migration

• Pendant la migration, le processus de fusion est suspendu dans le cluster de destination, mais il se poursuit dans le cluster autogéré.

  Remarque

  Si une tâche de migration s'exécute pendant une longue période, des métadonnées excessives peuvent s'accumuler dans le cluster de destination. Nous vous recommandons de ne pas dépasser une durée de 5 jours pour les tâches de migration. Les tâches dépassant 5 jours sont automatiquement annulées.

• Le cluster de destination doit être le cluster default. Si votre cluster autogéré utilise un nom différent, le service convertit automatiquement la définition cluster dans les tables distribuées en default.

Portée de la migration

• Objets pris en charge

  • Bases de données, dictionnaires de données et vues matérialisées.

    • Ce service prend en charge la migration des dictionnaires de données créés avec SQL, mais pas ceux créés avec XML.

      Pour vérifier cela, exécutez l'instruction suivante : SELECT * FROM system.dictionaries WHERE (database = '') OR isNull(database);. Si l'instruction renvoie des lignes, cela indique que vous disposez de dictionnaires de données créés à l'aide de XML.

    • Lorsqu'un dictionnaire de données accède à un service externe, assurez-vous que le service externe est disponible et que le cluster est ajouté à sa liste d'autorisation. Si la source de données d'un dictionnaire de données est une table interne dans le cluster ClickHouse actuel et que le paramètre HOST dans la définition est une adresse IP, l'accès au dictionnaire peut échouer après une migration en raison d'un changement d'adresse IP. Vous devez reconfirmer l'adresse HOST du cluster ClickHouse actuel et créer manuellement le dictionnaire de données.

  • Schémas de table : tous les schémas de table, à l'exception des tables utilisant les moteurs Kafka et RabbitMQ.

  • Données : migration incrémentielle des données des tables de la famille MergeTree.

• Objets et données non pris en charge

  • Tables utilisant les moteurs Kafka et RabbitMQ, ainsi que leurs données.

  • Données provenant de tables autres que MergeTree, telles que les tables externes et les tables Log.

  Important

  Vous devez migrer manuellement les éléments non pris en charge listés ci-dessus.

• Limites de volume de données

  • Données froides : la migration des données froides est lente. Pour éviter les échecs causés par des temps de migration prolongés, nous vous recommandons de supprimer les données froides de votre cluster autogéré afin que le volume total ne dépasse pas 1 To.

  • Données chaudes : si le volume de données chaudes dépasse 10 To, la tâche de migration risque d'échouer.

  Si votre volume de données dépasse ces limites, envisagez d'utiliser plutôt la solution de migration manuelle.

Étape 1 : Vérifier le cluster et activer les tables système

Avant de migrer les données, modifiez le fichier config.xml de votre cluster autogéré pour activer la migration incrémentielle. Les modifications requises dépendent de l'activation ou non des tables system.part_log et system.query_log.

<part_log>
    <database>system</database>
    <table>part_log</table>
    <partition_by>event_date</partition_by>
    <order_by>event_time</order_by>
    <ttl>event_date + INTERVAL 15 DAY DELETE</ttl>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</part_log>

<query_log>
    <database>system</database>
    <table>query_log</table>
    <partition_by>event_date</partition_by>
    <order_by>event_time</order_by>
    <ttl>event_date + INTERVAL 15 DAY DELETE</ttl>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_log>

Étape 2 : Configurer la compatibilité du cluster de destination

Étape 3 : (Facultatif) Activer le moteur MaterializedMySQL

Si votre cluster autogéré contient des tables qui utilisent le moteur MaterializedMySQL, exécutez l'instruction suivante pour activer ce moteur.

SET GLOBAL allow_experimental_database_materialized_mysql = 1;

Étape 4 : Enregistrer et nettoyer les tables utilisant les moteurs Kafka/RabbitMQ

Avant de commencer la migration, enregistrez les définitions de toutes les tables utilisant les moteurs Kafka/RabbitMQ et leurs vues matérialisées en aval dans le cluster autogéré, traitez les tables implicites, puis supprimez ces tables pour éviter les erreurs de migration.

1. Connectez-vous au cluster autogéré et interrogez toutes les tables utilisant les moteurs Kafka et RabbitMQ ainsi que leurs dépendances en aval.

   /*
   create_table_query: table definition
   dependencies_database: database of the table that depends on this table
   dependencies_table: table that depends on this table
   From dependencies_database and dependencies_table, you can identify the materialized views that depend on Kafka/RabbitMQ tables
   */
   SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');

2. Consultez la définition de la vue matérialisée pour vérifier si sa table cible est une table implicite.

   /*
   View the materialized view definition.
   If the target table of the materialized view is an implicit table, pay special attention:
   Dropping the materialized view will also drop the implicit table, causing data loss.
   Example: If CREATE MATERIALIZED VIEW [db.]table_name [TO[db.]name] does not specify TO,
   the system automatically creates an implicit table, possibly in the format '.inner_id.<TABLE_UUID>' or '.inner.<TABLE>'
   */
   SELECT * FROM system.tables WHERE database='<DATABASE>' AND name = '<MATERIALIZED_VIEW_NAME>';

3. Si la table cible d'une vue matérialisée est une table implicite, renommez la table cible avec un nouveau nom pour éviter la perte de données lors de la suppression ultérieure de la vue matérialisée.

   -- Rename the implicit target table to a new name to protect data
   RENAME TABLE <DATABASE>.`.inner_id.<TABLE_UUID>` TO <DATABASE>.<new_target_table_name>;

4. Supprimez les tables utilisant les moteurs Kafka/RabbitMQ et leurs vues matérialisées en aval.

   -- Drop materialized views first
   DROP TABLE <DATABASE>.<MATERIALIZED_VIEW_NAME>;
   -- Then drop Kafka/RabbitMQ engine tables
   DROP TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME>;

Étape 5 : Créer une tâche de migration de données

1. Connectez-vous à la console ApsaraDB for ClickHouse.

2. Sur la page Clusters, sélectionnez Clusters of Community-compatible Edition et cliquez sur l'ID du cluster de destination.

3. Dans le volet de navigation de gauche, choisissez Data Migration and Synchronization > Migration from ClickHouse.

4. Sur la page de la tâche de migration, cliquez sur Create Migration Task.

   1. Configurez les instances source et de destination.

      Configurez les paramètres suivants et cliquez sur Test Connectivity and Proceed.

      Remarque

      Si le test de connexion réussit, passez à l'étape suivante. Si le test de connexion échoue, reconfigurez les instances source et de destination en suivant les instructions affichées.

      Paramètres du cluster source

      Paramètre	Description	Exemple
      Source Access Method	Sélectionnez Express Connect, VPN Gateway, Smart Access Gateway, or Self-managed ClickHouse Clusters on an ECS Instance.	Express Connect, VPN Gateway, Smart Access Gateway, or Self-managed ClickHouse Clusters on an ECS Instance
      Cluster Name	Nom du cluster source. Le nom ne peut contenir que des chiffres et des lettres minuscules.	source
      Source Cluster Name	Exécutez SELECT * FROM system.clusters; pour obtenir le Source Cluster Name.	default
      VPC IP Address	Adresse IP et PORT (adresse TCP) de chaque shard du cluster, séparées par des virgules. Important Vous ne pouvez pas utiliser le nom de domaine VPC ni l'adresse SLB d'un cluster ApsaraDB for ClickHouse. Format : IP:PORT,IP:PORT,...... La méthode pour obtenir l'adresse IP et le PORT du cluster varie selon le scénario de migration des données. Migration inter-comptes ou inter-régions Vous pouvez utiliser l'instruction SQL suivante pour obtenir l'adresse IP et le PORT du cluster autogéré : SELECT shard_num, replica_num, host_address as ip, port FROM system.clusters WHERE cluster = 'default' and replica_num = 1; Ici, replica_num=1 sélectionne le premier ensemble de réplicas. Vous pouvez également choisir d'autres ensembles de réplicas ou sélectionner un réplica par shard. Migration ClickHouse hors Alibaba Cloud Si l'adresse IP ne peut pas être facilement mappée à Alibaba Cloud, vous pouvez utiliser l'instruction SQL suivante pour obtenir l'adresse IP et le PORT du cluster autogéré : SELECT shard_num, replica_num, host_address as ip, port FROM system.clusters WHERE cluster = '<cluster_name>' and replica_num = 1; Les paramètres sont décrits comme suit : cluster_name : nom du cluster de destination. replica_num=1 sélectionne le premier ensemble de réplicas. Vous pouvez également choisir d'autres ensembles de réplicas ou sélectionner un réplica par shard. Si l'adresse IP et le port sont mappés à Alibaba Cloud via une translation réseau, vous devez configurer l'adresse IP et le port mappés correspondants.	192.168.0.5:9000,192.168.0.6:9000
      Database Account	Compte de base de données du cluster source.	test
      Database Password	Mot de passe du compte de base de données du cluster source.	test

      Paramètres du cluster de destination

      Paramètre	Description	Exemple
      Database Account	Compte de base de données du cluster de destination.	test
      Database Password	Mot de passe du compte de base de données du cluster de destination.	test

   2. Confirmez le contenu de la migration.

      Vérifiez attentivement les informations relatives aux données à migrer sur la page, puis cliquez sur Next: Pre-detect and Start Synchronization.

   3. Le système exécute une pré-vérification du lien de migration en arrière-plan et démarre la tâche.

      Le système exécute une Instance Status Detection, une Storage Space Detection et une Local Table and Distributed Table Detection sur les clusters source et de destination.

      • Si la pré-vérification réussit :

        Une fois la pré-vérification réussie, la page indique que trois vérifications ont été validées : Instance status check, Storage space check et Local table and distributed table check. Le haut de la page indique que le temps de migration estimé est de 2 minutes et décrit les impacts pendant la migration :

        • L'instance source est accessible en lecture et en écriture, mais les opérations DDL ne peuvent pas être effectuées.

        • L'instance de destination est accessible en lecture, mais les tables migrées ne peuvent pas être écrites.

        • Lorsque le temps restant est inférieur à 10 minutes, vous devez arrêter les écritures pour déclencher la fin de la migration.

        • Les tables autres que MergeTree conservent uniquement la structure de la table sans migration des données après la mise à l'échelle.

        1. Examinez attentivement l'impact du processus de migration des données sur les instances.

        2. Cliquez sur Completed.

           Important

           • Après avoir cliqué sur Terminé, le système crée et démarre la tâche, et son statut passe à En cours d'exécution. Vous pouvez afficher la tâche dans la liste des tâches.

           • Après avoir créé la tâche, vous devez la surveiller. Dans la phase finale de la migration, vous devez arrêter les opérations d'écriture sur le cluster autogéré et migrer les schémas de base de données et de tables restants. Pour plus d'informations, consultez Surveiller la tâche de migration et arrêter les écritures sur le cluster autogéré.

      • Si la pré-vérification échoue : suivez les instructions du message d'erreur et relancez la tâche de migration des données. Le tableau suivant décrit les éléments de pré-vérification et leurs exigences. Pour plus d'informations sur les messages d'erreur de pré-vérification et leurs solutions, consultez Erreurs de pré-vérification de migration et solutions.

        Élément de vérification	Exigence
        Instance Status Detection	La tâche de migration des données ne peut pas démarrer si des tâches de gestion (telles que la mise à l'échelle horizontale, la mise à niveau ou la rétrogradation) sont en cours d'exécution sur le cluster source ou de destination.
        Storage Space Detection	L'espace de stockage disponible du cluster de destination doit être au moins 1,2 fois supérieur à l'espace de stockage utilisé du cluster autogéré.
        Local Table and Distributed Table Detection	Si une table locale dans le cluster autogéré n'a pas de table distribuée correspondante ou en a plusieurs, la vérification échoue. Pour résoudre ce problème, supprimez les tables distribuées redondantes ou créez une table distribuée unique pour la table locale.

Étape 8 : Reconstruire les tables utilisant les moteurs Kafka/RabbitMQ sur le cluster auto-géré

Une fois que la tâche de migration entre dans la phase data migration (c'est-à-dire que la migration du schéma des tables est terminée), utilisez les instructions DDL précédemment enregistrées pour reconstruire les tables utilisant les moteurs Kafka/RabbitMQ ainsi que leurs vues matérialisées en aval sur le cluster auto-géré. Après reconstruction, les données incrémentielles recommencent à circuler et sont automatiquement synchronisées vers le cluster de destination.

-- Rebuild Kafka/RabbitMQ engine tables on the self-managed cluster
CREATE TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME> (...)
ENGINE = Kafka/RabbitMQ
SETTINGS ...;

-- Rebuild materialized view (pointing to the renamed target table)
CREATE MATERIALIZED VIEW <DATABASE>.<MATERIALIZED_VIEW_NAME> TO <DATABASE>.<new_target_table_name>
AS SELECT ... FROM <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME>;

Étape 9 : Arrêter les écritures et effectuer le basculement

Lorsque le temps restant estimé pour la migration est inférieur à 10 minutes ou que la progression de la migration atteint 99 %, effectuez les étapes de basculement suivantes :

1. Arrêtez les écritures métier. Sur le cluster auto-géré, supprimez les tables utilisant les moteurs Kafka/RabbitMQ précédemment reconstruites ainsi que leurs vues matérialisées en aval.

   -- Drop materialized views first
   DROP TABLE <DATABASE>.<MATERIALIZED_VIEW_NAME>;
   -- Then drop Kafka/RabbitMQ engine tables
   DROP TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME>;

2. Attendez que la progression de la migration atteigne 100 % et que la migration soit entièrement terminée.

3. Connectez-vous au cluster de destination et utilisez les instructions DDL précédemment enregistrées pour reconstruire les tables utilisant les moteurs Kafka/RabbitMQ ainsi que leurs vues matérialisées en aval.

   Important

   Si vous avez effectué une opération RENAME sur les tables cibles implicites plus tôt, utilisez la clause TO pointant vers la table cible renommée lors de la reconstruction de la vue matérialisée.

   -- Rebuild Kafka/RabbitMQ engine tables on the destination cluster
   CREATE TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME> (...)
   ENGINE = Kafka/RabbitMQ
   SETTINGS ...;

   -- Rebuild materialized view (pointing to the renamed target table)
   CREATE MATERIALIZED VIEW <DATABASE>.<MATERIALIZED_VIEW_NAME> TO <DATABASE>.<new_target_table_name>
   AS SELECT ... FROM <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME>;

4. Vérifiez que le pipeline de données sur le cluster de destination fonctionne correctement et que les données circulent normalement.

Étape 10 : Terminer la migration

Après avoir arrêté les écritures sur le cluster auto-géré, vous pouvez cliquer sur Complete the task. Cette étape migre les données restantes, effectue une vérification du volume de données et migre les schémas de bases de données et de tables restants. Vous pouvez consulter le contenu migré dans les détails de la tâche.

1. Connectez-vous à la console ApsaraDB for ClickHouse.

2. Sur la page Clusters, sélectionnez Clusters of Community-compatible Edition, puis cliquez sur l'ID du cluster de destination.

3. Dans le volet de navigation de gauche, cliquez sur Data Migration and Synchronization > Migration from ClickHouse.

4. Pour la tâche de migration cible, cliquez sur Complete Migration dans la colonne Actions.

5. Dans la boîte de dialogue Complete Migration, cliquez sur OK.

Étape 11 : Migrer les données des tables n'appartenant pas à la famille MergeTree

La tâche de migration ne migre que le schéma des tables n'appartenant pas à la famille MergeTree (telles que les tables externes et les tables Log), en les créant dans le cluster de destination sans aucune donnée métier. Vous devez migrer les données métier manuellement. Procédez comme suit :

1. Connectez-vous au cluster auto-géré et exécutez l'instruction suivante pour identifier les tables n'appartenant pas à la famille MergeTree qui nécessitent une migration des données.

   SELECT
       `database` AS database_name,
       `name` AS table_name,
       `engine`
   FROM `system`.`tables`
   WHERE (`engine` NOT LIKE '%MergeTree%') AND (`engine` != 'Distributed') AND (`engine` != 'MaterializedView') AND (`engine` NOT IN ('Kafka', 'RabbitMQ')) AND (`database` NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema')) AND (`database` NOT IN (
       SELECT `name`
       FROM `system`.`databases`
       WHERE `engine` IN ('MySQL', 'MaterializedMySQL', 'MaterializeMySQL', 'Lazy', 'PostgreSQL', 'MaterializedPostgreSQL', 'SQLite')
   ))

2. Connectez-vous au cluster de destination et utilisez la fonction remote pour migrer les données de la table. Pour des instructions détaillées, consultez la section Migrer des données à l'aide de la fonction remote.

Autres opérations

Lorsqu'une tâche de migration est terminée, son Migration Status passe à Completed. La liste des tâches ne se met pas à jour immédiatement ; actualisez régulièrement la page pour afficher le dernier état.

Méthode 1 : Utiliser les commandes BACKUP et RESTORE

Pour plus d'informations, consultez la rubrique Utiliser les commandes BACKUP et RESTORE pour sauvegarder et restaurer des données.

Méthode 2 : Utiliser l'instruction INSERT FROM SELECT