ApsaraDB for ClickHouse:Mise à niveau via la migration de données

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Deux clusters Community-compatible Edition, tous deux avec le statut Running

  Pour migrer entre l'édition Community-compatible et l'édition Enterprise, consultez Migrate a ClickHouse Community-compatible Edition cluster to an Enterprise Edition cluster .

• Un compte de base de données et un mot de passe configurés sur les deux clusters

• La même configuration de stockage hiérarchisé pour les données chaudes et froides sur les deux clusters

• Les deux clusters dans la même région et le même Virtual Private Cloud (VPC), avec l'adresse IP de chaque cluster ajoutée à la liste d'autorisation de l'autre

  Exécutez SELECT * FROM system.clusters; pour trouver l'adresse IP d'un cluster. Pour configurer la liste d'autorisation, consultez Set a whitelist .

• Un cluster de destination dont la version majeure du moteur est ultérieure à celle du cluster source

• Un espace de stockage sur disque disponible sur le cluster de destination (hors stockage froid) qui représente au moins 1,2 fois l'espace de stockage sur disque utilisé du cluster source (hors stockage froid)

• Chaque table locale du cluster source associée à exactement une table distribuée

Pour connaître les versions prises en charge, consultez Release notes for ApsaraDB for ClickHouse Community-compatible Edition.

Éléments pouvant et ne pouvant pas être migrés

Contenu de migration pris en charge :

• Bases de données, tables (moteur MergeTree), vues matérialisées, dictionnaires de données (créés uniquement via SQL), autorisations utilisateur et configurations de cluster

• Schémas de table des tables non-MergeTree (tables externes et tables Log) — schémas uniquement, sans les données métier

  Si le cluster source contient des tables non-MergeTree, le cluster de destination ne disposera que de leurs schémas après la migration, sans aucune donnée métier. Pour migrer les données métier, utilisez la fonction remote . Pour plus d'informations, consultez Use the remote function to migrate data .

Non pris en charge :

• Dictionnaires de données créés à l'aide de XML

• Tables utilisant les moteurs Kafka et RabbitMQ (données métier)

Liste de contrôle de préparation

Avant de démarrer la migration :

• Confirmez qu'aucune opération de gestion (mise à l'échelle horizontale, mise à niveau ou rétrogradation) n'est en cours sur l'un ou l'autre cluster.

• Vérifiez la présence de dictionnaires de données créés via XML en exécutant : SELECT * FROM system.dictionaries WHERE (database = '') OR isNull(database); — si cette requête renvoie des résultats, supprimez ces dictionnaires avant de poursuivre.

• Si un dictionnaire de données accède à un service externe, confirmez que le service est accessible et que sa liste d'autorisation permet l'accès depuis le cluster de destination.

• Si un dictionnaire de données utilise une table ClickHouse interne comme source avec le paramètre HOST défini sur une adresse IP, l'IP change après la migration : recréez manuellement ce dictionnaire de données avec la nouvelle IP après la migration.

• Pour les tables Kafka et RabbitMQ : videz-les du cluster source et recréez-les sur le cluster de destination, ou utilisez des groupes de consommateurs différents pour éviter le fractionnement des données.

• Maintenez le total des données froides dans le cluster source inférieur à 1 To. Des volumes de données froides plus importants prolongent considérablement la durée de migration et peuvent entraîner l'échec de la tâche.

• Après la mise à niveau, mettez à jour l'endpoint dans les paramètres de votre client pour qu'il pointe vers le cluster de destination.

Impacts potentiels

Cluster source pendant la migration :

• Les opérations de lecture et d'écriture se poursuivent normalement.

• Les opérations Data Definition Language (DDL) (ajout, suppression ou modification de bases de données et de tables) sont bloquées.

• Lorsque le temps restant estimé pour la migration descend à 10 minutes ou moins, le cluster source suspend automatiquement les écritures pour garantir la cohérence des données :

  • Si cela se produit dans la fenêtre de temps d'arrêt des écritures prédéfinie, les écritures s'arrêtent immédiatement.

  • Si cela se produit en dehors de la fenêtre d'arrêt des écritures et dans les 5 jours suivant la création de la tâche, modifiez la fenêtre de temps d'arrêt des écritures pour continuer.

  • Si cela se produit en dehors de la fenêtre d'arrêt des écritures et plus de 5 jours après la création de la tâche, la migration échoue. Annulez la tâche, effacez les données migrées du cluster de destination et recommencez.

• Les écritures reprennent automatiquement lorsque toutes les données sont migrées, ou lorsque la fenêtre de temps d'arrêt des écritures se termine avant la fin de la migration.

Cluster de destination après la migration :

Le cluster de destination exécute des opérations de fusion fréquentes pendant une période après la migration, ce qui augmente l'utilisation des E/S et la latence des requêtes. Prévoyez cette augmentation de latence avant de basculer le trafic. Pour estimer la durée des opérations de fusion, consultez Calculate the merge duration after migration.

Aperçu de la migration

Toutes les étapes sont effectuées sur le cluster de destination, et non sur le cluster source.

1. Enregistrez et nettoyez les tables utilisant les moteurs Kafka/RabbitMQ (ignorez si cela ne s'applique pas).

2. Créez une tâche de migration sur le cluster de destination.

3. Évaluez si la migration peut aboutir (requis uniquement si la vitesse d'écriture source dépasse 20 Mo/s).

4. Surveillez la tâche de migration.

5. Recréez les tables utilisant les moteurs Kafka/RabbitMQ sur le cluster source (ignorez si cela ne s'applique pas).

6. Supprimez les tables utilisant les moteurs Kafka/RabbitMQ sur le cluster source (ignorez si cela ne s'applique pas).

7. Recréez les tables utilisant les moteurs Kafka/RabbitMQ sur le cluster de destination (ignorez si cela ne s'applique pas).

8. (Facultatif) Annulez la tâche de migration si nécessaire.

9. (Facultatif) Modifiez la fenêtre de temps d'arrêt des écritures.

Étape 1 : enregistrer et nettoyer les tables utilisant les 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, traitez les tables implicites, puis supprimez ces tables pour éviter les erreurs de migration.

1. Connectez-vous au cluster source 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 pour empêcher 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 2 : créer une tâche de migration

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

2. Sur la page Clusters, sélectionnez 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.

5. Configurez les instances source et de destination, puis cliquez sur Test Connectivity and Proceed.

   Si le test de connexion échoue, reconfigurez les instances selon les instructions du message d'erreur.

   

6. Passez en revue les détails du contenu de la migration, puis cliquez sur Next: Pre-detect and Start Synchronization.

7. Le système exécute une pré-vérification avec les contrôles suivants :

   Check	Requirement
   Instance status	Aucune tâche de gestion (mise à l'échelle horizontale, modifications de configuration) en cours sur l'un ou l'autre cluster
   Storage space	Stockage sur disque de destination >= 1,2 fois le stockage sur disque source (hors stockage froid)
   Local table and distributed table	Chaque table locale du cluster source possède exactement une table distribuée

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

     1. Passez en revue les détails d'impact sur la page.

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

        Définissez la fenêtre d'arrêt des écritures sur au moins 30 minutes pour améliorer le taux de réussite de la migration. La date de fin ne doit pas dépasser 5 jours à compter d'aujourd'hui. Planifiez la fenêtre pendant les heures creuses pour minimiser l'impact sur l'activité.

     3. Cliquez sur Completed pour créer et démarrer la tâche.

   • Si la pré-vérification échoue : Résolvez les problèmes indiqués, puis relancez la migration.

Étape 3 : évaluer si la migration peut aboutir

Ignorez cette étape si la vitesse d'écriture du cluster source est inférieure à 20 Mo/s.

Si la vitesse d'écriture du cluster source dépasse 20 Mo/s, vérifiez que le cluster de destination peut suivre :

1. Ouvrez View cluster monitoring information et consultez la métrique Disk throughput pour le cluster de destination.

2. Comparez les deux vitesses d'écriture :

   • Vitesse d'écriture de destination >= vitesse d'écriture source : La migration a un taux de réussite élevé. Passez à l'étape 4.

   • Vitesse d'écriture de destination < vitesse d'écriture source : La migration peut échouer. Annulez la tâche de migration et effectuez plutôt une migration manuelle.

Étape 4 : surveiller la tâche de migration

1. Sur la page Clusters, sélectionnez 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 Migration from ClickHouse. La liste de migration affiche le Migration Status, les Running Information et la Data Write-Stop Window pour chaque tâche.

   Lorsque le temps restant estimé dans la colonne Running Information descend à 10 minutes ou moins et que le statut est Migrating , la logique d'arrêt des écritures se déclenche. Consultez Impacts potentiels pour savoir ce qui se passe dans chaque scénario.

   Important

   • Si le cluster source contient des tables utilisant les moteurs Kafka/RabbitMQ : lorsque 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), effectuez l'Étape 5 pour reconstruire les tables utilisant les moteurs Kafka/RabbitMQ sur le cluster source afin que les données incrémentielles reprennent leur flux 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 utilisant les moteurs Kafka/RabbitMQ et leurs vues matérialisées en aval sur le cluster source afin d'éviter qu'un backlog de messages pendant la période d'arrêt des écritures ne provoque une incohérence des données.

Étape 5 : reconstruire les tables utilisant les moteurs Kafka/RabbitMQ sur le cluster source

Une fois que la tâche de migration est entrée 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 enregistrées pour reconstruire les tables utilisant les moteurs Kafka/RabbitMQ et leurs vues matérialisées en aval sur le cluster source. 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 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 utilisant les moteurs Kafka/RabbitMQ sur le cluster source

Peu avant la fenêtre d'arrêt des écritures configurée, supprimez les tables utilisant les 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.

-- 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 7 : reconstruire les tables utilisant les 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 utilisant les 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, sélectionnez 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 Migration from ClickHouse.

3. Dans la colonne Actions de la tâche cible, cliquez sur Stop Migration.

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

La liste des tâches peut ne pas se mettre à jour immédiatement après l'annulation. Actualisez la page pour vérifier le dernier statut. Après l'annulation, le Migration Status passe à Completed . Avant de démarrer une nouvelle migration, effacez les données migrées du cluster de destination pour éviter la duplication des données.

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

1. Sur la page Clusters, sélectionnez 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 Migration from ClickHouse.

3. Dans la colonne Actions de la tâche cible, cliquez sur Modify Data Write-Stop Time Window.

4. Dans la boîte de dialogue Modify Data Write-Stop Time Window, sélectionnez une nouvelle Write-stop Time. Les mêmes règles qui s'appliquent lors de la création de la tâche s'appliquent également ici.

5. Cliquez sur OK.

Étapes suivantes

Après avoir confirmé que toutes les données métier ont été migrées avec succès vers le cluster de destination, supprimez le cluster source.

Pour les instructions de suppression, consultez Delete a cluster.