ApsaraDB for ClickHouse:Migrate data between ClickHouse community-compatible clusters

• Les clusters source et de destination doivent répondre aux exigences suivantes :

  • Il s'agit de clusters de l'édition compatible avec la communauté.

    Remarque

    Pour migrer d'un cluster de l'édition compatible avec la communauté vers un cluster de l'édition Enterprise, ou inversement, consultez la rubrique Migrer un cluster ClickHouse de l'édition compatible avec la communauté vers un cluster de l'édition Enterprise.

  • Les deux clusters sont à l'état Running.

  • Vous disposez d'un compte de base de données et d'un mot de passe pour chaque cluster.

  • Les deux clusters appliquent la même politique de stockage hiérarchisé pour les données chaudes et froides.

  • Les deux clusters utilisent le même VPC, se trouvent dans la même région et leurs adresses IP figurent dans les listes d'autorisation respectives. Si cette condition n'est pas remplie, résolvez d'abord le problème de connectivité réseau. Pour plus d'informations, consultez la rubrique Résoudre les problèmes de connectivité réseau entre un cluster de destination et une source de données.

    Remarque

    Pour afficher l'adresse IP d'une instance Alibaba Cloud ClickHouse, exécutez la commande SELECT * FROM system.clusters;. Pour savoir comment configurer une liste d'autorisation, consultez la rubrique Configurer une liste d'autorisation.

• Le cluster de destination doit également respecter les conditions suivantes :

  • La version est supérieure ou égale à celle du cluster source. Pour connaître la dernière version disponible, consultez la rubrique Édition compatible avec la communauté.

  • L'espace disque disponible (hors stockage froid) représente au moins 1,2 fois l'espace disque utilisé (hors stockage froid) du cluster source.

• Chaque table locale du cluster source doit disposer d'une table distribuée unique.

Étape 1 : Enregistrer et nettoyer les tables des moteurs Kafka/RabbitMQ

Avant de démarrer 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 source, gérez les tables implicites, puis supprimez ces tables pour éviter les erreurs de migration.

1. Connectez-vous au cluster source et interrogez toutes les tables des 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 des 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 2 : Créer une tâche de migration

1. Connectez-vous à la console Alibaba Cloud ClickHouse.

2. Sur la page Clusters, cliquez sur l'onglet 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. Cliquez sur Create Migration Task.

   1. Configurez les instances source et de destination.

      Saisissez les informations requises et cliquez sur Test Connectivity and Proceed.

      Remarque

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

      • Source Instance : sélectionnez la source access method (par exemple Express Connect/VPN Gateway/Smart Access Gateway/ECS-hosted ClickHouse), puis spécifiez Instance Region, Cluster Name, Source Cluster Name, VPC IP Address, Database Account et Database Password.

      • Destination Instance : spécifiez Instance Region, Instance ID, Database Account et Database Password.

   2. Confirmez le contenu de la migration.

      Vérifiez le contenu de la migration, puis cliquez sur Next: Pre-detect and Start Synchronization.

   3. Le système effectue une vérification préalable et démarre la tâche.

      Le système effectue la Instance Status Detection, la Storage Space Detection et la Local Table and Distributed Table Detection sur les instances source et de destination.

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

        1. Passez en revue l'impact sur les instances pendant la migration.

        2. Définissez le Time of Stopping Data Writing.

           Remarque

           • Les écritures dans le cluster source doivent être arrêtées durant les 10 dernières minutes de la migration pour garantir la cohérence des données.

           • Pour assurer un taux de réussite élevé, nous vous recommandons de définir la durée d'arrêt des écritures sur au moins 30 minutes.

           • Une tâche de migration doit être achevée dans les cinq jours suivant sa création. Par conséquent, la date de fin du Time of Stopping Data Writing doit être antérieure ou égale à current date + 5 days.

           • Pour minimiser l'impact sur votre activité, nous vous recommandons de définir la fenêtre d'arrêt des écritures pendant vos heures creuses.

        3. Cliquez sur Completed.

           Remarque

           Après avoir cliqué sur ce bouton, la tâche est créée et démarrée.

      • Si la vérification préalable échoue, suivez les instructions pour résoudre les problèmes et réessayez la migration des données. Le tableau ci-dessous décrit les éléments de vérification préalable et leurs exigences.

        |
        **Check item**
        |
        **Requirement**
        | | --- | --- | |
        **Instance Status Detection**
        |
        Assurez-vous qu'aucune tâche de gestion, telle que la mise à l'échelle ou les modifications de configuration, n'est en cours d'exécution sur le cluster source ou de destination. Vous ne pouvez pas démarrer la migration si une tâche est en cours.
        | |
        **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 source.
        | |
        **Local Table and Distributed Table Detection**
        |
        La vérification échoue si une table locale du cluster source n'a pas de table distribuée correspondante ou si la table distribuée n'est pas unique. Vous devez supprimer les tables distribuées supplémentaires ou créer une table distribuée unique pour chaque table locale.
        |
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        

Étape 3 : Évaluer l'achèvement de la migration

Si la vitesse d'écriture du cluster source est inférieure à 20 Mo/s, vous pouvez ignorer cette étape.

Si la vitesse d'écriture du cluster source est supérieure à 20 Mo/s, vérifiez la vitesse d'écriture réelle du cluster de destination pour évaluer si la migration peut s'achever. La vitesse d'écriture du cluster de destination doit suivre celle du cluster source. Pour ce faire, suivez ces étapes :

1. Vérifiez le débit disque du cluster de destination pour déterminer sa vitesse d'écriture réelle. Pour plus d'informations, consultez la rubrique Afficher les informations de surveillance du cluster.

2. Comparez les vitesses d'écriture des clusters de destination et source.

   1. Si la vitesse d'écriture du cluster de destination est supérieure à celle du cluster source, la migration a fortement de chances de réussir. Passez à l'étape 4.

   2. Si la vitesse d'écriture du cluster de destination est inférieure à celle du cluster source, la migration a fortement de chances d'échouer. Nous vous recommandons d'annuler la tâche de migration et d'effectuer une migration manuelle.

Étape 4 : Afficher la tâche de migration

1. Sur la page Instance Status Detection, cliquez sur l'onglet Storage Space Detection, puis cliquez sur l'ID du cluster de destination.

2. Dans le volet de navigation de gauche, cliquez sur Local Table and Distributed Table Detection > Migration from ClickHouse.

   Sur la page de liste des migrations d'instances, affichez le Migration Status, les Running Information et la Data Write-Stop Window de la tâche.

   Remarque

   Lorsque le temps restant estimé dans la colonne Running Information est inférieur ou égal à 10 minutes et que le Migration Status est Migrating, un arrêt des écritures est déclenché sur le cluster source pour garantir la cohérence des données. Les règles sont les suivantes :

   • Si l'heure de déclenchement se situe dans la fenêtre d'arrêt des écritures configurée, les écritures dans le cluster source sont arrêtées.

   • Si l'heure de déclenchement se situe en dehors de la fenêtre d'arrêt des écritures configurée mais est antérieure ou égale à task start (that is, task creation) date + 5 days, vous pouvez modifier la fenêtre d'arrêt des écritures pour poursuivre la migration.

   • Si l'heure de déclenchement se situe en dehors de la fenêtre d'arrêt des écritures configurée et est postérieure à task start (that is, task creation) date + 5 days, la migration échoue. Vous devez annuler la tâche de migration, effacer les données migrées du cluster de destination et créer une nouvelle tâche de migration.

   Important

   • Si le cluster source contient des tables utilisant les moteurs Kafka/RabbitMQ : lorsque la tâche de migration entre dans la phase de data migration (c'est-à-dire que la migration du schéma de table est terminée), effectuez l'étape 5 pour reconstruire les tables des moteurs Kafka/RabbitMQ sur le cluster source afin que les données incrémentielles recommencent à circuler et soient synchronisées vers le cluster de destination.

   • Peu avant la fenêtre d'arrêt des écritures configurée, effectuez l'étape 6 pour supprimer les tables des moteurs Kafka/RabbitMQ et leurs vues matérialisées en aval sur le cluster source, afin d'éviter que l'accumulation de messages pendant la période d'arrêt des écritures ne provoque une incohérence des données.

Étape 5 : Reconstruire les tables des moteurs Kafka/RabbitMQ sur le cluster source

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

-- Rebuild Kafka/RabbitMQ engine tables on the source 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 6 : Supprimer les tables des moteurs Kafka/RabbitMQ sur le cluster source

Peu avant la fenêtre d'arrêt des écritures configurée, supprimez les tables des moteurs Kafka/RabbitMQ et leurs vues matérialisées en aval sur le cluster source pour arrêter les écritures de données incrémentielles et garantir la cohérence de la synchronisation finale des données.

-- Delete materialized views first
DROP TABLE <database>.<materialized_view_name> ON CLUSTER default;

-- Then delete Kafka/RabbitMQ engine tables
DROP TABLE <database>.<kafka_or_rabbitmq_table_name> ON CLUSTER default;

Étape 7 : Reconstruire les tables des moteurs Kafka/RabbitMQ sur le cluster de destination

Une fois la tâche de migration terminée, utilisez les instructions DDL précédemment enregistrées pour reconstruire les tables des moteurs Kafka/RabbitMQ et leurs vues matérialisées en aval sur le cluster de destination afin de restaurer le pipeline de consommation des données incrémentielles.

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

-- Rebuild materialized view
CREATE MATERIALIZED VIEW <database>.<materialized_view_name> TO <database>.<target_table_name>
AS SELECT ... FROM <database>.<kafka_or_rabbitmq_table_name>;

Étape 8 : (Facultatif) Annuler la tâche de migration

1. Sur la page Clusters, cliquez sur l'onglet Clusters of Community-compatible Edition, puis cliquez sur l'ID du cluster de destination.

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

3. Dans la colonne Actions de la tâche de migration, cliquez sur Cancel Migration.

4. Dans la boîte de dialogue Cancel Migration, cliquez sur OK.

   Remarque

   • Après l'annulation de la migration, la liste des tâches n'est pas mise à jour immédiatement. Actualisez la page périodiquement pour vérifier l'état de la tâche.

   • Une fois la tâche annulée, son Migration Status passe à Completed.

   • Avant de démarrer une nouvelle migration, vous devez effacer les données migrées du cluster de destination pour éviter la duplication des données.

Étape 9 : (Facultatif) Modifier la fenêtre d'arrêt des écritures

1. Sur la page Clusters, cliquez sur l'onglet Clusters of Community-compatible Edition, puis cliquez sur l'ID du cluster de destination.

2. Dans le volet de navigation de gauche, cliquez sur Data Migration and Synchronization > Clusters.

3. Dans la colonne Clusters of Community-compatible Edition de la tâche de migration, cliquez sur Data Migration and Synchronization.

4. Dans la boîte de dialogue Migration from ClickHouse, sélectionnez un nouveau Actions.

   Remarque

   Les règles de définition du Modify Data Write-Stop Time Window sont identiques à celles de la création d'une tâche de migration.

5. Cliquez sur Modify Data Write-Stop Time Window.