SYSTEM Statements
RELOAD EMBEDDED DICTIONARIES
Reload all Internal dictionaries.
By default, internal dictionaries are disabled.
Always returns Ok.
regardless of the result of the internal dictionary update.
RELOAD DICTIONARIES
Reloads all dictionaries that have been successfully loaded before.
By default, dictionaries are loaded lazily (see dictionaries_lazy_load), so instead of being loaded automatically at startup, they are initialized on first access through dictGet function or SELECT from tables with ENGINE = Dictionary. The SYSTEM RELOAD DICTIONARIES
query reloads such dictionaries (LOADED).
Always returns Ok.
regardless of the result of the dictionary update.
Syntax
RELOAD DICTIONARY
Completely reloads a dictionary dictionary_name
, regardless of the state of the dictionary (LOADED / NOT_LOADED / FAILED).
Always returns Ok.
regardless of the result of updating the dictionary.
The status of the dictionary can be checked by querying the system.dictionaries
table.
RELOAD MODELS
This statement and SYSTEM RELOAD MODEL
merely unload catboost models from the clickhouse-library-bridge. The function catboostEvaluate()
loads a model upon first access if it is not loaded yet.
Unloads all CatBoost models.
Syntax
RELOAD MODEL
Unloads a CatBoost model at model_path
.
Syntax
RELOAD FUNCTIONS
Reloads all registered executable user defined functions or one of them from a configuration file.
Syntax
RELOAD ASYNCHRONOUS METRICS
Re-calculates all asynchronous metrics. Since asynchronous metrics are periodically updated based on setting asynchronous_metrics_update_period_s, updating them manually using this statement is typically not necessary.
DROP DNS CACHE
Clears ClickHouse's internal DNS cache. Sometimes (for old ClickHouse versions) it is necessary to use this command when changing the infrastructure (changing the IP address of another ClickHouse server or the server used by dictionaries).
For more convenient (automatic) cache management, see disable_internal_dns_cache, dns_cache_max_entries, dns_cache_update_period parameters.
DROP MARK CACHE
Clears the mark cache.
DROP REPLICA
Dead replicas of ReplicatedMergeTree
tables can be dropped using following syntax:
Queries will remove the ReplicatedMergeTree
replica path in ZooKeeper. It is useful when the replica is dead and its metadata cannot be removed from ZooKeeper by DROP TABLE
because there is no such table anymore. It will only drop the inactive/stale replica, and it cannot drop local replica, please use DROP TABLE
for that. DROP REPLICA
does not drop any tables and does not remove any data or metadata from disk.
The first one removes metadata of 'replica_name'
replica of database.table
table.
The second one does the same for all replicated tables in the database.
The third one does the same for all replicated tables on the local server.
The fourth one is useful to remove metadata of dead replica when all other replicas of a table were dropped. It requires the table path to be specified explicitly. It must be the same path as was passed to the first argument of ReplicatedMergeTree
engine on table creation.
DROP DATABASE REPLICA
Dead replicas of Replicated
databases can be dropped using following syntax:
Similar to SYSTEM DROP REPLICA
, but removes the Replicated
database replica path from ZooKeeper when there's no database to run DROP DATABASE
. Please note that it does not remove ReplicatedMergeTree
replicas (so you may need SYSTEM DROP REPLICA
as well). Shard and replica names are the names that were specified in Replicated
engine arguments when creating the database. Also, these names can be obtained from database_shard_name
and database_replica_name
columns in system.clusters
. If the FROM SHARD
clause is missing, then replica_name
must be a full replica name in shard_name|replica_name
format.
DROP UNCOMPRESSED CACHE
Clears the uncompressed data cache.
The uncompressed data cache is enabled/disabled with the query/user/profile-level setting use_uncompressed_cache
.
Its size can be configured using the server-level setting uncompressed_cache_size
.
DROP COMPILED EXPRESSION CACHE
Clears the compiled expression cache.
The compiled expression cache is enabled/disabled with the query/user/profile-level setting compile_expressions
.
DROP QUERY CACHE
Clears the query cache. If a tag is specified, only query cache entries with the specified tag are deleted.
DROP FORMAT SCHEMA CACHE
Clears cache for schemas loaded from format_schema_path
.
Supported formats:
- Protobuf
FLUSH LOGS
Flushes buffered log messages to system tables, e.g. system.query_log. Mainly useful for debugging since most system tables have a default flush interval of 7.5 seconds. This will also create system tables even if message queue is empty.
RELOAD CONFIG
Reloads ClickHouse configuration. Used when configuration is stored in ZooKeeper. Note that SYSTEM RELOAD CONFIG
does not reload USER
configuration stored in ZooKeeper, it only reloads USER
configuration that is stored in users.xml
. To reload all USER
config use SYSTEM RELOAD USERS
RELOAD USERS
Reloads all access storages, including: users.xml, local disk access storage, replicated (in ZooKeeper) access storage.
SHUTDOWN
Normally shuts down ClickHouse (like service clickhouse-server stop
/ kill {$pid_clickhouse-server}
)
KILL
Aborts ClickHouse process (like kill -9 {$ pid_clickhouse-server}
)
Managing Distributed Tables
ClickHouse can manage distributed tables. When a user inserts data into these tables, ClickHouse first creates a queue of the data that should be sent to cluster nodes, then asynchronously sends it. You can manage queue processing with the STOP DISTRIBUTED SENDS
, FLUSH DISTRIBUTED, and START DISTRIBUTED SENDS
queries. You can also synchronously insert distributed data with the distributed_foreground_insert
setting.
STOP DISTRIBUTED SENDS
Disables background data distribution when inserting data into distributed tables.
In case of prefer_localhost_replica
is enabled (the default), the data to local shard will be inserted anyway.
FLUSH DISTRIBUTED
Forces ClickHouse to send data to cluster nodes synchronously. If any nodes are unavailable, ClickHouse throws an exception and stops query execution. You can retry the query until it succeeds, which will happen when all nodes are back online.
You can also override some settings via SETTINGS
clause, this can be useful to avoid some temporary limitations, like max_concurrent_queries_for_all_users
or max_memory_usage
.
Each pending block is stored in disk with settings from the initial INSERT query, so that is why sometimes you may want to override settings.
START DISTRIBUTED SENDS
Enables background data distribution when inserting data into distributed tables.
STOP LISTEN
Closes the socket and gracefully terminates the existing connections to the server on the specified port with the specified protocol.
However, if the corresponding protocol settings were not specified in the clickhouse-server configuration, this command will have no effect.
- If
CUSTOM 'protocol'
modifier is specified, the custom protocol with the specified name defined in the protocols section of the server configuration will be stopped. - If
QUERIES ALL [EXCEPT .. [,..]]
modifier is specified, all protocols are stopped, unless specified withEXCEPT
clause. - If
QUERIES DEFAULT [EXCEPT .. [,..]]
modifier is specified, all default protocols are stopped, unless specified withEXCEPT
clause. - If
QUERIES CUSTOM [EXCEPT .. [,..]]
modifier is specified, all custom protocols are stopped, unless specified withEXCEPT
clause.
START LISTEN
Allows new connections to be established on the specified protocols.
However, if the server on the specified port and protocol was not stopped using the SYSTEM STOP LISTEN command, this command will have no effect.
Managing MergeTree Tables
ClickHouse can manage background processes in MergeTree tables.
STOP MERGES
Provides possibility to stop background merges for tables in the MergeTree family:
DETACH / ATTACH
table will start background merges for the table even in case when merges have been stopped for all MergeTree tables before.
START MERGES
Provides possibility to start background merges for tables in the MergeTree family:
STOP TTL MERGES
Provides possibility to stop background delete old data according to TTL expression for tables in the MergeTree family:
Returns Ok.
even if table does not exist or table has not MergeTree engine. Returns error when database does not exist:
START TTL MERGES
Provides possibility to start background delete old data according to TTL expression for tables in the MergeTree family:
Returns Ok.
even if table does not exist. Returns error when database does not exist:
STOP MOVES
Provides possibility to stop background move data according to TTL table expression with TO VOLUME or TO DISK clause for tables in the MergeTree family:
Returns Ok.
even if table does not exist. Returns error when database does not exist:
START MOVES
Provides possibility to start background move data according to TTL table expression with TO VOLUME and TO DISK clause for tables in the MergeTree family:
Returns Ok.
even if table does not exist. Returns error when database does not exist:
SYSTEM UNFREEZE
Clears freezed backup with the specified name from all the disks. See more about unfreezing separate parts in ALTER TABLE table_name UNFREEZE WITH NAME
WAIT LOADING PARTS
Wait until all asynchronously loading data parts of a table (outdated data parts) will became loaded.
Managing ReplicatedMergeTree Tables
ClickHouse can manage background replication related processes in ReplicatedMergeTree tables.
STOP FETCHES
Provides possibility to stop background fetches for inserted parts for tables in the ReplicatedMergeTree
family:
Always returns Ok.
regardless of the table engine and even if table or database does not exist.
START FETCHES
Provides possibility to start background fetches for inserted parts for tables in the ReplicatedMergeTree
family:
Always returns Ok.
regardless of the table engine and even if table or database does not exist.
STOP REPLICATED SENDS
Provides possibility to stop background sends to other replicas in cluster for new inserted parts for tables in the ReplicatedMergeTree
family:
START REPLICATED SENDS
Provides possibility to start background sends to other replicas in cluster for new inserted parts for tables in the ReplicatedMergeTree
family:
STOP REPLICATION QUEUES
Provides possibility to stop background fetch tasks from replication queues which stored in Zookeeper for tables in the ReplicatedMergeTree
family. Possible background tasks types - merges, fetches, mutation, DDL statements with ON CLUSTER clause:
START REPLICATION QUEUES
Provides possibility to start background fetch tasks from replication queues which stored in Zookeeper for tables in the ReplicatedMergeTree
family. Possible background tasks types - merges, fetches, mutation, DDL statements with ON CLUSTER clause:
STOP PULLING REPLICATION LOG
Stops loading new entries from replication log to replication queue in a ReplicatedMergeTree
table.
START PULLING REPLICATION LOG
Cancels SYSTEM STOP PULLING REPLICATION LOG
.
SYNC REPLICA
Wait until a ReplicatedMergeTree
table will be synced with other replicas in a cluster, but no more than receive_timeout
seconds.
After running this statement the [db.]replicated_merge_tree_family_table_name
fetches commands from the common replicated log into its own replication queue, and then the query waits till the replica processes all of the fetched commands. The following modifiers are supported:
- If a
STRICT
modifier was specified then the query waits for the replication queue to become empty. TheSTRICT
version may never succeed if new entries constantly appear in the replication queue. - If a
LIGHTWEIGHT
modifier was specified then the query waits only forGET_PART
,ATTACH_PART
,DROP_RANGE
,REPLACE_RANGE
andDROP_PART
entries to be processed. Additionally, the LIGHTWEIGHT modifier supports an optional FROM 'srcReplicas' clause, where 'srcReplicas' is a comma-separated list of source replica names. This extension allows for more targeted synchronization by focusing only on replication tasks originating from the specified source replicas. - If a
PULL
modifier was specified then the query pulls new replication queue entries from ZooKeeper, but does not wait for anything to be processed.
SYNC DATABASE REPLICA
Waits until the specified replicated database applies all schema changes from the DDL queue of that database.
Syntax
RESTART REPLICA
Provides possibility to reinitialize Zookeeper session's state for ReplicatedMergeTree
table, will compare current state with Zookeeper as source of truth and add tasks to Zookeeper queue if needed.
Initialization of replication queue based on ZooKeeper data happens in the same way as for ATTACH TABLE
statement. For a short time, the table will be unavailable for any operations.
RESTORE REPLICA
Restores a replica if data is [possibly] present but Zookeeper metadata is lost.
Works only on readonly ReplicatedMergeTree
tables.
One may execute query after:
- ZooKeeper root
/
loss. - Replicas path
/replicas
loss. - Individual replica path
/replicas/replica_name/
loss.
Replica attaches locally found parts and sends info about them to Zookeeper. Parts present on a replica before metadata loss are not re-fetched from other ones if not being outdated (so replica restoration does not mean re-downloading all data over the network).
Parts in all states are moved to detached/
folder. Parts active before data loss (committed) are attached.
Syntax
Alternative syntax:
Example
Creating a table on multiple servers. After the replica's metadata in ZooKeeper is lost, the table will attach as read-only as metadata is missing. The last query needs to execute on every replica.
Another way:
RESTART REPLICAS
Provides possibility to reinitialize Zookeeper sessions state for all ReplicatedMergeTree
tables, will compare current state with Zookeeper as source of true and add tasks to Zookeeper queue if needed
DROP FILESYSTEM CACHE
Allows to drop filesystem cache.
SYNC FILE CACHE
It's too heavy and has potential for misuse.
Will do sync syscall.
LOAD PRIMARY KEY
Load the primary keys for the given table or for all tables.
UNLOAD PRIMARY KEY
Unload the primary keys for the given table or for all tables.
Managing Refreshable Materialized Views
Commands to control background tasks performed by Refreshable Materialized Views
Keep an eye on system.view_refreshes
while using them.
REFRESH VIEW
Trigger an immediate out-of-schedule refresh of a given view.
REFRESH VIEW
Wait for the currently running refresh to complete. If the refresh fails, throws an exception. If no refresh is running, completes immediately, throwing an exception if previous refresh failed.
STOP VIEW, STOP VIEWS
Disable periodic refreshing of the given view or all refreshable views. If a refresh is in progress, cancel it too.
START VIEW, START VIEWS
Enable periodic refreshing for the given view or all refreshable views. No immediate refresh is triggered.
CANCEL VIEW
If there's a refresh in progress for the given view, interrupt and cancel it. Otherwise do nothing.
SYSTEM WAIT VIEW
Waits for the running refresh to complete. If no refresh is running, returns immediately. If the latest refresh attempt failed, reports an error.
Can be used right after creating a new refreshable materialized view (without EMPTY keyword) to wait for the initial refresh to complete.