ApsaraDB for ClickHouse:FAQ

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

Essayez les solutions suivantes :

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

• Vérifiez la configuration de la liste d'autorisation ClickHouse. Consultez la rubrique Configurer 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 donc un service de vérification 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. Une création de table réussie confirme la connectivité réseau. Si la création de la table échoue, les causes fréquentes incluent :

• L'endpoint 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 fréquentes des échecs de connexion et leurs solutions :

• Cause : L'environnement réseau est mal configuré. Vous pouvez vous connecter via un réseau interne uniquement 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. Consultez la rubrique Demander et libérer des adresses IP publiques.

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

  Solution : Ajoutez l'IP du client à la liste d'autorisation. Consultez la rubrique Configurer 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. Consultez la rubrique 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 peut ne pas interpréter correctement ces caractères, ce qui provoque un échec de 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 paiements en retard, l'instance SLB peut être suspendue, rendant votre instance ApsaraDB for ClickHouse inaccessible.

  Solution : Vérifiez si votre compte Alibaba Cloud présente des paiements en retard et réglez tout solde impayé pour rétablir le service.

Pour résoudre ce problème, appliquez l'une des mesures suivantes :

• Découpez 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 pour les clusters Community Edition.

Causes fréquentes et solutions associées :

• Cause 1 : configuration sous-optimale des paramètres. ClickHouse offre ses 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 taille sur la base de 100 octets par ligne, mais il convient d'ajuster cette valeur 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. Un manque de CPU ou de mémoire peut limiter le nombre d'concurrent operations ainsi que la network egress bandwidth disponible. De même, définir une taille de batch importante sur une machine disposant de peu de mémoire peut déclencher des ramasse-miettes Java (GC) fréquents dans le processus DataWorks, ce qui ralentit les performances.

  Solution : Consultez les journaux de sortie DataWorks pour vérifier les spécifications des instances ECS.

• 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 totalWaitReaderTime est nettement supérieur à 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 hautes performances.

  Solution : Passez à un endpoint de type VPC network.

• Cause 5 : présence de dirty data. Normalement, les données sont écrites par batch. Cependant, si des dirty data sont rencontrées, l'écriture du batch en cours échoue. DataX bascule alors en mode d'insertion ligne par ligne. Ce repli génère un nombre excessif de data parts et réduit drastiquement les performances d'écriture.

  Vous pouvez utiliser les deux méthodes suivantes pour détecter 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.

    Utilisez 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 ce nombre chute à 1, cela indique fortement que DataX a rencontré des dirty data et est passé en mode ligne par ligne.

    Utilisez 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 repérer d'éventuelles erreurs survenues pendant l'importation. La présence d'erreurs suggère probablement une perte de données.

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

3. Validez l'exactitude du nombre de lignes dans la source Hive, car le décompte initial de la source peut être imprécis.

Procédez aux vérifications suivantes :

1. Examinez la table système query_log pour détecter les erreurs survenues lors de l'importation. Des erreurs indiquent qu'une perte de données a pu se produire.

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

3. Contrôlez 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 dont l'analyse échoue, réduisant ainsi 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 auto-gé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 qui a cessé de se synchroniser.

   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. S'il s'agit d'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> désigne le 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 la consommation mémoire.

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

  Solution : Migrez les données en les important depuis des fichiers. Migration de données d'une instance ClickHouse auto-gé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 traceur mémoire agrège la consommation mémoire de tous ses threads d'exécution. Ce traceur transmet ensuite ses informations à un traceur mémoire global. La solution dépend de l'erreur spécifique que vous rencontrez.

• Une erreur contenant Memory limit (for query) signifie que la requête a échoué car elle a consommé trop de mémoire, dépassant sa limite fixée à 70 % de la capacité mémoire totale de l'instance. Pour y remédier, effectuez une mise à niveau verticale afin d'augmenter la capacité mémoire de l'instance.

• Une erreur contenant Memory limit (for total) indique que l'utilisation globale de la mémoire sur l'instance a dépassé la limite système de 90 % de la capacité mémoire totale. Cette erreur peut résulter d'une forte concurrence des requêtes ou de tâches asynchrones en arrière-plan gourmandes en ressources, telles que les fusions de clés primaires exécutées 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é mémoire de l'instance.

SETTINGS 
    allow_experimental_analyzer = 1,
    allow_experimental_parallel_reading_from_replicas = 1;

La concurrence maximale de requêtes par défaut 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 correspondant au paramètre max_concurrent_queries.

5. Saisissez la nouvelle valeur dans la boîte de dialogue, puis 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 ce type de cluster, vous devez créer une table distribuée. Effectuez les écritures et les requêtes sur cette table pour obtenir des résultats cohérents. Sinon, chaque requête risque d'atteindre un shard différent. Créer une table distribuée.

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

Causes fréquentes et solutions associées :

• Cause 1 : processus de création de table incorrect. Un cluster distribué ClickHouse ne possède pas de sémantique DDL distribuée native. Si vous utilisez une instruction create table dans un cluster ClickHouse auto-géré, l'instruction peut retourner un message de succès, mais la table n'est créée que sur le serveur actuellement connecté. Lorsque vous vous connectez à un autre serveur, la table reste invisible.

  Solution :

  1. Lors de la création d'une table, utilisez l'instruction create table <table_name> on cluster default. La clause on cluster default diffuse l'instruction à 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 utilisant le moteur de table distribuée au-dessus de la table test.

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

• Cause 2 : configuration incorrecte de la table ReplicatedMergeTree. Le moteur de table ReplicatedMergeTree est une version améliorée du moteur MergeTree offrant la synchronisation maître-réplica. Sur une instance à réplica unique, vous ne pouvez créer que des tables avec le moteur MergeTree. Sur une instance maître-réplica, vous devez créer des tables avec le moteur ReplicatedMergeTree.

  Solution : Lors de la création d'une table sur 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.

insert into <destination table> as select * from <Kafka external table>;

Symptôme

Un TTL a été correctement configuré pour une table, mais les données expirées qu'elle contient ne sont pas supprimées automatiquement. La configuration du TTL n'est donc pas effective.

Étapes de dépannage

1. Vérifiez si la configuration du TTL de la table est appropriée.

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

2. Vérifiez le paramètre materialize_ttl_after_modify.

   Ce paramètre détermine si une nouvelle règle TTL s'applique 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 ne s'applique qu'aux nouvelles données ; les données existantes ne sont alors pas affectées par le TTL.

   • Consultez la valeur du paramètre

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

   • Modifiez la valeur du paramètre

     Important

     Cette commande analyse toutes les données existantes et peut entraîner une charge importante sur les ressources. Utilisez-la avec prudence.

     ALTER TABLE $table_name MATERIALIZE TTL;

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

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

   • Vérifiez la valeur du paramètre ttl_only_drop_parts

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

   • Examinez 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 règles de partitionnement et de TTL ne sont pas alignées, certaines données risquent de ne pas être nettoyées rapidement. Les points suivants expliquent l'interaction entre ces deux types de règles.

     • Lorsque les règles sont alignées (par exemple, un partitionnement par jour associé à un TTL journalier), ClickHouse peut déterminer l'expiration à partir 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 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 n'est supprimée que lorsque 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 identifier et supprimer individuellement les lignes expirées. Cette stratégie consomme le plus de ressources.

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

   La suppression des données expirées s'effectue de manière asynchrone lors des fusions, et non en temps réel. Vous pouvez contrôler la fréquence des fusions à l'aide du 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. Pour une instance en ligne, la valeur par défaut est de 7 200 secondes (2 heures).

   • Modifiez le paramètre

     Si la valeur de merge_with_ttl_timeout est trop élevée, la fréquence de déclenchement des fusions TTL diminue, ce qui retarde le nettoyage des données expirées. Réduisez cette valeur pour augmenter la fréquence de nettoyage. Pour plus de détails, consultez Description du paramètre.

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

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

   • Interrogez l'activité actuelle des threads d'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 d'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 selon vos besoins métier (par exemple, de 2 à 4, ou de 4 à 8). Si cela ne résout pas le problème, augmentez 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. En revanche, augmenter le paramètre background_pool_size ne nécessite pas de redémarrage, mais le diminuer exige un redémarrage du cluster.

6. Vérifiez si le schéma de la table et la conception des partitions sont adapté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 optimal, nous recommandons d'aligner la granularité des partitions sur celle du TTL (par exemple, en définissant les deux sur un intervalle journalier). Pour plus de détails, consultez les Bonnes 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 de l'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 qui en découlent.

8. Examinez les autres paramètres système dans system.merge_tree_settings.

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

   • 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 avec TTL en cours dans le pool de threads d'arrière-plan dépasse cette valeur, ClickHouse ne planifie plus de nouvelles tâches de fusion avec TTL.

Le bon fonctionnement d'une primary key merge requiert les deux conditions préalables suivantes.

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

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

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

Voici les causes fréquentes et leurs solutions.

• Cause 1 : L'éviction des données TTL se produit lors de la phase de fusion des clés primaires. 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 :

  • Déclenchez manuellement une tâche de fusion en exécutant optimize final ou optimize a specific partition.

  • Lors de la création d'une table, définissez 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 :

  • Régénérez les informations TTL en exécutant alter table materialize ttl.

  • Mettez à 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 en cours de données dans celle-ci.

• 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 en cours d'écriture, la procédure varie selon le 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.

• Tentez d'interrompre la requête depuis la console.

• Cause 1 : Le client ClickHouse analyse la syntaxe. Or, 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 n'effectuant pas d'analyse syntaxique côté client, comme les outils basés sur JDBC (DataGrip, 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 de caractères non encadrée par des guillemets.

  Solution : Placez la valeur de la chaîne entre guillemets.

Si votre cluster est une édition Enterprise 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 à jour votre instance vers la dernière version. Mettre à jour les versions mineures du moteur.

Problème : Sur un cluster Community Edition multi-nœuds, vous pouvez 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 même 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. Cela consomme des ressources importantes et augmente la latence. Pour éviter cela, 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, puis diffusé à tous les autres nœuds pour compléter 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 jeux de données volumineux.

• 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 à la place sur l'instance actuelle.

  Par exemple, vous exécutez l'instruction suivante sur instance_a pour interroger des données depuis 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, appelons-la 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 de 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);. Cependant, l'ensemble de conditions défini dans la table temporaire A est généré 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 l'ensemble de conditions 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 l'ensemble de conditions depuis une source incorrecte, ce qui conduit à 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, changez cette instruction :

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

en :

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 consulter 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 fréquentes incluent :

• Une requête déclenchant une erreur OOM.

• Un redémarrage d'instance provoqué par un changement de configuration.

• Un redémarrage d'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 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 à 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'write operation s intensives. L'utilisation s'équilibre entre les node s une fois les données synchronisées.

• Description du problème :

  Comment consulter les journaux système détaillés pour résoudre des erreurs ou identifier des 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 texte 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é.

     Configurer les paramètres config.xml.

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

  3. Exécutez l'instruction suivante pour consulter 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 Set a Whitelist.

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

Si ces conditions ne sont pas remplies, établissez d'abord la connectivité au moyen d'une solution réseau adaptée. Ajoutez ensuite l'adresse IP de chaque entité dans la liste d'autorisation de l'autre.

Oui, vous pouvez migrer un cluster ClickHouse édition Community vers un cluster édition Enterprise.

La migration des données entre les clusters édition Enterprise et édition Community s'effectue via la fonction remote ou par exportation et importation de fichiers de données. Migrate data from a self-managed ClickHouse cluster to 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. Bien que plus performant, cet analyseur peut ne pas être rétrocompatible avec certaines instructions SQL héritées. En cas d'erreur d'analyse syntaxique, revenez à l'ancien analyseur. Learn more about the new analyzer.

SET allow_experimental_analyzer = 0;

La fonctionnalité de suspension est exclusivement disponible pour les clusters édition Enterprise. Les clusters ClickHouse édition Community ne peuvent pas être suspendus. Pour suspendre un cluster édition Enterprise, accédez à la page des clusters édition Enterprise. Sélectionnez la région cible dans le coin supérieur gauche. Dans la liste des clusters, localisez le cluster concerné, puis cliquez sur > Suspend dans la colonne Actions.

Description du problème

Les utilisateurs peu familiers avec ClickHouse créent parfois par erreur des tables utilisant le moteur MergeTree dans un cluster multi-réplicas. Cela empêche la synchronisation des données entre les nœuds réplicas de chaque shard. Par conséquent, les requêtes sur la table distribuée correspondante peuvent retourner des résultats incohérents. Pour résoudre ce problème, convertissez la table MergeTree en table ReplicatedMergeTree.

Solution

ClickHouse ne fournit aucune instruction DDL permettant de modifier directement le moteur de stockage d'une table. Pour convertir une table MergeTree en ReplicatedMergeTree, créez une nouvelle table avec le moteur ReplicatedMergeTree, puis importez-y les données de la table d'origine.

Prenons l'exemple d'une table MergeTree nommée table_src et de sa table distribuée associée table_dst_d dans un cluster multi-réplicas. Pour convertir cette table MergeTree en 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. Deux méthodes s'offrent à vous.

Définir un session_id unique garantit que le serveur ClickHouse maintient un contexte cohérent pour les requêtes partageant le même session ID. Cela permet d'exécuter plusieurs instructions SQL au sein d'une seule session. L'exemple ci-dessous illustre cette approche avec le ClickHouse Java Client (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 session ID 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 max_block_size fixé à 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 édition Enterprise ?

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

  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 édition Enterprise, chaque nœud dispose d'une limite CCU (maximum 32 CCU, 1 CCU équivalant approximativement à 1 vCore et 4 Gio de mémoire). Si une requête SQL consomme plus de mémoire que le seuil du nœud, MemoryTracker intercepte la requête. Le seuil par défaut correspond à 0,9 fois la mémoire totale du nœud. Exécutez l'instruction SQL suivante pour consulter ce 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 répartit la phase de lecture des données sur plusieurs nœuds, diluant ainsi la consommation mémoire. Enterprise Edition.

Pourquoi les résultats de requête sont-ils incohérents ?

Pourquoi ReplacingMergeTree échoue-t-il à dédupliquer après une fusion forcée ?

optimize TABLE <table_name> FINAL ON cluster default;