> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-3a82795f.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Documentation for SYSTEM Statements

# SYSTEM Statements

export const CloudNotSupportedBadge = () => {
  return <div className="cloudNotSupportedBadge">
            <div className="cloudNotSupportedIcon">
            <svg width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg">
                <path strokeWidth="1.5" d="M6.33366 12.6666L12.3739 12.6667C13.6593 12.6667 14.7073 11.6187 14.7073 10.3334C14.7073 9.04804 13.6593 8.00003 12.3739 8.00003C12.3739 8.00003 12.3337 7.66659 12.0003 7.33325M10.667 5.33322C8.00033 2.33325 4.45395 4.78537 4.14195 6.68203C2.55728 6.7627 1.29395 8.06203 1.29395 9.6667C1.29395 11.3234 2.66699 12.6666 4.00033 12.6666" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" />
                <path strokeWidth="1.5" d="M2.66699 14L12.0003 4.66663" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" />
            </svg>

        </div>
            Not supported in ClickHouse Cloud
        </div>;
};

<h2 id="reload-embedded-dictionaries">
  SYSTEM RELOAD EMBEDDED DICTIONARIES
</h2>

Reload all [Internal dictionaries](/reference/statements/create/dictionary).
By default, internal dictionaries are disabled.
Always returns `Ok.` regardless of the result of the internal dictionary update.

<h2 id="reload-dictionaries">
  SYSTEM RELOAD DICTIONARIES
</h2>

The `SYSTEM RELOAD DICTIONARIES` query reloads dictionaries with a status of `LOADED` (see the `status` column of [`system.dictionaries`](/reference/system-tables/dictionaries)), i.e dictionaries that have been successfully loaded before.
By default, dictionaries are loaded lazily (see [dictionaries\_lazy\_load](/reference/settings/server-settings/settings#dictionaries_lazy_load)), so instead of being loaded automatically at startup, they are initialized on first access through use of the [`dictGet`](/reference/functions/regular-functions/ext-dict-functions#dictGet) function or use of `SELECT` from tables with `ENGINE = Dictionary`.

**Syntax**

```sql theme={null}
SYSTEM RELOAD DICTIONARIES [ON CLUSTER cluster_name]
```

<h2 id="reload-dictionary">
  SYSTEM RELOAD DICTIONARY
</h2>

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.

```sql theme={null}
SYSTEM RELOAD DICTIONARY [ON CLUSTER cluster_name] dictionary_name
```

The status of the dictionary can be checked by querying the `system.dictionaries` table.

```sql theme={null}
SELECT name, status FROM system.dictionaries;
```

<h2 id="reload-models">
  SYSTEM RELOAD MODELS
</h2>

<Note>
  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.
</Note>

Unloads all CatBoost models.

**Syntax**

```sql theme={null}
SYSTEM RELOAD MODELS [ON CLUSTER cluster_name]
```

<h2 id="reload-model">
  SYSTEM RELOAD MODEL
</h2>

Unloads a CatBoost model at `model_path`.

**Syntax**

```sql theme={null}
SYSTEM RELOAD MODEL [ON CLUSTER cluster_name] <model_path>
```

<h2 id="reload-functions">
  SYSTEM RELOAD FUNCTIONS
</h2>

Reloads all registered [executable user defined functions](/reference/functions/regular-functions/udf#executable-user-defined-functions) or one of them from a configuration file.

**Syntax**

```sql theme={null}
SYSTEM RELOAD FUNCTIONS [ON CLUSTER cluster_name]
SYSTEM RELOAD FUNCTION [ON CLUSTER cluster_name] function_name
```

<h2 id="reload-asynchronous-metrics">
  SYSTEM RELOAD ASYNCHRONOUS METRICS
</h2>

Re-calculates all [asynchronous metrics](/reference/system-tables/asynchronous_metrics). Since asynchronous metrics are periodically updated based on setting [asynchronous\_metrics\_update\_period\_s](/reference/settings/server-settings/settings), updating them manually using this statement is typically not necessary.

```sql theme={null}
SYSTEM RELOAD ASYNCHRONOUS METRICS [ON CLUSTER cluster_name]
```

<h2 id="drop-dns-cache">
  SYSTEM CLEAR|DROP DNS CACHE
</h2>

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.

<h2 id="drop-mark-cache">
  SYSTEM CLEAR|DROP MARK CACHE
</h2>

Clears the mark cache.

<h2 id="drop-iceberg-metadata-cache">
  SYSTEM CLEAR|DROP ICEBERG METADATA CACHE
</h2>

Clears the iceberg metadata cache.

<h2 id="drop-avro-schema-cache">
  SYSTEM CLEAR|DROP AVRO SCHEMA CACHE
</h2>

Clears the per-URL Confluent Schema Registry caches used by the `AvroConfluent` format. This drops both the schema-fetch cache (id → schema) and the schema-registration cache (subject + schema → id), so subsequent reads and writes fall back to the registry server. Useful when a schema was deleted or rewritten on the registry side, or to verify the registry's idempotency in tests.

<h2 id="drop-parquet-metadata-cache">
  SYSTEM DROP PARQUET METADATA CACHE
</h2>

Clears the parquet metadata cache.

<h2 id="drop-text-index-caches">
  SYSTEM CLEAR|DROP TEXT INDEX CACHES
</h2>

Clears the text index's header, dictionary and postings caches.

If you like to drop one of these caches individually, you can run

* `SYSTEM CLEAR TEXT INDEX HEADER CACHE`,
* `SYSTEM CLEAR TEXT INDEX DICTIONARY CACHE`, or
* `SYSTEM CLEAR TEXT INDEX POSTINGS CACHE`

<h2 id="drop-replica">
  SYSTEM DROP REPLICA
</h2>

Dead replicas of `ReplicatedMergeTree` tables can be dropped using following syntax:

```sql theme={null}
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';
```

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.

<h2 id="drop-database-replica">
  SYSTEM DROP DATABASE REPLICA
</h2>

Dead replicas of `Replicated` databases can be dropped using following syntax:

```sql theme={null}
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';
```

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.

<h2 id="drop-uncompressed-cache">
  SYSTEM CLEAR|DROP UNCOMPRESSED CACHE
</h2>

Clears the uncompressed data cache.
The uncompressed data cache is enabled/disabled with the query/user/profile-level setting [`use_uncompressed_cache`](/reference/settings/session-settings#use_uncompressed_cache).
Its size can be configured using the server-level setting [`uncompressed_cache_size`](/reference/settings/server-settings/settings#uncompressed_cache_size).

<h2 id="drop-compiled-expression-cache">
  SYSTEM CLEAR|DROP COMPILED EXPRESSION CACHE
</h2>

Clears the compiled expression cache.
The compiled expression cache is enabled/disabled with the query/user/profile-level setting [`compile_expressions`](/reference/settings/session-settings#compile_expressions).

<h2 id="drop-query-condition-cache">
  SYSTEM CLEAR|DROP QUERY CONDITION CACHE
</h2>

Clears the query condition cache.

<h2 id="drop-query-cache">
  SYSTEM CLEAR|DROP QUERY CACHE
</h2>

```sql theme={null}
SYSTEM CLEAR QUERY CACHE;
SYSTEM CLEAR QUERY CACHE TAG '<tag>'
```

Clears the [query cache](/concepts/features/performance/caches/query-cache).
If a tag is specified, only query cache entries with the specified tag are deleted.

<h2 id="system-drop-schema-format">
  SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE
</h2>

Clears cache for schemas loaded from [`format_schema_path`](/reference/settings/server-settings/settings#format_schema_path).

Supported targets:

* Protobuf: Removes imported Protobuf message definitions from memory.
* Files: Deletes cached schema files stored locally in the [`format_schema_path`](/reference/settings/server-settings/settings#format_schema_path), generated when `format_schema_source` is set to `query`.
  Note: If no target is specified, both caches are cleared.

```sql theme={null}
SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE [FOR Protobuf/Files]
```

<h2 id="flush-logs">
  SYSTEM FLUSH LOGS
</h2>

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.

```sql theme={null}
SYSTEM FLUSH LOGS [ON CLUSTER cluster_name] [log_name|[database.table]] [, ...]
```

If you don't want to flush everything, you can flush one or more individual logs by passing either their name or their target table:

```sql theme={null}
SYSTEM FLUSH LOGS query_log, system.query_views_log;
```

<h2 id="reload-config">
  SYSTEM RELOAD CONFIG
</h2>

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`

```sql theme={null}
SYSTEM RELOAD CONFIG [ON CLUSTER cluster_name]
```

<h2 id="reload-users">
  SYSTEM RELOAD USERS
</h2>

Reloads all access storages, including: users.xml, local disk access storage, replicated (in ZooKeeper) access storage.

```sql theme={null}
SYSTEM RELOAD USERS [ON CLUSTER cluster_name]
```

<h2 id="shutdown">
  SYSTEM SHUTDOWN
</h2>

Normally shuts down ClickHouse (like `service clickhouse-server stop` / `kill {$pid_clickhouse-server}`)

<h2 id="kill">
  SYSTEM KILL
</h2>

Aborts ClickHouse process (like `kill -9 {$ pid_clickhouse-server}`)

<h2 id="instrument">
  SYSTEM INSTRUMENT
</h2>

Manages instrumentation points using LLVM's XRay feature which is available when ClickHouse is built using `ENABLE_XRAY=1`.
This enables to debug and profile in production without modifying the source code and with minimal overhead.
When no instrumentation point is added, the performance penalty is negligible because it only adds an extra jump to a nearby
address at the prolog and epilog of those functions that are longer than 200 instructions.

<h3 id="instrument-add">
  SYSTEM INSTRUMENT ADD
</h3>

Adds a new instrumentation point. Functions instrumented can be inspected in the [`system.instrumentation`](/reference/system-tables/instrumentation) system table. More than one handler can be added for the same function, and they will be executed in the same order the instrumentation is added.
The functions to be instrumented can be collected from [`system.symbols`](/reference/system-tables/symbols) system table.

There are three different kind of handlers to add to functions:

**Syntax**

```sql theme={null}
SYSTEM INSTRUMENT ADD FUNCTION HANDLER [PARAMETERS]
```

where `FUNCTION` is any function or substring of a function such as `QueryMetricLog::startQuery`, and the handler one of the following

<h4 id="instrument-add-log">
  LOG
</h4>

Prints the text provided as an argument and the stack trace either on `ENTRY` or `EXIT` of the function.

```sql theme={null}
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'
```

<h4 id="instrument-add-sleep">
  SLEEP
</h4>

Sleeps for a number of fix amount of seconds either on `ENTRY` or `EXIT`:

```sql theme={null}
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' SLEEP ENTRY 0.5
```

or for a uniformly distributed random amount of seconds providing min and max separated by a whitespace:

```sql theme={null}
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' SLEEP ENTRY 0 1
```

<h4 id="instrument-add-profile">
  PROFILE
</h4>

Measures the time spent between `ENTRY` and `EXIT` of a function.
The result of the profiling is stored in [`system.trace_log`](/reference/system-tables/trace_log) and can be converted
to [Chrome Event Trace Format](/reference/system-tables/trace_log#chrome-event-trace-format).

```sql theme={null}
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' PROFILE
```

<h3 id="instrument-remove">
  SYSTEM INSTRUMENT REMOVE
</h3>

Removes either a single instrumentation point with:

```sql theme={null}
SYSTEM INSTRUMENT REMOVE ID
```

all of them using the `ALL` parameter:

```sql theme={null}
SYSTEM INSTRUMENT REMOVE ALL
```

a set of IDs from a subquery:

```sql theme={null}
SYSTEM INSTRUMENT REMOVE (SELECT id FROM system.instrumentation WHERE handler = 'log')
```

or all instrumentation points that match a given function\_name:

```sql theme={null}
SYSTEM INSTRUMENT REMOVE 'QueryMetricLog::startQuery'
```

The instrumentation point information can be collected from [`system.instrumentation`](/reference/system-tables/instrumentation) system table.

<h2 id="managing-distributed-tables">
  Managing Distributed Tables
</h2>

ClickHouse can manage [distributed](/reference/engines/table-engines/special/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`](#stop-distributed-sends), [FLUSH DISTRIBUTED](#flush-distributed), and [`START DISTRIBUTED SENDS`](#start-distributed-sends) queries. You can also synchronously insert distributed data with the [`distributed_foreground_insert`](/reference/settings/session-settings#distributed_foreground_insert) setting.

<h3 id="stop-distributed-sends">
  SYSTEM STOP DISTRIBUTED SENDS
</h3>

Disables background data distribution when inserting data into distributed tables.

```sql theme={null}
SYSTEM STOP DISTRIBUTED SENDS [db.]<distributed_table_name> [ON CLUSTER cluster_name]
```

<Note>
  In case of [`prefer_localhost_replica`](/reference/settings/session-settings#prefer_localhost_replica) is enabled (the default), the data to local shard will be inserted anyway.
</Note>

<h3 id="flush-distributed">
  SYSTEM FLUSH DISTRIBUTED
</h3>

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

```sql theme={null}
SYSTEM FLUSH DISTRIBUTED [db.]<distributed_table_name> [ON CLUSTER cluster_name] [SETTINGS ...]
```

<Note>
  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.
</Note>

<h3 id="start-distributed-sends">
  SYSTEM START DISTRIBUTED SENDS
</h3>

Enables background data distribution when inserting data into distributed tables.

```sql theme={null}
SYSTEM START DISTRIBUTED SENDS [db.]<distributed_table_name> [ON CLUSTER cluster_name]
```

<h3 id="stop-listen">
  SYSTEM STOP LISTEN
</h3>

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.

```sql theme={null}
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']
```

* 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 with `EXCEPT` clause.
* If `QUERIES DEFAULT [EXCEPT .. [,..]]` modifier is specified, all default protocols are stopped, unless specified with `EXCEPT` clause.
* If `QUERIES CUSTOM [EXCEPT .. [,..]]` modifier is specified, all custom protocols are stopped, unless specified with `EXCEPT` clause.

<h3 id="start-listen">
  SYSTEM START LISTEN
</h3>

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.

```sql theme={null}
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']
```

<h2 id="managing-mergetree-tables">
  Managing MergeTree Tables
</h2>

ClickHouse can manage background processes in [MergeTree](/reference/engines/table-engines/mergetree-family/mergetree) tables.

<h3 id="stop-merges">
  SYSTEM STOP MERGES
</h3>

Provides possibility to stop background merges for tables in the MergeTree family:

```sql theme={null}
SYSTEM STOP MERGES [ON CLUSTER cluster_name] [ON VOLUME <volume_name> | [db.]merge_tree_family_table_name]
```

<Note>
  `DETACH / ATTACH` table will start background merges for the table even in case when merges have been stopped for all MergeTree tables before.
</Note>

<h3 id="start-merges">
  SYSTEM START MERGES
</h3>

Provides possibility to start background merges for tables in the MergeTree family:

```sql theme={null}
SYSTEM START MERGES [ON CLUSTER cluster_name] [ON VOLUME <volume_name> | [db.]merge_tree_family_table_name]
```

<h3 id="stop-ttl-merges">
  SYSTEM STOP TTL MERGES
</h3>

Provides possibility to stop background delete old data according to [TTL expression](/reference/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-ttl) 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:

```sql theme={null}
SYSTEM STOP TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
```

<h3 id="start-ttl-merges">
  SYSTEM START TTL MERGES
</h3>

Provides possibility to start background delete old data according to [TTL expression](/reference/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-ttl) for tables in the MergeTree family:
Returns `Ok.` even if table does not exist. Returns error when database does not exist:

```sql theme={null}
SYSTEM START TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
```

<h3 id="stop-moves">
  SYSTEM STOP MOVES
</h3>

Provides possibility to stop background move data according to [TTL table expression with TO VOLUME or TO DISK clause](/reference/engines/table-engines/mergetree-family/mergetree#mergetree-table-ttl) for tables in the MergeTree family:
Returns `Ok.` even if table does not exist. Returns error when database does not exist:

```sql theme={null}
SYSTEM STOP MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
```

<h3 id="start-moves">
  SYSTEM START MOVES
</h3>

Provides possibility to start background move data according to [TTL table expression with TO VOLUME and TO DISK clause](/reference/engines/table-engines/mergetree-family/mergetree#mergetree-table-ttl) for tables in the MergeTree family:
Returns `Ok.` even if table does not exist. Returns error when database does not exist:

```sql theme={null}
SYSTEM START MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
```

<h3 id="query_language-system-unfreeze">
  SYSTEM SYSTEM UNFREEZE
</h3>

Clears a frozen backup with the specified name from all the disks. See more about unfreezing separate parts in [ALTER TABLE table\_name UNFREEZE WITH NAME ](/reference/statements/alter/partition#unfreeze-partition)

```sql theme={null}
SYSTEM UNFREEZE WITH NAME <backup_name>
```

<h3 id="wait-loading-parts">
  SYSTEM WAIT LOADING PARTS
</h3>

Wait until all asynchronously loading data parts of a table (outdated data parts) will became loaded.

```sql theme={null}
SYSTEM WAIT LOADING PARTS [ON CLUSTER cluster_name] [db.]merge_tree_family_table_name
```

<h2 id="managing-replicatedmergetree-tables">
  Managing ReplicatedMergeTree Tables
</h2>

ClickHouse can manage background replication related processes in [ReplicatedMergeTree](/reference/engines/table-engines/mergetree-family/replication) tables.

<h3 id="stop-fetches">
  SYSTEM STOP FETCHES
</h3>

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.

```sql theme={null}
SYSTEM STOP FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```

<h3 id="start-fetches">
  SYSTEM START FETCHES
</h3>

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.

```sql theme={null}
SYSTEM START FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```

<h3 id="stop-replicated-sends">
  SYSTEM STOP REPLICATED SENDS
</h3>

Provides possibility to stop background sends to other replicas in cluster for new inserted parts for tables in the `ReplicatedMergeTree` family:

```sql theme={null}
SYSTEM STOP REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```

<h3 id="start-replicated-sends">
  SYSTEM START REPLICATED SENDS
</h3>

Provides possibility to start background sends to other replicas in cluster for new inserted parts for tables in the `ReplicatedMergeTree` family:

```sql theme={null}
SYSTEM START REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```

<h3 id="stop-replication-queues">
  SYSTEM STOP REPLICATION QUEUES
</h3>

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:

```sql theme={null}
SYSTEM STOP REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```

<h3 id="start-replication-queues">
  SYSTEM START REPLICATION QUEUES
</h3>

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:

```sql theme={null}
SYSTEM START REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```

<h3 id="stop-pulling-replication-log">
  SYSTEM STOP PULLING REPLICATION LOG
</h3>

Stops loading new entries from replication log to replication queue in a `ReplicatedMergeTree` table.

```sql theme={null}
SYSTEM STOP PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```

<h3 id="start-pulling-replication-log">
  SYSTEM START PULLING REPLICATION LOG
</h3>

Cancels `SYSTEM STOP PULLING REPLICATION LOG`.

```sql theme={null}
SYSTEM START PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```

<h3 id="sync-replica">
  SYSTEM SYNC REPLICA
</h3>

Wait until a `ReplicatedMergeTree` table will be synced with other replicas in a cluster, but no more than `receive_timeout` seconds.

```sql theme={null}
SYSTEM SYNC REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name [IF EXISTS] [STRICT | LIGHTWEIGHT [FROM 'srcReplica1'[, 'srcReplica2'[, ...]]] | PULL]
```

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:

* With `IF EXISTS` (available since 25.6) the query won't throw an error if the table does not exists. This is useful when adding a new replica to a cluster, when it's already part of the cluster configuration but it is still in the process of creating and synchronizing the table.
* If a `STRICT` modifier was specified then the query waits for the replication queue to become empty. The `STRICT` version may never succeed if new entries constantly appear in the replication queue.
* If a `LIGHTWEIGHT` modifier was specified then the query waits only for `GET_PART`, `ATTACH_PART`, `DROP_RANGE`, `REPLACE_RANGE` and `DROP_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.

<h3 id="sync-database-replica">
  SYNC DATABASE REPLICA
</h3>

Waits until the specified [replicated database](/reference/engines/database-engines/replicated) applies all schema changes from the DDL queue of that database.

**Syntax**

```sql theme={null}
SYSTEM SYNC DATABASE REPLICA replicated_database_name;
```

<h3 id="restart-replica">
  SYSTEM RESTART REPLICA
</h3>

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.

```sql theme={null}
SYSTEM RESTART REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name
```

<h3 id="restore-replica">
  SYSTEM RESTORE REPLICA
</h3>

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

<Note>
  Parts in all states are moved to `detached/` folder. Parts active before data loss (committed) are attached.
</Note>

<h3 id="restore-database-replica">
  SYSTEM RESTORE DATABASE REPLICA
</h3>

Restores a replica if data is \[possibly] present but Zookeeper metadata is lost.

**Syntax**

```sql theme={null}
SYSTEM RESTORE DATABASE REPLICA repl_db [ON CLUSTER cluster]
```

**Example**

```sql theme={null}
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;
```

**Syntax**

```sql theme={null}
SYSTEM RESTORE REPLICA [db.]replicated_merge_tree_family_table_name [ON CLUSTER cluster_name]
```

Alternative syntax:

```sql theme={null}
SYSTEM RESTORE REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name
```

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

```sql theme={null}
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;
```

Another way:

```sql theme={null}
SYSTEM RESTORE REPLICA test ON CLUSTER cluster;
```

<h3 id="restart-replicas">
  SYSTEM RESTART REPLICAS
</h3>

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

<h3 id="drop-filesystem-cache">
  SYSTEM CLEAR|DROP FILESYSTEM CACHE
</h3>

Allows to drop filesystem cache.

```sql theme={null}
SYSTEM CLEAR FILESYSTEM CACHE [ON CLUSTER cluster_name]
```

<h3 id="sync-file-cache">
  SYSTEM SYNC FILE CACHE
</h3>

<Note>
  It's too heavy and has potential for misuse.
</Note>

Will do sync syscall.

```sql theme={null}
SYSTEM SYNC FILE CACHE [ON CLUSTER cluster_name]
```

<h3 id="load-primary-key">
  SYSTEM LOAD PRIMARY KEY
</h3>

Load the primary keys for the given table or for all tables.

```sql theme={null}
SYSTEM LOAD PRIMARY KEY [db.]name
```

```sql theme={null}
SYSTEM LOAD PRIMARY KEY
```

<h3 id="unload-primary-key">
  SYSTEM UNLOAD PRIMARY KEY
</h3>

Unload the primary keys for the given table or for all tables.

```sql theme={null}
SYSTEM UNLOAD PRIMARY KEY [db.]name
```

```sql theme={null}
SYSTEM UNLOAD PRIMARY KEY
```

<h2 id="managing-refreshable-materialized-views">
  Managing Refreshable Materialized Views
</h2>

Commands to control background tasks performed by [Refreshable Materialized Views](/reference/statements/create/view#refreshable-materialized-view)

Keep an eye on [`system.view_refreshes`](/reference/system-tables/view_refreshes) while using them.

<h3 id="stop-view-stop-views">
  SYSTEM STOP \[REPLICATED] VIEW, STOP VIEWS
</h3>

Disable periodic refreshing of the given view or all refreshable views. If a refresh is in progress, cancel it too.

If the view is in a Replicated or Shared database, `STOP VIEW` only affects the current replica, while `STOP REPLICATED VIEW` affects all replicas.

<Note>
  The stopped state does not persist across server restarts. After a restart, views will resume their configured refresh schedules.
  In Replicated or Shared databases, `SYSTEM STOP VIEW` only affects the current replica. Use `SYSTEM STOP REPLICATED VIEW` to stop refreshes on all replicas.
</Note>

```sql theme={null}
SYSTEM STOP VIEW [db.]name
```

```sql theme={null}
SYSTEM STOP VIEWS
```

<h3 id="start-view-start-views">
  SYSTEM START \[REPLICATED] VIEW, START VIEWS
</h3>

Enable periodic refreshing for the given view or all refreshable views. No immediate refresh is triggered.

If the view is in a Replicated or Shared database, `START VIEW` undoes the effect of `STOP VIEW`, and `START REPLICATED VIEW` undoes the effect of `STOP REPLICATED VIEW`. `START VIEW` also undoes the effect of `PAUSE VIEW`.

```sql theme={null}
SYSTEM START VIEW [db.]name
```

```sql theme={null}
SYSTEM START VIEWS
```

<h3 id="pause-view-pause-views">
  SYSTEM PAUSE VIEW, PAUSE VIEWS
</h3>

Disable periodic refreshing of the given view or all refreshable views.
Unlike `SYSTEM STOP VIEW`, `SYSTEM PAUSE VIEW` does not interrupt a refresh that is already in progress: the running refresh is allowed to finish, and only subsequent refreshes are prevented.

Undo with `SYSTEM START VIEW` or `SYSTEM START VIEWS`.

<Note>
  The paused state does not persist across server restarts. After a restart, views will resume their configured refresh schedules.
  In Replicated or Shared databases, `SYSTEM PAUSE VIEW` only affects the current replica.
</Note>

```sql theme={null}
SYSTEM PAUSE VIEW [db.]name
```

```sql theme={null}
SYSTEM PAUSE VIEWS
```

<h3 id="refresh-view">
  SYSTEM REFRESH VIEW
</h3>

Trigger an immediate out-of-schedule refresh of a given view.

```sql theme={null}
SYSTEM REFRESH VIEW [db.]name
```

<h3 id="wait-view">
  SYSTEM WAIT VIEW
</h3>

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.

If the view is in a Replicated or Shared database, and refresh is running on another replica, waits for that refresh to complete.

```sql theme={null}
SYSTEM WAIT VIEW [db.]name
```

<h3 id="cancel-view">
  SYSTEM CANCEL VIEW
</h3>

If there's a refresh in progress for the given view on the current replica, interrupt and cancel it. Otherwise do nothing.

```sql theme={null}
SYSTEM CANCEL VIEW [db.]name
```

<h2 id="flush-object-storage-queue">
  SYSTEM FLUSH OBJECT STORAGE QUEUE
</h2>

Blocks until the given file has been processed or permanently failed by the given [S3Queue](/reference/engines/table-engines/integrations/s3queue) or [AzureQueue](/reference/engines/table-engines/integrations/azure-queue) table. Returns immediately if the file was already processed. Raises an error if the file has permanently failed (all retries exhausted).

```sql theme={null}
SYSTEM FLUSH OBJECT STORAGE QUEUE [db.]table_name PATH 'path'
```