2020-04-03 13:23:32 +00:00
---
toc_priority: 37
toc_title: SYSTEM
---
2020-03-21 04:11:51 +00:00
# SYSTEM Queries {#query-language-system}
- [RELOAD DICTIONARIES ](#query_language-system-reload-dictionaries )
- [RELOAD DICTIONARY ](#query_language-system-reload-dictionary )
- [DROP DNS CACHE ](#query_language-system-drop-dns-cache )
- [DROP MARK CACHE ](#query_language-system-drop-mark-cache )
- [FLUSH LOGS ](#query_language-system-flush_logs )
- [RELOAD CONFIG ](#query_language-system-reload-config )
- [SHUTDOWN ](#query_language-system-shutdown )
- [KILL ](#query_language-system-kill )
- [STOP DISTRIBUTED SENDS ](#query_language-system-stop-distributed-sends )
- [FLUSH DISTRIBUTED ](#query_language-system-flush-distributed )
- [START DISTRIBUTED SENDS ](#query_language-system-start-distributed-sends )
- [STOP MERGES ](#query_language-system-stop-merges )
- [START MERGES ](#query_language-system-start-merges )
2020-03-22 09:14:59 +00:00
## RELOAD DICTIONARIES {#query_language-system-reload-dictionaries}
2019-09-06 20:54:37 +00:00
2019-09-09 18:34:48 +00:00
Reloads all dictionaries that have been successfully loaded before.
2020-04-03 13:23:32 +00:00
By default, dictionaries are loaded lazily (see [dictionaries\_lazy\_load ](../../operations/server_configuration_parameters/settings.md#server_configuration_parameters-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).
2019-09-06 20:54:37 +00:00
Always returns `Ok.` regardless of the result of the dictionary update.
2020-04-03 13:23:32 +00:00
## RELOAD DICTIONARY Dictionary\_name {#query_language-system-reload-dictionary}
2019-09-06 20:54:37 +00:00
2020-03-20 10:10:48 +00:00
Completely reloads a dictionary `dictionary_name` , regardless of the state of the dictionary (LOADED / NOT\_LOADED / FAILED).
2019-09-06 20:54:37 +00:00
Always returns `Ok.` regardless of the result of updating the dictionary.
2019-09-06 23:09:02 +00:00
The status of the dictionary can be checked by querying the `system.dictionaries` table.
2019-09-06 20:54:37 +00:00
2020-03-20 10:10:48 +00:00
``` sql
2019-09-06 23:08:42 +00:00
SELECT name, status FROM system.dictionaries;
2019-09-06 20:54:37 +00:00
```
2020-03-22 09:14:59 +00:00
## DROP DNS CACHE {#query_language-system-drop-dns-cache}
2019-09-06 20:54:37 +00:00
2020-03-20 10:10:48 +00:00
Resets 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).
2019-09-06 20:54:37 +00:00
2020-03-20 10:10:48 +00:00
For more convenient (automatic) cache management, see disable\_internal\_dns\_cache, dns\_cache\_update\_period parameters.
2019-09-06 20:54:37 +00:00
2020-03-22 09:14:59 +00:00
## DROP MARK CACHE {#query_language-system-drop-mark-cache}
2019-09-06 20:54:37 +00:00
Resets the mark cache. Used in development of ClickHouse and performance tests.
2020-03-22 09:14:59 +00:00
## FLUSH LOGS {#query_language-system-flush_logs}
2019-09-06 20:54:37 +00:00
2020-03-20 10:10:48 +00:00
Flushes buffers of log messages to system tables (e.g. system.query\_log). Allows you to not wait 7.5 seconds when debugging.
2019-09-06 20:54:37 +00:00
2020-03-22 09:14:59 +00:00
## RELOAD CONFIG {#query_language-system-reload-config}
2019-09-06 20:54:37 +00:00
2019-09-06 23:11:10 +00:00
Reloads ClickHouse configuration. Used when configuration is stored in ZooKeeeper.
2019-09-06 20:54:37 +00:00
2020-03-22 09:14:59 +00:00
## SHUTDOWN {#query_language-system-shutdown}
2019-09-06 20:54:37 +00:00
Normally shuts down ClickHouse (like `service clickhouse-server stop` / `kill {$pid_clickhouse-server}` )
2020-03-22 09:14:59 +00:00
## KILL {#query_language-system-kill}
2019-09-06 20:54:37 +00:00
Aborts ClickHouse process (like `kill -9 {$ pid_clickhouse-server}` )
2019-08-14 07:58:30 +00:00
2020-03-21 04:11:51 +00:00
## Managing Distributed Tables {#query-language-system-distributed}
2019-07-10 07:04:53 +00:00
2020-04-03 13:23:32 +00:00
ClickHouse can manage [distributed ](../../engines/table_engines/special/distributed.md ) 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 ](#query_language-system-stop-distributed-sends ), [FLUSH DISTRIBUTED ](#query_language-system-flush-distributed ), and [START DISTRIBUTED SENDS ](#query_language-system-start-distributed-sends ) queries. You can also synchronously insert distributed data with the `insert_distributed_sync` setting.
2019-07-10 07:04:53 +00:00
2020-03-22 09:14:59 +00:00
### STOP DISTRIBUTED SENDS {#query_language-system-stop-distributed-sends}
2019-07-10 07:04:53 +00:00
2019-08-14 07:58:30 +00:00
Disables background data distribution when inserting data into distributed tables.
2019-07-10 07:04:53 +00:00
2020-03-20 10:10:48 +00:00
``` sql
2019-07-10 07:04:53 +00:00
SYSTEM STOP DISTRIBUTED SENDS [db.]< distributed_table_name >
```
2020-03-22 09:14:59 +00:00
### FLUSH DISTRIBUTED {#query_language-system-flush-distributed}
2019-07-10 07:04:53 +00:00
2019-08-14 07:58:30 +00:00
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.
2019-07-10 07:04:53 +00:00
2020-03-20 10:10:48 +00:00
``` sql
2019-07-10 07:04:53 +00:00
SYSTEM FLUSH DISTRIBUTED [db.]< distributed_table_name >
```
2020-03-22 09:14:59 +00:00
### START DISTRIBUTED SENDS {#query_language-system-start-distributed-sends}
2019-07-10 07:04:53 +00:00
2019-08-14 07:58:30 +00:00
Enables background data distribution when inserting data into distributed tables.
2019-07-10 07:04:53 +00:00
2020-03-20 10:10:48 +00:00
``` sql
2019-07-10 07:04:53 +00:00
SYSTEM START DISTRIBUTED SENDS [db.]< distributed_table_name >
```
2019-08-14 07:58:30 +00:00
2020-03-22 09:14:59 +00:00
### STOP MERGES {#query_language-system-stop-merges}
2019-11-01 08:45:09 +00:00
2019-11-01 14:17:49 +00:00
Provides possibility to stop background merges for tables in the MergeTree family:
2019-11-01 08:45:09 +00:00
2020-03-20 10:10:48 +00:00
``` sql
2019-11-01 14:17:49 +00:00
SYSTEM STOP MERGES [[db.]merge_tree_family_table_name]
2019-11-01 08:45:09 +00:00
```
2020-03-20 10:10:48 +00:00
2019-11-22 13:02:33 +00:00
!!! note "Note"
2019-11-01 14:31:06 +00:00
`DETACH / ATTACH` table will start background merges for the table even in case when merges have been stopped for all MergeTree tables before.
2019-11-01 14:17:49 +00:00
2020-03-22 09:14:59 +00:00
### START MERGES {#query_language-system-start-merges}
2019-11-01 14:17:49 +00:00
Provides possibility to start background merges for tables in the MergeTree family:
2019-11-01 08:45:09 +00:00
2020-03-20 10:10:48 +00:00
``` sql
2019-11-01 14:17:49 +00:00
SYSTEM START MERGES [[db.]merge_tree_family_table_name]
2019-11-01 08:45:09 +00:00
```
2020-01-30 10:34:55 +00:00
[Original article ](https://clickhouse.tech/docs/en/query_language/system/ ) <!--hide-->