SYSTEM RELOAD EMBEDDED DICTIONARIES
Ok., quel que soit le résultat de la mise à jour des dictionnaires internes.
SYSTEM RELOAD DICTIONARIES
SYSTEM RELOAD DICTIONARIES recharge les dictionnaires dont le statut est LOADED (voir la colonne status de system.dictionaries), c’est-à-dire les dictionnaires qui ont déjà été chargés avec succès.
Par défaut, les dictionnaires sont chargés de manière différée (voir dictionaries_lazy_load) ; ainsi, au lieu d’être chargés automatiquement au démarrage, ils sont initialisés lors du premier accès, via la fonction dictGet ou une instruction SELECT sur des tables avec ENGINE = Dictionary.
Syntaxe
SYSTEM RELOAD DICTIONARIES [ON CLUSTER cluster_name]
dictionary_name, quel que soit son état (LOADED / NOT_LOADED / FAILED).
Renvoie toujours Ok., quel que soit le résultat de la mise à jour du dictionnaire.
SYSTEM RELOAD DICTIONARY [ON CLUSTER cluster_name] dictionary_name
system.dictionaries.
SELECT name, status FROM system.dictionaries;
Cette instruction et SYSTEM RELOAD MODEL se contentent de décharger les modèles CatBoost de clickhouse-library-bridge. La fonction catboostEvaluate()
charge un modèle lors du premier accès s’il n’est pas encore chargé.
SYSTEM RELOAD MODELS [ON CLUSTER cluster_name]
model_path.
Syntaxe
SYSTEM RELOAD MODEL [ON CLUSTER cluster_name] <model_path>
SYSTEM RELOAD FUNCTIONS [ON CLUSTER cluster_name]
SYSTEM RELOAD FUNCTION [ON CLUSTER cluster_name] function_name
SYSTEM RELOAD ASYNCHRONOUS METRICS
SYSTEM RELOAD ASYNCHRONOUS METRICS [ON CLUSTER cluster_name]
SYSTEM CLEAR|DROP DNS CACHE
disable_internal_dns_cache, dns_cache_max_entries, dns_cache_update_period.
SYSTEM CLEAR|DROP MARK CACHE
SYSTEM CLEAR|DROP AVRO SCHEMA CACHE
AvroConfluent. Cette opération supprime à la fois le cache de récupération des schémas (id → schéma) et le cache d’enregistrement des schémas (subject + schéma → id), de sorte que les lectures et écritures suivantes repassent par le serveur du registre. Utile lorsqu’un schéma a été supprimé ou réécrit côté registre, ou pour vérifier l’idempotence du registre dans les tests.
Efface le cache de métadonnées Parquet.
SYSTEM CLEAR|DROP TEXT INDEX CACHES
SYSTEM CLEAR TEXT INDEX HEADER CACHE,SYSTEM CLEAR TEXT INDEX DICTIONARY CACHE, ouSYSTEM CLEAR TEXT INDEX POSTINGS CACHE
Les répliques inactives des tables ReplicatedMergeTree peuvent être supprimées à l’aide de la syntaxe suivante :
SYSTEM DROP REPLICA 'replica_name' FROM TABLE database.table;
SYSTEM DROP REPLICA 'replica_name' FROM DATABASE database;
SYSTEM DROP REPLICA 'replica_name';
SYSTEM DROP REPLICA 'replica_name' FROM ZKPATH '/path/to/table/in/zk';
ReplicatedMergeTree dans ZooKeeper. Cela est utile lorsque la réplique est hors service et que ses métadonnées ne peuvent plus être supprimées de ZooKeeper via DROP TABLE, car la table n’existe plus. Seule la réplique inactive/obsolète sera supprimée ; la réplique locale ne peut pas l’être. Pour cela, utilisez DROP TABLE. DROP REPLICA ne supprime aucune table et n’efface ni données ni métadonnées sur le disque.
La première supprime les métadonnées de la réplique 'replica_name' de la table database.table.
La deuxième fait de même pour toutes les tables répliquées de la base de données.
La troisième fait de même pour toutes les tables répliquées sur le serveur local.
La quatrième est utile pour supprimer les métadonnées d’une réplique hors service lorsque toutes les autres répliques d’une table ont été supprimées. Elle nécessite que le chemin de la table soit spécifié explicitement. Il doit s’agir du même chemin que celui passé comme premier argument du moteur ReplicatedMergeTree lors de la création de la table.
SYSTEM DROP DATABASE REPLICA
Replicated peuvent être supprimées à l’aide de la syntaxe suivante :
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'] FROM DATABASE database;
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'];
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'] FROM ZKPATH '/path/to/table/in/zk';
SYSTEM DROP REPLICA, mais supprime le chemin de la réplique de la base de données Replicated dans ZooKeeper lorsqu’il n’existe aucune base de données sur laquelle exécuter DROP DATABASE. Veuillez noter que cela ne supprime pas les répliques ReplicatedMergeTree (vous pouvez donc aussi avoir besoin de SYSTEM DROP REPLICA). Les noms du shard et de la réplique sont ceux qui ont été spécifiés dans les arguments du moteur Replicated lors de la création de la base de données. En outre, ces noms peuvent être récupérés à partir des colonnes database_shard_name et database_replica_name de system.clusters. Si la clause FROM SHARD est absente, replica_name doit alors être un nom de réplique complet au format shard_name|replica_name.
SYSTEM CLEAR|DROP UNCOMPRESSED CACHE
use_uncompressed_cache au niveau de la requête, de l’utilisateur ou du profil.
Sa taille peut être configurée à l’aide du paramètre uncompressed_cache_size au niveau du serveur.
SYSTEM CLEAR|DROP COMPILED EXPRESSION CACHE
compile_expressions, défini au niveau de la requête, de l’utilisateur ou du profil.
SYSTEM CLEAR|DROP QUERY CONDITION CACHE
SYSTEM CLEAR|DROP CACHE DE REQUÊTES
SYSTEM CLEAR QUERY CACHE;
SYSTEM CLEAR QUERY CACHE TAG '<tag>'
format_schema_path.
Cibles prises en charge :
- Protobuf : supprime de la mémoire les définitions de messages Protobuf importées.
- Fichiers : supprime les fichiers de schéma mis en cache et stockés localement dans
format_schema_path, générés lorsque format_schema_source est défini sur query.
Remarque : si aucune cible n’est spécifiée, les deux caches sont vidés.
SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE [FOR Protobuf/Files]
system.query_log. Cette commande est surtout utile pour le débogage, car la plupart des tables système ont un intervalle de vidage par défaut de 7,5 secondes.
Elle crée également les tables système, même si la file d’attente des messages est vide.
SYSTEM FLUSH LOGS [ON CLUSTER cluster_name] [log_name|[database.table]] [, ...]
SYSTEM FLUSH LOGS query_log, system.query_views_log;
SYSTEM RELOAD CONFIG ne recharge pas la configuration USER stockée dans ZooKeeper ; il recharge uniquement la configuration USER stockée dans users.xml. Pour recharger l’ensemble de la configuration USER, utilisez SYSTEM RELOAD USERS
SYSTEM RELOAD CONFIG [ON CLUSTER cluster_name]
SYSTEM RELOAD USERS [ON CLUSTER cluster_name]
service clickhouse-server stop / kill {$pid_clickhouse-server})
Met fin au processus ClickHouse (comme kill -9 {$ pid_clickhouse-server})
Gère les points d’instrumentation à l’aide de la fonctionnalité XRay de LLVM, disponible lorsque ClickHouse est compilé avec ENABLE_XRAY=1.
Cela permet de déboguer et de profiler en production sans modifier le code source, avec une surcharge minimale.
Lorsqu’aucun point d’instrumentation n’est ajouté, la pénalité de performance est négligeable, car cela ajoute seulement un saut supplémentaire vers une adresse proche
au prologue et à l’épilogue des fonctions de plus de 200 instructions.
Ajoute un nouveau point d’instrumentation. Les fonctions instrumentées peuvent être examinées dans la table système system.instrumentation. Plusieurs handlers peuvent être ajoutés à une même fonction, et ils seront exécutés dans le même ordre que celui dans lequel l’instrumentation a été ajoutée.
Les fonctions à instrumenter peuvent être répertoriées à partir de la table système system.symbols.
Il existe trois types différents de handlers à ajouter aux fonctions :
Syntax
SYSTEM INSTRUMENT ADD FUNCTION HANDLER [ARGUMENTS]
FUNCTION désigne n’importe quelle fonction ou sous-chaîne d’une fonction, telle que QueryMetricLog::startQuery, et où le gestionnaire est l’un des suivants
Affiche le texte passé en argument ainsi que la stack trace, soit à l’ENTRY, soit à l’EXIT de la fonction.
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' LOG ENTRY 'this is a log printed at entry'
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' LOG EXIT 'this is a log printed at exit'
ENTRY, soit sur EXIT :
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' SLEEP ENTRY 0.5
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' SLEEP ENTRY 0 1
ENTRY et EXIT d’une fonction.
Le résultat du profilage est stocké dans system.trace_log et peut être converti
en format de trace d’événements Chrome.
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' PROFILE
SYSTEM INSTRUMENT REMOVE ID
ALL :
SYSTEM INSTRUMENT REMOVE ALL
SYSTEM INSTRUMENT REMOVE (SELECT id FROM system.instrumentation WHERE handler = 'log')
SYSTEM INSTRUMENT REMOVE 'QueryMetricLog::startQuery'
system.instrumentation.
Gestion des tables Distributed
STOP DISTRIBUTED SENDS, FLUSH DISTRIBUTED et START DISTRIBUTED SENDS. Vous pouvez également insérer des données distribuées de manière synchrone avec le paramètre distributed_foreground_insert.
SYSTEM STOP DISTRIBUTED SENDS
SYSTEM STOP DISTRIBUTED SENDS [db.]<distributed_table_name> [ON CLUSTER cluster_name]
Si prefer_localhost_replica est activé (valeur par défaut), les données seront malgré tout insérées dans le shard local. SETTINGS ; cela peut être utile pour contourner certaines limitations temporaires, comme max_concurrent_queries_for_all_users ou max_memory_usage.
SYSTEM FLUSH DISTRIBUTED [db.]<distributed_table_name> [ON CLUSTER cluster_name] [SETTINGS ...]
Chaque bloc en attente est stocké sur le disque avec les paramètres de la requête INSERT initiale ; il peut donc parfois être utile de remplacer ces paramètres.
SYSTEM START DISTRIBUTED SENDS
SYSTEM START DISTRIBUTED SENDS [db.]<distributed_table_name> [ON CLUSTER cluster_name]
SYSTEM STOP LISTEN [ON CLUSTER cluster_name] [QUERIES ALL | QUERIES DEFAULT | QUERIES CUSTOM | TCP | TCP WITH PROXY | TCP SECURE | HTTP | HTTPS | MYSQL | GRPC | POSTGRESQL | PROMETHEUS | CUSTOM 'protocol']
- Si le modificateur
CUSTOM 'protocol' est spécifié, le protocole personnalisé portant le nom indiqué, défini dans la section des protocoles de la configuration du serveur, sera arrêté.
- Si le modificateur
QUERIES ALL [EXCEPT .. [,..]] est spécifié, tous les protocoles seront arrêtés, sauf ceux indiqués dans la clause EXCEPT.
- Si le modificateur
QUERIES DEFAULT [EXCEPT .. [,..]] est spécifié, tous les protocoles par défaut seront arrêtés, sauf ceux indiqués dans la clause EXCEPT.
- Si le modificateur
QUERIES CUSTOM [EXCEPT .. [,..]] est spécifié, tous les protocoles personnalisés seront arrêtés, sauf ceux indiqués dans la clause EXCEPT.
Permet d’établir de nouvelles connexions sur les protocoles spécifiés.
Cependant, si le serveur sur le port et avec le protocole spécifiés n’a pas été arrêté à l’aide de la commande SYSTEM STOP LISTEN, cette commande sera sans effet.
SYSTEM START LISTEN [ON CLUSTER cluster_name] [QUERIES ALL | QUERIES DEFAULT | QUERIES CUSTOM | TCP | TCP WITH PROXY | TCP SECURE | HTTP | HTTPS | MYSQL | GRPC | POSTGRESQL | PROMETHEUS | CUSTOM 'protocol']
Gestion des tables MergeTree
SYSTEM STOP MERGES [ON CLUSTER cluster_name] [ON VOLUME <volume_name> | [db.]merge_tree_family_table_name]
Un DETACH / ATTACH d’une table redémarre les fusions en arrière-plan de cette table, même si elles ont auparavant été arrêtées pour toutes les tables MergeTree.
SYSTEM START MERGES [ON CLUSTER cluster_name] [ON VOLUME <volume_name> | [db.]merge_tree_family_table_name]
Ok. même si la table n’existe pas ou n’utilise pas le moteur MergeTree. Renvoie une erreur lorsque la base de données n’existe pas :
SYSTEM STOP TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
Ok. même si la table n’existe pas. Renvoie une erreur lorsque la base de données n’existe pas :
SYSTEM START TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
Ok. même si la table n’existe pas. Renvoie une erreur lorsque la base de données n’existe pas :
SYSTEM STOP MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
Ok. même si la table n’existe pas. Renvoie une erreur lorsque la base de données n’existe pas :
SYSTEM START MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
SYSTEM UNFREEZE WITH NAME <backup_name>
SYSTEM WAIT LOADING PARTS
SYSTEM WAIT LOADING PARTS [ON CLUSTER cluster_name] [db.]merge_tree_family_table_name
Gestion des tables ReplicatedMergeTree
ReplicatedMergeTree :
Renvoie toujours Ok., quel que soit le moteur de table, même si la table ou la base de données n’existe pas.
SYSTEM STOP FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
ReplicatedMergeTree :
Renvoie toujours Ok., quel que soit le moteur de table, même si la table ou la base de données n’existe pas.
SYSTEM START FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
SYSTEM STOP REPLICATED SENDS
ReplicatedMergeTree :
SYSTEM STOP REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
SYSTEM START REPLICATED SENDS
ReplicatedMergeTree :
SYSTEM START REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
SYSTEM STOP REPLICATION QUEUES
ReplicatedMergeTree. Types possibles de tâches en arrière-plan - fusions, récupérations, mutations, instructions DDL avec la clause ON CLUSTER :
SYSTEM STOP REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
SYSTEM START REPLICATION QUEUES
ReplicatedMergeTree. Types possibles de tâches en arrière-plan : fusions, récupérations, mutations, instructions DDL avec la clause ON CLUSTER :
SYSTEM START REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
SYSTEM STOP PULLING REPLICATION LOG
ReplicatedMergeTree.
SYSTEM STOP PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
SYSTEM START PULLING REPLICATION LOG
SYSTEM STOP PULLING REPLICATION LOG.
SYSTEM START PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
ReplicatedMergeTree soit synchronisée avec les autres répliques d’un cluster, sans dépasser receive_timeout secondes.
SYSTEM SYNC REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name [IF EXISTS] [STRICT | LIGHTWEIGHT [FROM 'srcReplica1'[, 'srcReplica2'[, ...]]] | PULL]
[db.]replicated_merge_tree_family_table_name récupère les commandes du journal répliqué commun dans sa propre file de réplication, puis la requête attend que la réplique traite toutes les commandes récupérées. Les modificateurs suivants sont pris en charge :
- Avec
IF EXISTS (disponible à partir de la version 25.6), la requête ne renverra pas d’erreur si la table n’existe pas. Cela est utile lors de l’ajout d’une nouvelle réplique à un cluster, lorsqu’elle fait déjà partie de la configuration du cluster mais qu’elle est encore en cours de création et de synchronisation de la table.
- Si un modificateur
STRICT a été spécifié, la requête attend que la file de réplication soit vide. La version STRICT peut ne jamais aboutir si de nouvelles entrées apparaissent constamment dans la file de réplication.
- Si un modificateur
LIGHTWEIGHT a été spécifié, la requête attend uniquement que les entrées GET_PART, ATTACH_PART, DROP_RANGE, REPLACE_RANGE et DROP_PART soient traitées.
De plus, le modificateur LIGHTWEIGHT prend en charge une clause facultative FROM 'srcReplicas', où ‘srcReplicas’ est une liste de noms de répliques sources séparés par des virgules. Cette extension permet une synchronisation plus ciblée en se concentrant uniquement sur les tâches de réplication provenant des répliques sources spécifiées.
- Si un modificateur
PULL a été spécifié, la requête récupère de nouvelles entrées de la file de réplication depuis ZooKeeper, mais n’attend pas leur traitement.
SYNCHRONISER LA RÉPLIQUE DE LA BASE DE DONNÉES
SYSTEM SYNC DATABASE REPLICA replicated_database_name;
ReplicatedMergeTree, de comparer l’état actuel à celui de ZooKeeper, qui sert de source de référence, et d’ajouter des tâches à la file d’attente ZooKeeper si nécessaire.
L’initialisation de la file d’attente de réplication à partir des données ZooKeeper s’effectue de la même manière que pour l’instruction ATTACH TABLE. Pendant une courte période, la table sera indisponible pour toute opération.
SYSTEM RESTART REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name
ReplicatedMergeTree en mode readonly.
Cette requête peut être exécutée après :
- la perte de la racine ZooKeeper
/ ;
- la perte du chemin des répliques
/replicas ;
- la perte du chemin d’une réplique individuelle
/replicas/replica_name/.
La réplique attache les parts trouvées localement et envoie à ZooKeeper des informations à leur sujet.
Les parts présentes sur une réplique avant la perte des métadonnées ne sont pas récupérées de nouveau depuis d’autres répliques si elles ne sont pas obsolètes (la restauration d’une réplique ne signifie donc pas le retéléchargement de toutes les données sur le réseau).
Les parts dans tous les états sont déplacées vers le dossier detached/. Les parts actives avant la perte des données (committed) sont attachées.
SYSTEM RESTORE DATABASE REPLICA
SYSTEM RESTORE DATABASE REPLICA repl_db [ON CLUSTER cluster]
CREATE DATABASE repl_db
ENGINE=Replicated("/clickhouse/repl_db", shard1, replica1);
CREATE TABLE repl_db.test_table (n UInt32)
ENGINE = ReplicatedMergeTree
ORDER BY n PARTITION BY n % 10;
-- zookeeper_delete_path("/clickhouse/repl_db", recursive=True) <- root loss.
SYSTEM RESTORE DATABASE REPLICA repl_db;
SYSTEM RESTORE REPLICA [db.]replicated_merge_tree_family_table_name [ON CLUSTER cluster_name]
SYSTEM RESTORE REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name
CREATE TABLE test(n UInt32)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/test/', '{replica}')
ORDER BY n PARTITION BY n % 10;
INSERT INTO test SELECT * FROM numbers(1000);
-- zookeeper_delete_path("/clickhouse/tables/test", recursive=True) <- root loss.
SYSTEM RESTART REPLICA test;
SYSTEM RESTORE REPLICA test;
SYSTEM RESTORE REPLICA test ON CLUSTER cluster;
ReplicatedMergeTree, de comparer l’état actuel avec celui de Zookeeper, considéré comme source de vérité, et d’ajouter des tâches à la file d’attente de Zookeeper si nécessaire
SYSTEM CLEAR|DROP FILESYSTEM CACHE
SYSTEM CLEAR FILESYSTEM CACHE [ON CLUSTER cluster_name]
Cette opération est trop lourde et peut faire l’objet d’une mauvaise utilisation.
SYSTEM SYNC FILE CACHE [ON CLUSTER cluster_name]
SYSTEM LOAD PRIMARY KEY [db.]name
SYSTEM UNLOAD PRIMARY KEY
SYSTEM UNLOAD PRIMARY KEY [db.]name
SYSTEM UNLOAD PRIMARY KEY
Gestion des vues matérialisées avec rafraîchissement
system.view_refreshes lors de leur utilisation.
SYSTEM STOP [REPLICATED] VIEW, STOP VIEWS
STOP VIEW n’affecte que la réplique courante, tandis que STOP REPLICATED VIEW affecte toutes les répliques.
L’état d’arrêt n’est pas conservé après un redémarrage du serveur. Après redémarrage, les vues reprennent leur planification d’actualisation configurée.
Dans les bases de données Replicated ou Shared, SYSTEM STOP VIEW n’affecte que la réplique courante. Utilisez SYSTEM STOP REPLICATED VIEW pour arrêter les actualisations sur toutes les répliques.
SYSTEM STOP VIEW [db.]name
SYSTEM START [REPLICATED] VIEW, START VIEWS
START VIEW annule l’effet de STOP VIEW, et START REPLICATED VIEW annule l’effet de STOP REPLICATED VIEW. START VIEW annule également l’effet de PAUSE VIEW.
SYSTEM START VIEW [db.]name
SYSTEM PAUSE VIEW, PAUSE VIEWS
SYSTEM STOP VIEW, SYSTEM PAUSE VIEW n’interrompt pas un rafraîchissement déjà en cours : le rafraîchissement en cours peut aller à son terme, et seules les rafraîchissements suivantes sont empêchées.
Pour annuler, utilisez SYSTEM START VIEW ou SYSTEM START VIEWS.
L’état en pause ne persiste pas après un redémarrage du serveur. Après le redémarrage, les vues reprendront leur planification de rafraîchissement configurée.
Dans les bases de données Replicated ou Shared, SYSTEM PAUSE VIEW n’affecte que la réplique actuelle.
SYSTEM PAUSE VIEW [db.]name
SYSTEM REFRESH VIEW [db.]name
SYSTEM WAIT VIEW [db.]name
SYSTEM CANCEL VIEW [db.]name
SYSTEM FLUSH OBJECT STORAGE QUEUE
SYSTEM FLUSH OBJECT STORAGE QUEUE [db.]table_name PATH 'path'
