ApsaraDB for ClickHouse:Migrer d'un cluster ClickHouse auto-géré vers Cloud ClickHouse

Pendant la migration

• Durant la migration, le processus de fusion (merge) est suspendu dans le cluster de destination, mais se poursuit dans le cluster auto-géré.

  Remarque

  Si une tâche de migration s'exécute pendant une longue durée, un excès de métadonnées peut s'accumuler dans le cluster de destination. Nous recommandons de limiter la durée des tâches de migration à 5 jours maximum. Les tâches dépassant cette limite sont automatiquement annulées.

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

Périmètre de 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 via SQL, mais pas ceux créés via XML.

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

    • Lorsqu'un dictionnaire de données accède à un service externe, assurez-vous que ce service est disponible et que le cluster figure bien dans sa liste d'autorisation. Si la source de données d'un dictionnaire est une table interne du 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 la migration en raison d'un changement d'adresse IP. Vous devrez alors reconfirmer le paramètre HOST du cluster ClickHouse actuel et recré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 provenant 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 issues 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 dus à des durées de migration trop longues, nous recommandons de purger les données froides de votre cluster auto-gé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 auto-gé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 auto-géré contient des tables utilisant 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 de moteur Kafka/RabbitMQ

Avant de démarrer la migration, notez les définitions de toutes les tables de moteur Kafka/RabbitMQ et de leurs vues matérialisées en aval dans le cluster auto-géré, gérez les tables implicites, puis supprimez ces tables pour éviter les erreurs de migration.

1. Connectez-vous au cluster auto-géré et interrogez toutes les tables de moteur 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 (RENAME) pour éviter toute 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 de moteur 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 des tâches de migration, cliquez sur Create Migration Task.

   1. Configurez les instances source et de destination.

      Définissez les paramètres suivants et cliquez sur Test Connectivity and Proceed.

      Remarque

      Si le test de connexion réussit, passez à l'étape suivante. En cas d'échec, reconfigurez les instances source et de destination en suivant les indications 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és par des virgules. Important Vous ne pouvez pas utiliser le nom de domaine VPC ou 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 auto-gé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 vers Alibaba Cloud, vous pouvez utiliser l'instruction SQL suivante pour obtenir l'adresse IP et le PORT du cluster auto-gé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 vers Alibaba Cloud via une traduction 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 effectue 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 :

        Après le succès de la pré-vérification, la page indique que trois contrôles ont été validés : Instance status check, Storage space check et Local table and distributed table check. Le haut de la page affiche une durée estimée de migration de 2 minutes et décrit les impacts durant la migration :

        • L'instance source reste accessible en lecture et écriture, mais les opérations DDL sont impossibles.

        • L'instance de destination est accessible en lecture, mais les tables migrées ne peuvent pas faire l'objet d'écritures.

        • 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 non-MergeTree conservent uniquement leur structure après la mise à l'échelle, sans migration des données.

        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 Complete, le système crée et démarre la tâche, dont le statut passe à Running. Vous pouvez consulter la tâche dans la liste des tâches.

           • Après la création de la tâche, vous devez la surveiller. Lors de la dernière phase de la migration, vous devez interrompre les opérations d'écriture sur le cluster auto-gé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 auto-gé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 et solutions de pré-vérification de la migration.

        Élément de contrôle	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 l'extension, la mise à niveau ou la réduction) 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 représenter au moins 1,2 fois l'espace de stockage utilisé du cluster auto-géré.
        Local Table and Distributed Table Detection	Si une table locale du cluster auto-géré n'a pas de table distribuée correspondante ou en possède plusieurs, le contrôle échoue. Pour résoudre ce problème, supprimez les tables distribuées excédentaires ou créez une table distribuée unique pour la table locale.

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

Une fois que la tâche de migration entre dans la phase de migration des données (c'est-à-dire que la migration du schéma de table est terminée), utilisez les instructions DDL précédemment sauvegardées pour reconstruire les tables de moteur Kafka/RabbitMQ et leurs vues matérialisées en aval sur le cluster auto-géré. Une fois reconstruites, les données incrémentielles reprennent leur flux 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 la bascule

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

1. Arrêtez les écritures métier. Sur le cluster auto-géré, supprimez les tables de moteur 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 totalement terminée.

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

   Important

   Si vous avez précédemment effectué une opération RENAME sur des tables cibles implicites, 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 affluent normalement.

Étape 10 : Terminer la migration

Après avoir arrêté les écritures sur le cluster auto-géré, vous pouvez 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 non-MergeTree

La tâche de migration transfère uniquement le schéma des tables non-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 non-MergeTree nécessitant une migration de 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 Migrer des données à l'aide de la fonction remote.

Autres opérations

Lorsqu'une tâche de migration se termine, son Migration Status passe à Completed. La liste des tâches ne se met pas à jour instantanément ; actualisez donc la page périodiquement pour consulter le statut le plus récent.

Méthode 1 : Utiliser les commandes BACKUP et RESTORE

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

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