ApsaraDB for ClickHouse:FAQ

ApsaraDB for ClickHouse corrige les bugs de stabilité de la version communautaire et fournit des files d'attente de ressources pour définir les priorités d'utilisation des ressources par rôle utilisateur.

Essayez les solutions suivantes :

• Vérifiez la connectivité réseau. Utilisez ping pour vérifier l'accessibilité du réseau et telnet pour vous assurer que les ports de base de données 3306 et 8123 sont ouverts.

• Vérifiez la configuration de la liste d'autorisation de votre instance ClickHouse. Configuration d'une liste d'autorisation.

• Confirmez l'adresse IP publique de votre machine cliente. Sur un réseau d'entreprise, cette adresse peut changer fréquemment ; utilisez un service de recherche d'IP tel que whatsmyip.

Dans les versions 20.3 et 20.8, le système valide automatiquement la connexion lors de la création d'une table externe. La réussite de la création de la table confirme la connectivité réseau. Si la création de la table échoue, les causes courantes sont les suivantes :

• Le point de terminaison cible et ClickHouse ne se trouvent pas dans le même VPC, ce qui empêche la connectivité réseau.

• Le serveur MySQL utilise une liste d'autorisation. Vous devez ajouter ClickHouse à la liste d'autorisation MySQL.

Causes courantes des échecs de connexion et leurs solutions :

• Cause : L'environnement réseau est mal configuré. Vous ne pouvez vous connecter via un réseau interne que si votre application et l'instance se trouvent dans le même VPC. Si elles se trouvent dans des VPC différents, vous devez activer un endpoint public et vous connecter via le réseau public.

  Solution : Activez l'accès au réseau public. Demande et libération d'adresses IP publiques.

• Cause : L'adresse IP du client ne figure pas dans la liste d'autorisation de l'instance.

  Solution : Ajoutez l'adresse IP du client à la liste d'autorisation. Configuration d'une liste d'autorisation.

• Cause : Le groupe de sécurité de votre instance ECS bloque le trafic sur le port requis.

  Solution : Mettez à jour les règles du groupe de sécurité ECS. Guide d'utilisation des groupes de sécurité.

• Cause : Un pare-feu d'entreprise bloque la connexion.

  Solution : Modifiez les règles de votre pare-feu pour autoriser le trafic sortant vers l'instance.

• Cause : Le nom d'utilisateur ou le mot de passe dans la chaîne de connexion contient des caractères spéciaux, tels que !@#$%^&*()_+=. Le client risque de ne pas interpréter correctement ces caractères, ce qui entraîne un échec de la connexion.

  Solution : Vous devez encoder en URL tous les caractères spéciaux présents dans la chaîne de connexion. Les règles d'encodage sont les suivantes :

  ! : %21
  @ : %40
  # : %23
  $ : %24
  % : %25
  ^ : %5e
  & : %26
  * : %2a
  ( : %28
  ) : %29
  _ : %5f
  + : %2b
  = : %3d

  Par exemple, si votre mot de passe est ab@#c, le mot de passe encodé dans la chaîne de connexion doit être ab%40 %23c.

• Cause : ApsaraDB for ClickHouse provisionne automatiquement une instance Server Load Balancer (SLB) en paiement à l'utilisation pour votre cluster. Si votre compte Alibaba Cloud présente des impayés, l'instance SLB peut être suspendue, rendant votre instance ApsaraDB for ClickHouse inaccessible.

  Solution : Vérifiez si votre compte Alibaba Cloud présente des impayés et réglez tout solde dû pour restaurer le service.

Pour résoudre ce problème, effectuez l'une des opérations suivantes :

• Divisez les fichiers volumineux dans OSS en fichiers plus petits avant de les importer.

• Effectuez une mise à l'échelle verticale de votre cluster pour augmenter sa mémoire. Mise à l'échelle verticale et horizontale des clusters Edition Community.

Causes courantes et solutions :

• Cause 1 : Configuration des paramètres sous-optimale. ClickHouse offre de meilleures performances avec une taille de batch élevée et un nombre réduit d'concurrent operations. Un seul batch peut souvent contenir des dizaines, voire des centaines de milliers de lignes, selon la taille moyenne de vos lignes. À titre indicatif, vous pouvez estimer cette valeur sur la base de 100 octets par ligne, mais il convient de l'ajuster en fonction des caractéristiques réelles de vos données.

  Solution : Définissez le nombre d'concurrent operations à 10 ou moins. Testez différentes valeurs de paramètres pour trouver la configuration optimale adaptée à votre charge de travail.

• Cause 2 : Ressources insuffisantes dans le exclusive resource group DataWorks. Les instances ECS du exclusive resource group peuvent être sous-dimensionnées. Une capacité CPU ou mémoire insuffisante peut limiter le nombre d'concurrent operations et la network egress bandwidth disponible. De même, la définition d'une taille de batch importante sur une machine dotée d'une mémoire limitée peut déclencher un garbage collection (GC) Java fréquent dans le processus DataWorks, ce qui ralentit les performances.

  Solution : Vérifiez les spécifications de l'instance ECS dans les journaux de sortie DataWorks.

• Cause 3 : Le goulot d'étranglement se situe au niveau de la data source.

  Solution : Dans les journaux de sortie DataWorks, recherchez les métriques totalWaitReaderTime et totalWaitWriterTime. Si la valeur de totalWaitReaderTime est significativement supérieure à celle de totalWaitWriterTime, le goulot d'étranglement se trouve côté lecture (la data source), et non côté écriture.

• Cause 4 : Utilisation d'un public network endpoint. Un public network endpoint dispose d'une bande passante limitée et ne convient pas aux opérations d'importation ou d'exportation de données haute performance.

  Solution : Basculez vers un endpoint de VPC network.

• Cause 5 : Présence de dirty data. Normalement, les données sont écrites par batch. Toutefois, si des dirty data sont rencontrées, l'écriture du batch actuel échoue. DataX revient alors à un mode d'insertion ligne par ligne. Ce repli génère un nombre excessif de data parts et réduit considérablement les performances d'écriture.

  Vous pouvez utiliser les deux méthodes suivantes pour vérifier la présence de dirty data.

  • Vérifiez les messages d'erreur. Si le journal contient une erreur Cannot parse, cela indique la présence de dirty data.

    Vous pouvez utiliser la requête SQL suivante pour identifier les exceptions.

    SELECT written_rows, written_bytes, query_duration_ms, event_time, exception
    FROM system.query_log
    WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart' and exception_code != 0
    ORDER BY event_time DESC LIMIT 30;

  • Surveillez le nombre de lignes par batch. Si le nombre de lignes par batch tombe à 1, cela indique fortement que DataX a rencontré des dirty data et est passé en mode ligne par ligne.

    Vous pouvez utiliser la requête SQL suivante pour vérifier le nombre de lignes.

    SELECT written_rows, written_bytes, query_duration_ms, event_time
    FROM system.query_log
    WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart'
    ORDER BY event_time DESC LIMIT 30;

  Solution : Identifiez et corrigez ou supprimez les dirty data de la data source.

Effectuez les vérifications suivantes :

1. Consultez la table système query_log pour détecter d'éventuelles erreurs lors de l'importation. La présence d'erreurs suggère une perte de données.

2. Vérifiez si le moteur de votre table prend en charge la déduplication. Par exemple, si vous utilisez le moteur de table ReplacingMergeTree, le nombre de lignes dans ClickHouse peut être inférieur à celui de Hive, car ce moteur supprime les doublons.

3. Vérifiez l'exactitude du nombre de lignes dans la source Hive, car le comptage initial de la source peut être imprécis.

Vérifiez les points suivants :

1. Consultez la table système query_log pour détecter d'éventuelles erreurs survenues lors de l'importation. La présence d'erreurs peut indiquer une perte de données.

2. Vérifiez si le moteur de votre table effectue une déduplication des données. Par exemple, le moteur ReplacingMergeTree supprime les entrées en double, ce qui réduit le nombre de lignes dans ClickHouse par rapport à Kafka.

3. Vérifiez si le paramètre kafka_skip_broken_messages est activé dans la configuration de votre table externe Kafka. S'il est activé, ClickHouse ignore les messages qui ne peuvent pas être analysés, ce qui réduit le nombre de lignes dans ClickHouse par rapport à Kafka.

Utilisez l'une des méthodes suivantes :

• Exportez les fichiers à l'aide du client ClickHouse. Migration de données d'une instance ClickHouse autogérée vers ApsaraDB for ClickHouse Community Edition.

• Utilisez la fonction remote.

  INSERT INTO <destination_table> SELECT * FROM remote('<connection_string>', '<database>', '<table>', '<username>', '<password>');

Solution : Suivez ces étapes pour resynchroniser les données MySQL.

1. Supprimez la table dont la synchronisation s'est arrêtée.

   DROP TABLE <table_name> ON cluster default;

   Remarque

   Dans cette commande, table_name correspond au nom de la table dont la synchronisation s'est arrêtée. Si la table est une table distribuée, vous devez supprimer à la fois la table distribuée et sa table locale.

2. Redémarrez le processus de synchronisation.

   ALTER database <database_name> ON cluster default MODIFY SETTING skip_unsupported_tables = 1;

   Remarque

   Dans cette commande, <database_name> correspond au nom de la base de données synchronisée dans ApsaraDB for ClickHouse.

• Cause : Utilisation élevée de la mémoire.

  Solution : Ajustez le paramètre max_insert_threads pour réduire l'utilisation de la mémoire.

• Cause : Utilisation d'une instruction insert into select pour importer des données entre des clusters ClickHouse.

  Solution : Migrez les données en les important à partir de fichiers. Migration de données d'une instance ClickHouse autogérée vers ApsaraDB for ClickHouse Community Edition.

Le serveur ClickHouse suit l'utilisation de la mémoire à plusieurs niveaux. Pour une requête unique, un traqueur de mémoire agrège l'utilisation de la mémoire de tous ses threads de requête. Ce traqueur rapporte ensuite les informations à un traqueur de mémoire global. La solution dépend de l'erreur spécifique que vous rencontrez.

• Une erreur avec Memory limit (for query) signifie que la requête a échoué car elle a consommé trop de mémoire, dépassant sa limite de 70 % de la capacité totale de mémoire de l'instance. Pour résoudre ce problème, effectuez une mise à niveau verticale pour augmenter la capacité de mémoire de l'instance.

• Une erreur avec Memory limit (for total) signifie que l'utilisation globale de la mémoire sur l'instance a dépassé la limite système de 90 % de la capacité totale de mémoire de l'instance. Cette erreur peut résulter d'une concurrence élevée des requêtes ou de tâches asynchrones en arrière-plan gourmandes en ressources, telles que les tâches de fusion de clés primaires qui s'exécutent après les écritures de données. Commencez par réduire la concurrence des requêtes. Si l'erreur persiste, effectuez une mise à niveau verticale pour augmenter la capacité de mémoire de l'instance.

La concurrence maximale par défaut des requêtes pour un serveur est de 100. Modifiez cette valeur dans la console :

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 cible.

3. Dans le volet de navigation de gauche, cliquez sur Parameter Configuration.

4. Sur la page Parameter Configuration, cliquez sur l'icône de modification dans la colonne Parameter Value pour le paramètre max_concurrent_queries.

5. Saisissez la nouvelle valeur dans la boîte de dialogue et cliquez sur OK.

6. Cliquez sur Submit Parameters.

7. Cliquez sur OK.

Envisagez les solutions suivantes :

• Vérifiez si vous utilisez un cluster multi-nœuds. Dans un cluster multi-nœuds, vous devez créer une table distribuée. Écrivez dans cette table et interrogez-la pour obtenir des résultats cohérents. Sinon, chaque requête peut atteindre un shard différent. Création d'une table distribuée.

• Vérifiez si vous utilisez un cluster maître-réplica. Dans un cluster maître-réplica, utilisez des tables avec un moteur de table de la série Replicated pour synchroniser les données entre les réplicas. Sinon, chaque requête peut atteindre un réplica différent, ce qui entraîne des résultats incohérents. Moteurs de table.

Causes courantes et solutions :

• Cause 1 : Le processus de création de table est incorrect. Un cluster distribué ClickHouse ne dispose pas de sémantique DDL distribuée native. Si vous utilisez une instruction create table dans un cluster ClickHouse géré par vos soins, l'instruction peut renvoyer un message de succès, mais la table est créée uniquement sur le serveur actuellement connecté. Lorsque vous vous connectez à un autre serveur, la table n'est pas visible.

  Solution :

  1. Lorsque vous créez une table, utilisez l'instruction create table <table_name> on cluster default. La clause on cluster default diffuse l'instruction vers tous les nœuds du cluster par défaut.

     CREATE TABLE test ON cluster default (a UInt64) Engine = MergeTree() ORDER BY tuple();

  2. Créez une autre table qui utilise le moteur de table distribué au-dessus de la table de test.

     CREATE TABLE test_dis ON cluster default AS test Engine = Distributed(default, default, test, cityHash64(a));

• Cause 2 : La table ReplicatedMergeTree est mal configurée. Le moteur de table ReplicatedMergeTree est une version améliorée du moteur de table MergeTree qui fournit une synchronisation maître-réplica. Sur une instance à réplica unique, vous pouvez uniquement créer des tables avec le moteur MergeTree. Sur une instance maître-réplica, vous devez créer des tables avec le moteur ReplicatedMergeTree.

  Solution : Lorsque vous créez une table dans une instance maître-réplica, utilisez ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') ou ReplicatedMergeTree() pour configurer le moteur de table ReplicatedMergeTree. Les arguments dans ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') font partie d'un modèle fixe et ne doivent pas être modifiés.

Symptôme

Un TTL est correctement configuré pour une table, mais les données expirées ne sont pas supprimées automatiquement. Le paramètre TTL n'est donc pas appliqué.

Étapes de dépannage

1. Vérifiez si le paramètre TTL de la table est approprié.

   Définissez le TTL en fonction de vos besoins métier. Nous vous recommandons de définir le TTL au niveau du jour et d'éviter les configurations à la seconde ou à la minute, telles que TTL event_time + INTERVAL 30 SECOND.

2. Vérifiez le paramètre materialize_ttl_after_modify.

   Ce paramètre contrôle l'application d'une nouvelle règle TTL aux données existantes après l'exécution d'une instruction ALTER MODIFY TTL. La valeur par défaut est 1 (activé). Une valeur de 0 signifie que la règle s'applique uniquement aux nouvelles données ; les données existantes ne sont pas affectées par le TTL.

   • Vérifiez le paramètre

     SELECT * FROM system.settings WHERE name like 'materialize_ttl_after_modify';

   • Modifiez le paramètre

     Important

     Cette commande analyse toutes les données existantes et peut générer une charge élevée sur les ressources. Utilisez-la avec précaution.

     ALTER TABLE $table_name MATERIALIZE TTL;

3. Diagnostiquez la stratégie de nettoyage des partitions.

   Lorsque le paramètre ttl_only_drop_parts est défini sur 1, ClickHouse supprime une partie de données uniquement lorsque toutes les lignes qu'elle contient ont expiré.

   • Vérifiez le paramètre ttl_only_drop_parts

     SELECT * FROM system.merge_tree_settings WHERE name LIKE 'ttl_only_drop';

   • Vérifiez l'état d'expiration des partitions

     SELECT partition, name, active, bytes_on_disk, modification_time, min_time, max_time, delete_ttl_info_min, delete_ttl_info_max FROM system.parts c WHERE database = 'your_dbname' AND TABLE = 'your_tablename' LIMIT 100;

     • delete_ttl_info_min : Valeur minimale de la clé datetime utilisée pour la règle TTL DELETE dans cette partie.

     • delete_ttl_info_max : Valeur maximale de la clé datetime utilisée pour la règle TTL DELETE dans cette partie.

   • Si les partitions et les règles TTL ne sont pas alignées, certaines données peuvent ne pas être nettoyées rapidement. Les sections suivantes expliquent l'interaction entre les partitions et les règles TTL.

     • Si les partitions et les règles TTL sont alignées (par exemple, un partitionnement par jour avec un TTL quotidien), ClickHouse peut déterminer l'expiration en fonction de l'ID de partition et supprimer une partition entière en une seule fois. Il s'agit de la stratégie la plus efficace. Pour des performances optimales, nous vous recommandons de combiner une stratégie de partitionnement (par jour, par exemple) avec ttl_only_drop_parts=1 afin de supprimer efficacement les données expirées.

     • Si les règles ne sont pas alignées et que ttl_only_drop_parts = 1, ClickHouse vérifie les informations TTL de chaque partie. Une partie est supprimée uniquement après que toutes ses données ont dépassé l'horodatage delete_ttl_info_max.

     • Si les règles ne sont pas alignées et que ttl_only_drop_parts = 0, ClickHouse doit analyser les données de chaque partie pour trouver et supprimer individuellement les lignes expirées. Il s'agit de la stratégie la plus gourmande en ressources.

4. Contrôlez la fréquence de déclenchement des fusions.

   Les données expirées sont supprimées de manière asynchrone lors des fusions, et non en temps réel. Vous pouvez contrôler la fréquence de fusion avec le paramètre merge_with_ttl_timeout ou forcer la matérialisation du TTL en utilisant l'instruction ALTER TABLE ... MATERIALIZE TTL.

   • Vérifiez le paramètre

     SELECT * FROM system.merge_tree_settings WHERE name = 'merge_with_ttl_timeout';

     Remarque

     L'unité est la seconde. La valeur par défaut pour une instance en ligne est de 7 200 secondes (2 heures).

   • Modifiez le paramètre

     Si merge_with_ttl_timeout est défini sur une valeur trop élevée, la fréquence de déclenchement de la fusion TTL diminue, ce qui retarde le nettoyage des données expirées. Vous pouvez réduire cette valeur pour augmenter la fréquence de nettoyage. Pour plus de détails, consultez la page Description des paramètres.

5. Vérifiez les paramètres du pool de threads.

   La suppression des données TTL se produit pendant la phase de fusion des parties et est limitée par les paramètres max_number_of_merges_with_ttl_in_pool (par défaut : 2 pour les instances en ligne) et background_pool_size (par défaut : 16 pour les instances en ligne).

   • Interrogez l'activité actuelle des threads en arrière-plan

     SELECT * FROM system.metrics WHERE metric LIKE 'Background%';

     La métrique BackgroundPoolTask indique le nombre de tâches actuellement actives dans le pool en arrière-plan.

   • Modifiez les paramètres

     Si vos autres paramètres sont corrects et que l'utilisation du CPU est faible, envisagez d'augmenter le paramètre max_number_of_merges_with_ttl_in_pool en fonction de vos besoins métier, par exemple de 2 à 4, ou de 4 à 8. Si cela ne résout pas le problème, envisagez d'augmenter le paramètre background_pool_size.

     Important

     Vous devez redémarrer le cluster si vous ajustez le paramètre max_number_of_merges_with_ttl_in_pool. Vous n'avez pas besoin de redémarrer le cluster lorsque vous augmentez le paramètre background_pool_size, mais vous devez le redémarrer lorsque vous réduisez le paramètre background_pool_size.

6. Vérifiez si le schéma de la table et la conception des partitions sont appropriés.

   Si une table n'est pas partitionnée efficacement ou si la granularité des partitions est trop grossière, l'efficacité du nettoyage TTL diminue. Pour un nettoyage efficace, nous vous recommandons d'aligner la granularité des partitions sur celle du TTL (par exemple, en définissant les deux sur un intervalle quotidien). Pour plus de détails, consultez les pages Meilleures pratiques.

7. Vérifiez si le cluster dispose d'un espace disque suffisant.

   Les opérations de fusion en arrière-plan déclenchent le nettoyage TTL et nécessitent un espace disque disponible. Des parties de données volumineuses ou un espace disque insuffisant (par exemple, une utilisation supérieure à 90 %) peuvent empêcher les opérations de fusion et les suppressions TTL associées.

8. Vérifiez les autres paramètres système dans system.merge_tree_settings.

   • merge_with_recompression_ttl_timeout : Délai minimum avant qu'une fusion avec un TTL de recompression puisse se répéter. Par défaut, cela signifie que les règles TTL sont appliquées à une table au moins toutes les 4 heures. Si vous devez appliquer les règles TTL plus fréquemment, réduisez cette valeur.

   • max_number_of_merges_with_ttl_in_pool : Ce paramètre contrôle le nombre maximal de threads disponibles pour les tâches TTL. Si le nombre de tâches de fusion en cours avec TTL dans le pool de threads en arrière-plan dépasse cette valeur, ClickHouse ne planifie pas de nouvelles tâches de fusion avec TTL.

Une primary key merge doit respecter les deux conditions préalables suivantes pour fonctionner correctement.

• La clé ORDER BY doit inclure la partition key de la storage table. Une primary key merge ne se produit pas entre différentes partitions.

• Pour une distributed table, la clé ORDER BY doit inclure la clé de sharding, qui est déterminée par l'hash algorithm. Une primary key merge ne se produit pas entre différents nœuds.

Le tableau suivant décrit les commandes optimize courantes et leur comportement.

Voici les causes courantes et leurs solutions.

• Cause 1 : L'éviction des données TTL se produit pendant la phase de fusion de la clé primaire. Si une partie de données n'est pas fusionnée pendant une période prolongée, le système ne peut pas évacuer les données expirées qu'elle contient.

  Solution :

  • Vous pouvez déclencher manuellement une tâche de fusion en exécutant optimize final ou optimize a specific partition.

  • Lors de la création d'une table, vous pouvez définir des paramètres tels que merge_with_ttl_timeout et ttl_only_drop_parts pour fusionner plus fréquemment les parties de données contenant des données expirées.

• Cause 2 : Si le TTL d'une table est modifié ou ajouté, les parties de données existantes peuvent présenter des informations TTL manquantes ou incorrectes. Cela peut également empêcher l'éviction des données expirées.

  Solution :

  • Vous pouvez régénérer les informations TTL en exécutant alter table materialize ttl.

  • Vous pouvez mettre à jour les informations TTL en exécutant optimize partition.

Pour modifier une table locale, exécutez une instruction DDL. Pour une table distribuée, la procédure dépend de l'écriture ou non de données dans la table.

• Si aucune donnée n'est écrite dans la table, modifiez d'abord la table locale, puis la table distribuée.

• Si des données sont écrites dans la table, la procédure dépend du type de modification.

  Type	Actions
  Ajout d'une colonne nullable	Modifiez la table locale. Modifiez la table distribuée.
  Modification du type de données d'une colonne (vers un type convertible)
  Suppression d'une colonne nullable	Modifiez la table distribuée. Modifiez la table locale.
  Ajout d'une colonne non nullable	Arrêtez l'écriture des données. Exécutez SYSTEM FLUSH DISTRIBUTED sur la table distribuée. Modifiez la table locale. Modifiez la table distribuée. Reprenez l'écriture des données.
  Suppression d'une colonne non nullable
  Renommage d'une colonne

Essayez les solutions suivantes :

• Attendez la fin de l'opération.

• Essayez d'interrompre la requête dans la console.

• Cause 1 : Le client ClickHouse analyse la syntaxe. Cependant, set global on cluster default est une syntaxe côté serveur. Si la version du client est incompatible avec celle du serveur, le client bloque cette instruction.

  Solution :

  • Utilisez un outil qui n'effectue pas d'analyse syntaxique côté client. Parmi les exemples figurent les outils basés sur JDBC, tels que DataGrip et DBeaver.

  • Écrivez un programme JDBC pour exécuter l'instruction.

• Cause 2 : Dans l'instruction set global on cluster default key = value;, la value est une chaîne, mais n'est pas entourée de guillemets.

  Solution : Entourez la valeur de chaîne de guillemets.

Si votre cluster est un cluster Enterprise Edition et que l'instruction de création de table inclut ON CLUSTER default, vous pouvez rencontrer l'erreur ON CLUSTER is not allowed for Replicated database. Ce problème survient dans certaines versions mineures. Mettez à niveau votre instance vers la dernière version. Mettre à niveau les versions mineures du moteur.

Problème : Si vous utilisez un cluster Community Edition multi-nœuds, vous risquez de rencontrer l'erreur Exception: Double-distributed IN/JOIN subqueries is denied (distributed_product_mode = 'deny'). lorsqu'une requête utilise JOIN ou IN pour joindre plusieurs tables distribuées.

Cause : La jointure de plusieurs tables distribuées dans une requête peut provoquer une amplification des requêtes. Par exemple, dans un cluster à trois nœuds, une requête de jointure entre deux tables distribuées se transforme en 3 x 3 sous-requêtes sur les tables locales sous-jacentes. Cette opération consomme d'importantes ressources et augmente la latence. Pour prévenir ce problème, le système bloque ces requêtes par défaut.

Fonctionnement : En remplaçant l'opérateur IN ou JOIN par GLOBAL IN ou GLOBAL JOIN, vous indiquez au moteur d'exécuter la sous-requête de droite sur un seul nœud. Le résultat est stocké dans une table temporaire, qui est ensuite diffusée à tous les autres nœuds pour effectuer la jointure localement.

Impact de l'utilisation de GLOBAL IN ou GLOBAL JOIN :

• La table temporaire est envoyée à tous les serveurs distants. Évitez cette stratégie pour les grands ensembles de données.

• L'utilisation de GLOBAL IN ou GLOBAL JOIN avec la fonction remote() peut produire des résultats incorrects. En effet, la sous-requête, qui devrait s'exécuter sur l'instance externe, s'exécute plutôt sur l'instance actuelle.

  Par exemple, vous exécutez l'instruction suivante sur instance_a pour interroger les données de l'instance externe cc-bp1wc089c****.

  SELECT *
  FROM remote('cc-bp1wc089c****.clickhouse.ads.aliyuncs.com:3306', `default`, test_tbl_distributed1, '<your_Account>', '<YOUR_PASSWORD>')
  WHERE id GLOBAL IN
      (SELECT id
       FROM test_tbl_distributed1);

  Dans ce cas, instance_a exécute la sous-requête SELECT id FROM test_tbl_distributed1 pour générer une table temporaire, que nous appellerons temp_table_A. Les données de temp_table_A sont ensuite envoyées à l'instance externe cc-bp1wc089c**** pour la requête finale. L'instance externe cc-bp1wc089c**** exécute finalement l'instruction SELECT * FROM default.test_tbl_distributed1 WHERE id IN (temp_table_A);.

  Le problème provient de la source des données dans la table temporaire.

  Selon la description ci-dessus, l'instruction finale exécutée par l'instance cc-bp1wc089c**** est SELECT * FROM default.test_tbl_distributed1 WHERE id IN (temporary table A);. Toutefois, la condition définie dans la table temporaire A est générée sur l'instance a. Dans cet exemple, l'instance cc-bp1wc089c**** aurait dû exécuter SELECT * FROM default.test_tbl_distributed1 WHERE id IN (SELECT id FROM test_tbl_distributed1 );, et la condition définie aurait dû provenir de l'instance cc-bp1wc089c****. Par conséquent, l'utilisation de GLOBAL IN ou GLOBAL JOIN amène la sous-requête à récupérer la condition définie depuis une source incorrecte, ce qui entraîne un résultat erroné.

Solutions :

Solution 1 : Modifiez le code SQL de votre application pour remplacer manuellement IN ou JOIN par GLOBAL IN ou GLOBAL JOIN.

Par exemple, remplacez cette instruction :

SELECT * FROM test_tbl_distributed WHERE id IN (SELECT id FROM test_tbl_distributed1);

par :

SELECT * FROM test_tbl_distributed WHERE id GLOBAL IN (SELECT id FROM test_tbl_distributed1);

Solution 2 : Modifiez le paramètre système distributed_product_mode ou prefer_global_in_and_join afin que le système convertisse automatiquement IN ou JOIN en GLOBAL IN ou GLOBAL JOIN.

SET GLOBAL ON cluster default distributed_product_mode='global';

SET GLOBAL ON cluster default prefer_global_in_and_join = 1;

Pour afficher l'espace disque utilisé par chaque table, exécutez la requête suivante.

SELECT table, formatReadableSize(sum(bytes)) as size, min(min_date) as min_date, max(max_date) as max_date FROM system.parts WHERE active GROUP BY table; 

Voici un exemple de requête :

SELECT * FROM system.disks;

Utilisez la requête suivante :

SELECT * FROM system.parts WHERE disk_name = 'cold_disk';

Pour déplacer une partition de données vers le stockage froid, exécutez l'instruction suivante :

ALTER TABLE table_name MOVE PARTITION partition_expr TO DISK 'cold_disk';

Les causes courantes incluent :

• Une requête déclenchant une erreur OOM (Out Of Memory).

• Un redémarrage de l'instance déclenché par une modification de configuration.

• Un redémarrage de l'instance suite à une mise à niveau ou une rétrogradation.

Le tableau suivant décrit les tables système courantes et leurs fonctions.

Les paramètres au niveau de l'utilisateur correspondent aux éléments de configuration du fichier users.xml. Pour modifier un paramètre, exécutez l'instruction suivante.

SET global ON cluster default ${key}=${value};

Spécifiez le paramètre de quota dans les settings d'une instruction d'exécution :

settings max_memory_usage = XXX;

Dans un cluster multi-node avec dual-replica ou single-replica, le write node présente une CPU usage et une memory usage plus élevées que les autres node s lors d'intenses write operation s. L'utilisation s'équilibre entre les node s une fois les données synchronisées.

• Description du problème :

  Comment afficher les journaux système détaillés pour résoudre les erreurs ou identifier les problèmes potentiels.

• Solution :

  1. Vérifiez le paramètre text_log.level de votre cluster et effectuez l'une des actions suivantes :

     1. Si text_log.level est vide, la journalisation textuelle est désactivée. Pour l'activer, définissez une valeur pour ce paramètre.

     2. Si text_log.level possède une valeur, vérifiez que le niveau de journalisation répond à vos besoins. Sinon, modifiez le paramètre pour atteindre le niveau souhaité.

     Configuration des paramètres config.xml.

  2. Connectez-vous à la base de données cible. Connexion à une base de données.

  3. Exécutez l'instruction suivante pour afficher et analyser les journaux.

     SELECT * FROM system.text_log;

Si le cluster de destination et la source de données se trouvent dans le même VPC et la même région, vérifiez que l'adresse IP de chacun figure dans la liste d'autorisation de l'autre.

• Pour configurer la liste d'autorisation ClickHouse, consultez la section Définir une liste d'autorisation.

• Pour les autres sources de données, reportez-vous à leur documentation produit respective.

Si les conditions précédentes ne sont pas remplies, établissez d'abord la connectivité à l'aide d'une solution réseau appropriée. Ajoutez ensuite l'adresse IP de chacun à la liste d'autorisation de l'autre.

Oui, il est possible de migrer un cluster ClickHouse Community Edition vers un cluster Enterprise Edition.

Vous pouvez migrer des données entre les clusters Enterprise Edition et Community Edition à l'aide de la fonction remote ou en exportant et en important des fichiers de données. Migration de données d'un cluster ClickHouse autogéré vers Alibaba Cloud ClickHouse Community-Compatible Edition.

Par défaut, les instances de l'édition Enterprise 24.5 ou ultérieure utilisent le nouvel analyseur de requêtes. Cet analyseur offre de meilleures performances, mais peut ne pas être rétrocompatible avec certaines instructions SQL héritées. Si vous rencontrez une erreur d'analyse, revenez à l'ancien analyseur. En savoir plus sur le nouvel analyseur.

SET allow_experimental_analyzer = 0;

La fonctionnalité de suspension est uniquement disponible pour les clusters de l'édition Enterprise. Les clusters ClickHouse Community Edition ne peuvent pas être suspendus. Pour suspendre un cluster de l'édition Enterprise, accédez à la page Clusters de l'édition Enterprise. Sélectionnez la région cible dans le coin supérieur gauche. Dans la liste des clusters, repérez le cluster cible et cliquez sur > Suspendre dans la colonne Actions.

Description du problème

Les utilisateurs peu familiarisés avec ClickHouse peuvent créer par erreur des tables utilisant le moteur MergeTree dans un cluster multi-réplica. Cela empêche la synchronisation des données entre les nœuds réplica de chaque shard. Par conséquent, les requêtes exécutées sur la table distribuée correspondante peuvent renvoyer des résultats incohérents. Pour résoudre ce problème, vous devez convertir la table MergeTree en table ReplicatedMergeTree.

Solution

ClickHouse ne propose pas d'instruction DDL permettant de modifier directement le moteur de stockage d'une table. Pour convertir une table MergeTree en table ReplicatedMergeTree, vous devez créer une nouvelle table avec le moteur ReplicatedMergeTree, puis importer les données depuis la table d'origine.

Par exemple, supposons que vous disposiez d'une table MergeTree nommée table_src et de sa table distribuée correspondante nommée table_src_d dans un cluster multi-réplica. Pour convertir cette table MergeTree en table ReplicatedMergeTree, procédez comme suit :

1. Créez la table ReplicatedMergeTree cible, table_dst, ainsi que sa table distribuée correspondante, table_dst_d. CREATE TABLE.

2. Importez les données de la table MergeTree table_src vers table_dst_d. Vous pouvez utiliser l'une des deux méthodes suivantes.

La définition d'un session_id unique garantit que le serveur ClickHouse conserve un contexte cohérent pour les requêtes partageant le même ID de session. Cela vous permet d'exécuter plusieurs instructions SQL au sein d'une seule session. Cet exemple illustre la procédure à suivre avec le client Java ClickHouse (V2).

1. Ajoutez la dépendance au fichier pom.xml de votre projet Maven.

   <dependency>
       <groupId>com.clickhouse</groupId>
       <artifactId>client-v2</artifactId>
       <version>0.8.2</version>
   </dependency>

2. Définissez un ID de session personnalisé dans CommandSettings.

   package org.example;
   
   import com.clickhouse.client.api.Client;
   import com.clickhouse.client.api.command.CommandSettings;
   public class Main {
   
       public static void main(String[] args) {
           Client client = new Client.Builder()
                   .addEndpoint("endpoint") // Instance endpoint
                   .setUsername("username")   // Username
                   .setPassword("password")   // Password
                   .build();
   
           try {
               client.ping(10);
               CommandSettings commandSettings = new CommandSettings();
               // Set the session_id
               commandSettings.serverSetting("session_id","examplesessionid");
               // Set the max_block_size parameter for the session
               client.execute("SET max_block_size=65409 ",commandSettings);
               // Execute the queries
               client.execute("SELECT 1 ",commandSettings);
               client.execute("SELECT 2 ",commandSettings);
   
           } catch (Exception e) {
               throw new RuntimeException(e);
           } finally {
               client.close();
           }
       }
   }

Dans cet exemple, les deux instructions SELECT s'exécutent dans la même session avec un paramètre max_block_size de 65409. ClickHouse Java Client : Java Client | ClickHouse Docs.

Pourquoi les opérations DELETE ou UPDATE restent-elles incomplètes ?

SELECT * FROM clusterAllReplicas('default', system.mutations) WHERE is_done = 0;

Comment résoudre l'erreur « Code: 241. DB::Exception: Memory limit (total) exceeded » dans ApsaraDB for ClickHouse Enterprise Edition ?

• Symptôme : Lors de l'exécution d'une instruction SQL, vous rencontrez le message d'erreur suivant, bien que la mémoire totale de votre cluster dépasse la limite indiquée dans le message :

  Code: 241. DB::Exception: Memory limit (total) exceeded: would use 115.28 GiB (attempt to allocate chunk of 133791376 bytes), maximum: 115.20 GiB. OvercommitTracker decision: Query was selected to stop by OvercommitTracker.: While executing AggregatingTransform. (MEMORY_LIMIT_EXCEEDED) (version 24.2.2.16476 (official build))

• Cause : Dans ApsaraDB for ClickHouse Enterprise Edition, un nœud unique possède une limite CCU (maximum de 32 CCU, où 1 CCU équivaut approximativement à 1 vCore et 4 Go de mémoire). Si une seule requête SQL consomme plus de mémoire que le seuil du nœud, MemoryTracker intercepte la requête. Le seuil par défaut est égal à 0,9 fois la mémoire totale du nœud. Vous pouvez exécuter l'instruction SQL suivante pour interroger le seuil :

  SELECT *
  FROM system.server_settings
  WHERE name = 'max_server_memory_usage_to_ram_ratio';

• Solution : Définissez le paramètre allow_experimental_parallel_reading_from_replicas sur 1. Cela permet de distribuer la phase de lecture des données sur plusieurs nœuds, répartissant ainsi la consommation de mémoire. Consultez la rubrique Enterprise Edition.

Pourquoi les résultats des requêtes sont-ils incohérents ?