SYSTEM ステートメント

SYSTEM RELOAD EMBEDDED DICTIONARIES

すべての 内部Dictionary を再読み込みします。 デフォルトでは、内部Dictionaryは無効化されています。 内部Dictionaryの更新結果に関係なく、常に Ok. を返します。

SYSTEM RELOAD DICTIONARIES

以前に正常にロードされたすべてのディクショナリを再ロードします。 デフォルトでは、ディクショナリは遅延ロードされます（dictionaries_lazy_load を参照）。そのため、起動時に自動的にロードされるのではなく、dictGet 関数または SELECT を使って ENGINE = Dictionary のテーブルにアクセスしたときに初めて初期化されます。SYSTEM RELOAD DICTIONARIES クエリは、このようなディクショナリ（LOADED、system.dictionaries の status 列を参照）を再ロードします。 ディクショナリの更新結果に関わらず、常に Ok. を返します。

構文

SYSTEM RELOAD DICTIONARIES [ON CLUSTER cluster_name]

SYSTEM RELOAD DICTIONARY

Dictionary dictionary_name を、辞書の状態（LOADED / NOT_LOADED / FAILED）に関係なく完全に再読み込みします。 Dictionary の更新結果に関係なく、常に Ok. を返します。

SYSTEM RELOAD DICTIONARY [ON CLUSTER cluster_name] dictionary_name

Dictionary の状態は system.dictionaries テーブルをクエリすることで確認できます。

SELECT name, status FROM system.dictionaries;

SYSTEM RELOAD MODELS

注記

このステートメントと SYSTEM RELOAD MODEL は、単に clickhouse-library-bridge から CatBoost モデルをアンロードするだけです。catboostEvaluate() 関数は、まだロードされていない場合、初回アクセス時にモデルをロードします。

すべてのCatBoostモデルをアンロードします。

構文

SYSTEM RELOAD MODELS [ON CLUSTER cluster_name]

SYSTEM RELOAD MODEL

model_path で指定されたCatBoostモデルを再読み込みします。

構文

SYSTEM RELOAD MODEL [ON CLUSTER cluster_name] <model_path>

SYSTEM RELOAD FUNCTIONS

設定ファイルから、登録済みの実行可能なユーザー定義関数をすべて、またはいずれか1つを再読み込みします。

構文

SYSTEM RELOAD FUNCTIONS [ON CLUSTER cluster_name]
SYSTEM RELOAD FUNCTION [ON CLUSTER cluster_name] function_name

SYSTEM RELOAD ASYNCHRONOUS METRICS

すべての非同期メトリクスを再計算します。非同期メトリクスは、asynchronous_metrics_update_period_s設定に基づいて定期的に更新されるため、このステートメントを手動で実行して更新する必要は通常ありません。

SYSTEM RELOAD ASYNCHRONOUS METRICS [ON CLUSTER cluster_name]

SYSTEM DROP DNS CACHE

ClickHouseの内部DNSキャッシュをクリアします。インフラストラクチャを変更する際（別のClickHouseサーバーやディクショナリで使用されるサーバーのIPアドレスを変更する場合など）、古いバージョンのClickHouseではこのコマンドの使用が必要になることがあります。

より便利（自動的）なキャッシュ管理を行うには、disable_internal_dns_cache、dns_cache_max_entries、dns_cache_update_period パラメータを参照してください。

SYSTEM DROP MARK CACHE

マークキャッシュをクリアします。

SYSTEM DROP ICEBERG METADATA CACHE

Icebergメタデータキャッシュをクリアします。

SYSTEM DROP TEXT INDEX DICTIONARY CACHE

テキストインデックスのDictionaryキャッシュをクリアします。

SYSTEM DROP TEXT INDEX HEADER CACHE

テキストインデックスヘッダーキャッシュをクリアします。

SYSTEM DROP TEXT INDEX POSTINGS CACHE

テキスト索引のポスティングキャッシュを消去します。

SYSTEM DROP TEXT INDEX POSTINGS CACHE

テキスト索引ヘッダーキャッシュ、Dictionaryキャッシュおよびポスティングキャッシュをクリアします。

SYSTEM DROP REPLICA

ReplicatedMergeTreeテーブルの停止したレプリカは、次の構文で削除できます。

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';

これらのクエリは、ZooKeeper内の ReplicatedMergeTree レプリカパスを削除します。これは、レプリカがダウンしており、もはやそのテーブルが存在しないために DROP TABLE では ZooKeeper からメタデータを削除できない場合に有用です。非アクティブまたは古いレプリカのみを削除し、ローカルレプリカを削除することはできません。その場合は DROP TABLE を使用してください。DROP REPLICA はテーブルを一切削除せず、ディスク上のデータやメタデータも削除しません。

1つ目は、database.table テーブルの 'replica_name' レプリカのメタデータを削除します。 2つ目は、データベース内のすべてのレプリケートテーブルに対して同じ操作を行います。 3つ目は、ローカルサーバー上のすべてのレプリケートテーブルに対して同じ操作を行います。 4つ目は、テーブルの他のすべてのレプリカが削除されたあとに、ダウンしたレプリカのメタデータを削除する場合に有用です。テーブルパスを明示的に指定する必要があります。このパスは、テーブル作成時に ReplicatedMergeTree エンジンの第1引数として渡されたパスと同一でなければなりません。

SYSTEM DROP DATABASE REPLICA

Replicated データベースの不要なレプリカは、以下の構文で削除できます。

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 と同様ですが、DROP DATABASE を実行する対象のデータベースが存在しない場合に、ZooKeeper から Replicated データベースのレプリカパスを削除します。なお、このステートメントは ReplicatedMergeTree のレプリカは削除しないため、必要に応じて SYSTEM DROP REPLICA も実行する必要があります。シャード名とレプリカ名は、データベース作成時に Replicated エンジンの引数として指定した名前です。また、これらの名前は system.clusters の database_shard_name および database_replica_name カラムから取得できます。FROM SHARD 句が省略された場合、replica_name は shard_name|replica_name 形式の完全なレプリカ名である必要があります。

SYSTEM DROP UNCOMPRESSED CACHE

非圧縮データキャッシュをクリアします。 非圧縮データキャッシュは、クエリ/ユーザー/プロファイルレベルの設定 use_uncompressed_cache によって有効化/無効化されます。 そのサイズは、サーバーレベルの設定 uncompressed_cache_size で設定できます。

SYSTEM DROP COMPILED EXPRESSION CACHE

コンパイル済み式キャッシュをクリアします。 コンパイル済み式キャッシュは、クエリ/ユーザー/プロファイルレベルの設定 compile_expressions によって有効化/無効化されます。

SYSTEM DROP QUERY CONDITION CACHE

クエリ条件キャッシュを消去します。

クエリ条件キャッシュをクリアします。

SYSTEM DROP QUERY CACHE

SYSTEM DROP QUERY CACHE;
SYSTEM DROP QUERY CACHE TAG '<tag>'

query cache をクリアします。 タグを指定した場合は、指定されたタグを持つクエリキャッシュエントリのみが削除されます。

SYSTEM DROP FORMAT SCHEMA CACHE

format_schema_pathから読み込まれたスキーマのキャッシュをクリアします。

サポートされている対象:

• Protobuf: インポートされたProtobufメッセージ定義をメモリから削除します。
• Files: format_schema_source が query に設定されている場合に生成され、ローカルの format_schema_path に保存されているスキーマファイルのキャッシュを削除します。 注意: 対象を指定しない場合、両方のキャッシュがクリアされます。

SYSTEM DROP FORMAT SCHEMA CACHE [FOR Protobuf/Files]

SYSTEM FLUSH LOGS

バッファされているログメッセージを system.query_log などの system テーブルにフラッシュします。多くの system テーブルはデフォルトのフラッシュ間隔が 7.5 秒に設定されているため、主にデバッグ時に役立ちます。 これにより、メッセージキューが空であっても system テーブルが作成されます。

SYSTEM FLUSH LOGS [ON CLUSTER cluster_name] [log_name|[database.table]] [, ...]

すべてをフラッシュしたくない場合は、名前または対象テーブルを渡すことで、特定のログ（1つまたは複数）だけをフラッシュできます。

SYSTEM FLUSH LOGS query_log, system.query_views_log;

SYSTEM RELOAD CONFIG

ClickHouseの設定を再読み込みします。設定がZooKeeperに保存されている場合に使用します。SYSTEM RELOAD CONFIG はZooKeeperに保存されている USER の設定は再読み込みせず、users.xml に保存されている USER の設定のみを再読み込みします。すべての USER 設定を再読み込むには SYSTEM RELOAD USERS を使用します。

SYSTEM RELOAD CONFIG [ON CLUSTER cluster_name]

SYSTEM RELOAD USERS

users.xml、ローカルディスクのアクセスストレージ、ZooKeeper上でレプリケートされているアクセスストレージなど、すべてのアクセスストレージを再読み込みします。

SYSTEM RELOAD USERS [ON CLUSTER cluster_name]

SYSTEM SHUTDOWN

Not supported in ClickHouse Cloud

ClickHouse を通常の方法でシャットダウンします（service clickhouse-server stop / kill {$pid_clickhouse-server} と同様に動作します）

SYSTEM KILL

ClickHouseプロセスを強制終了します（kill -9 {$ pid_clickhouse-server} のように動作します）。

SYSTEM INSTRUMENT

ClickHouse を ENABLE_XRAY=1 を指定してビルドした場合に利用可能な LLVM の XRay 機能を用いて、インストルメンテーションポイントを管理します。 これにより、ソースコードを変更することなく、かつ最小限のオーバーヘッドで、本番環境におけるデバッグとプロファイリングを行うことができます。 インストルメンテーションポイントが追加されていない場合、性能への影響はごくわずかです。これは、200 命令を超える長さの関数のプロローグとエピローグに対して、近傍のアドレスへの余分なジャンプが 1 回追加されるだけだからです。

SYSTEM INSTRUMENT ADD

新しいインストルメンテーションポイントを追加します。インストルメント対象となった関数は、system.instrumentation システムテーブルで確認できます。同じ関数に対して複数のハンドラーを追加でき、インストルメンテーションが追加された順に実行されます。 インストルメント対象の関数は、system.symbols システムテーブルから収集できます。

関数に追加できるハンドラーの種類は 3 つあります。

構文

SYSTEM INSTRUMENT ADD FUNCTION HANDLER [PARAMETERS]

ここで、FUNCTION は QueryMetricLog::startQuery のような関数、または関数名の一部（サブストリング）を表し、handler には次のいずれかを指定します

LOG

関数のENTRYまたはEXITのタイミングで、引数として指定されたテキストとスタックトレースを出力します。

SYSTEM INSTRUMENT ADD `QueryMetricLog::startQuery` LOG ENTRY 'エントリ時に出力されるログ'
SYSTEM INSTRUMENT ADD `QueryMetricLog::startQuery` LOG EXIT '終了時に出力されるログ'

SLEEP

ENTRY または EXIT のいずれかで、指定した秒数だけスリープします。

SYSTEM INSTRUMENT ADD `QueryMetricLog::startQuery` SLEEP ENTRY 0.5

または、最小値と最大値を空白で区切って指定することで、一様分布に従うランダムな秒数を与えることができます：

SYSTEM INSTRUMENT ADD `QueryMetricLog::startQuery` SLEEP ENTRY 0 1

PROFILE

関数の ENTRY から EXIT までに要した時間を計測します。 プロファイリングの結果は system.trace_log に保存されます。

SYSTEM INSTRUMENT ADD `QueryMetricLog::startQuery` PROFILE

SYSTEM INSTRUMENT REMOVE

以下のいずれかの方法で、単一の計測ポイントを削除します。

SYSTEM INSTRUMENT REMOVE ID

いずれも ALL パラメータを使用します。

SYSTEM INSTRUMENT REMOVE ALL

または、サブクエリから得られる ID の集合：

SYSTEM INSTRUMENT REMOVE (SELECT id FROM system.instrumentation WHERE handler = 'log')

インストゥルメンテーションポイントのIDは、system.instrumentation システムテーブルから取得できます。

分散テーブルの管理

ClickHouseは分散テーブルを管理できます。ユーザーがこれらのテーブルにデータを挿入すると、ClickHouseは最初にクラスターノードに送信すべきデータのキューを作成し、その後非同期に送信します。キュー処理は、STOP DISTRIBUTED SENDS、FLUSH DISTRIBUTED、START DISTRIBUTED SENDS クエリで管理できます。また、distributed_foreground_insert 設定を使用して、分散データを同期的に挿入することもできます。

SYSTEM STOP DISTRIBUTED SENDS

分散テーブルへのデータ挿入時に、バックグラウンドでのデータ配信を無効化します。

SYSTEM STOP DISTRIBUTED SENDS [db.]<distributed_table_name> [ON CLUSTER cluster_name]

注記

prefer_localhost_replicaが有効な場合(デフォルト)、ローカル分片へのデータは挿入されます。

SYSTEM FLUSH DISTRIBUTED

ClickHouseにクラスタノードへのデータ送信を同期的に実行させます。いずれかのノードが利用できない場合、ClickHouseは例外をスローし、クエリの実行を停止します。すべてのノードがオンラインに復旧すると成功するため、それまでクエリを再試行できます。

一部の設定は SETTINGS 句で上書きすることもできます。これは、一時的な制限（max_concurrent_queries_for_all_users や max_memory_usage など）を回避するのに有用です。

SYSTEM FLUSH DISTRIBUTED [db.]<distributed_table_name> [ON CLUSTER cluster_name] [SETTINGS ...]

注記

保留中の各ブロックは、最初の INSERT クエリの設定でディスクに保存されます。そのため、場合によっては設定を上書きする必要が生じることがあります。

SYSTEM START DISTRIBUTED SENDS

分散テーブルへのデータ挿入時に、バックグラウンドでのデータ配信を有効化します。

SYSTEM START DISTRIBUTED SENDS [db.]<distributed_table_name> [ON CLUSTER cluster_name]

SYSTEM STOP LISTEN

指定されたポートおよびプロトコルでソケットをクローズし、既存のサーバーへの接続を正常に終了します。

ただし、対応するプロトコル設定が clickhouse-server設定で指定されていない場合、このコマンドは何の効果もありません。

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']

• CUSTOM 'protocol' 修飾子が指定されている場合、サーバー設定のプロトコルセクションで定義された指定名のカスタムプロトコルが停止されます。
• QUERIES ALL [EXCEPT .. [,..]] 修飾子が指定されている場合、EXCEPT 句で指定されたものを除き、すべてのプロトコルが停止されます。
• QUERIES DEFAULT [EXCEPT .. [,..]] 修飾子が指定されている場合、EXCEPT 句で指定されたものを除き、すべてのデフォルトプロトコルが停止されます。
• QUERIES CUSTOM [EXCEPT .. [,..]] 修飾子が指定されている場合、EXCEPT 句で指定されたものを除き、すべてのカスタムプロトコルが停止されます。

SYSTEM START LISTEN

指定されたプロトコルで新しい接続を受け付けられるようにします。

ただし、指定したポートとプロトコルのサーバーが SYSTEM STOP LISTEN コマンドで停止されていない場合、このコマンドは何の効果もありません。

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']

MergeTreeテーブルの管理

ClickHouseはMergeTreeテーブルにおけるバックグラウンドプロセスを管理できます。

SYSTEM STOP MERGES

Not supported in ClickHouse Cloud

MergeTree ファミリーのテーブルに対するバックグラウンドマージ処理を停止するためのコマンドです。

SYSTEM STOP MERGES [ON CLUSTER cluster_name] [ON VOLUME <volume_name> | [db.]merge_tree_family_table_name]

注記

テーブルに対して DETACH/ATTACH を実行すると、すべての MergeTreeテーブルのマージが停止されている場合でも、そのテーブルのバックグラウンドでのマージ処理が開始されます。

SYSTEM START MERGES

Not supported in ClickHouse Cloud

MergeTree ファミリーのテーブルに対してバックグラウンドマージを開始するためのコマンドです。

SYSTEM START MERGES [ON CLUSTER cluster_name] [ON VOLUME <volume_name> | [db.]merge_tree_family_table_name]

SYSTEM STOP TTL MERGES

MergeTreeファミリーのテーブルに対して、TTL expression に従って古いデータをバックグラウンドで削除する処理を停止します。 テーブルが存在しない場合や、テーブルがMergeTreeエンジンではない場合でも Ok. を返します。データベースが存在しない場合はエラーを返します。

SYSTEM STOP TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]

SYSTEM START TTL MERGES

MergeTreeファミリーに属するテーブルに対して、TTL expression に従って古いデータのバックグラウンド削除を開始します。 テーブルが存在しない場合でも Ok. を返し、データベースが存在しない場合はエラーを返します。

SYSTEM START TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]

SYSTEM STOP MOVES

MergeTreeファミリーのテーブルに対して、TO VOLUME または TO DISK 句を含む有効期限 (TTL) テーブル式 に基づくバックグラウンドでのデータ移動を停止するためのコマンドです。 テーブルが存在しない場合でも Ok. を返します。データベースが存在しない場合はエラーを返します。

SYSTEM STOP MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]

SYSTEM START MOVES

MergeTree ファミリーのテーブルに対して、TO VOLUME および TO DISK 句を含む TTL テーブル式 に従い、バックグラウンドでデータ移動を開始します。 テーブルが存在しない場合でも Ok. を返しますが、データベースが存在しない場合はエラーを返します。

SYSTEM START MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]

SYSTEM SYSTEM UNFREEZE

指定された名前の凍結されたバックアップを、すべてのディスクから削除します。個別のパーツを凍結解除する方法については、ALTER TABLE table_name UNFREEZE WITH 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

ReplicatedMergeTreeテーブルの管理

ClickHouseは、ReplicatedMergeTreeテーブルに関連するバックグラウンドのレプリケーション処理を管理できます。

SYSTEM STOP FETCHES

Not supported in ClickHouse Cloud

ReplicatedMergeTree ファミリーのテーブルにおいて、挿入されたパーツのバックグラウンドフェッチを停止します。 テーブルエンジンの種類や、テーブルやデータベースの存在有無にかかわらず、常に Ok. を返します。

SYSTEM STOP FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

SYSTEM START FETCHES

Not supported in ClickHouse Cloud

ReplicatedMergeTreeファミリーのテーブルにおいて、挿入されたパーツのバックグラウンドフェッチを開始します。 テーブルエンジンの種類や、テーブルやデータベースの存在有無にかかわらず、常に Ok. を返します。

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 ファミリーのテーブルについて、ZooKeeper に保存されているレプリケーションキュー内のバックグラウンドフェッチタスクを停止できます。対象となるバックグラウンドタスクの種類は、マージ、フェッチ、ミューテーション、ON CLUSTER 句付きの DDL ステートメントです。

SYSTEM STOP REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

SYSTEM START REPLICATION QUEUES

ReplicatedMergeTree ファミリーのテーブルについて、ZooKeeper に保存されているレプリケーションキューからバックグラウンドでのフェッチタスクを開始する機能を提供します。可能なバックグラウンドタスクの種類は、マージ、フェッチ、ミューテーション、ON CLUSTER 句付きの DDL ステートメントです。

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]

SYSTEM SYNC REPLICA

ReplicatedMergeTreeテーブルがクラスタ内の他のレプリカと同期されるまで待機しますが、receive_timeout 秒を上限とします。

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 は共通のレプリケーションログからコマンドを自身のレプリケーションキューにフェッチし、その後クエリはレプリカがフェッチされたすべてのコマンドを処理するまで待機します。以下の修飾子がサポートされています。

• IF EXISTS（25.6 以降で利用可能）を指定すると、テーブルが存在しない場合でもクエリはエラーを発生させません。これは、新しいレプリカをクラスターに追加する際、すでにクラスター設定の一部になっているものの、まだテーブルの作成と同期の途中である場合に有用です。
• STRICT 修飾子が指定された場合、クエリはレプリケーションキューが空になるまで待機します。レプリケーションキューに新しいエントリが継続的に追加される場合、STRICT バージョンは完了しない可能性があります。
• LIGHTWEIGHT 修飾子が指定された場合、クエリは GET_PART、ATTACH_PART、DROP_RANGE、REPLACE_RANGE、DROP_PART エントリが処理されるまでのみ待機します。 加えて、LIGHTWEIGHT 修飾子はオプションの FROM 'srcReplicas' 句をサポートします。ここで 'srcReplicas' は、ソースレプリカ名のカンマ区切りリストです。この拡張により、指定されたソースレプリカから発生したレプリケーションタスクのみに対象を絞ることで、より的を絞った同期が可能になります。
• PULL 修飾子が指定された場合、クエリは ZooKeeper から新しいレプリケーションキューエントリをフェッチしますが、いずれのエントリの処理完了も待機しません。

SYNC DATABASE REPLICA

指定されたレプリケートデータベースが、そのデータベースの DDL キューにあるすべてのスキーマ変更の適用を完了するまで待機します。

構文

SYSTEM SYNC DATABASE REPLICA replicated_database_name;

SYSTEM RESTART REPLICA

ReplicatedMergeTree テーブルに対して ZooKeeper セッションの状態を再初期化します。現在の状態を信頼できる唯一の情報源である ZooKeeper と比較し、必要に応じて ZooKeeper キューにタスクを追加します。 ZooKeeper のデータに基づくレプリケーションキューの初期化は、ATTACH TABLE ステートメントの場合と同じ方法で行われます。短時間のあいだ、そのテーブルはあらゆる操作に対して利用できなくなります。

SYSTEM RESTART REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name

SYSTEM RESTORE REPLICA

データは存在している可能性があるが、ZooKeeper のメタデータが失われたレプリカを復元します。

ReplicatedMergeTree の読み取り専用テーブルでのみ動作します。

次のような状況が発生した後に、このクエリを実行できます:

• ZooKeeper ルート / の消失。
• レプリカパス /replicas の消失。
• 個々のレプリカパス /replicas/replica_name/ の消失。

レプリカはローカルで見つかったパーツをアタッチして、それらに関する情報を ZooKeeper に送信します。 メタデータの消失前にレプリカ上に存在していたパーツは、古くなっていない限り他のレプリカから再取得されません（そのため、レプリカの復元は、すべてのデータをネットワーク越しに再ダウンロードすることを意味しません）。

注記

あらゆる状態のパーツは detached/ ディレクトリに移動されます。データ消失前にアクティブ（コミット済み）だったパーツがアタッチされます。

SYSTEM RESTORE DATABASE REPLICA

データは存在している可能性があるが、Zookeeperのメタデータが失われた場合にレプリカを復元します。

構文

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) <- ルートの喪失。

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

例

複数のサーバーでテーブルを作成します。ZooKeeper 内のレプリカのメタデータが失われると、そのテーブルはメタデータがない状態のため読み取り専用としてアタッチされます。最後のクエリはすべてのレプリカで実行する必要があります。

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) <- ルートの喪失。

SYSTEM RESTART REPLICA test;
SYSTEM RESTORE REPLICA test;

別の方法：

SYSTEM RESTORE REPLICA test ON CLUSTER cluster;

SYSTEM RESTART REPLICAS

すべての ReplicatedMergeTreeテーブルに対してZooKeeperセッションの状態を再初期化します。現在の状態を、正とみなすZooKeeper上の状態と比較し、必要に応じてタスクをZooKeeperキューに追加します。

SYSTEM DROP FILESYSTEM CACHE

このコマンドにより、ファイルシステムキャッシュを削除できます。

SYSTEM DROP FILESYSTEM CACHE [ON CLUSTER cluster_name]

SYSTEM SYNC FILE CACHE

注記

負荷が大きく、悪用されるおそれがあります。

sync システムコールを実行します。

SYSTEM SYNC FILE CACHE [ON CLUSTER cluster_name]

SYSTEM LOAD PRIMARY KEY

指定したテーブル、またはすべてのテーブルのプライマリキーをロードします。

SYSTEM LOAD PRIMARY KEY [db.]name

SYSTEM LOAD PRIMARY KEY

SYSTEM UNLOAD PRIMARY KEY

指定したテーブル、またはすべてのテーブルについてプライマリキーをアンロードします。

SYSTEM UNLOAD PRIMARY KEY [db.]name

SYSTEM UNLOAD PRIMARY KEY

リフレッシャブルmaterialized viewの管理

リフレッシャブルmaterialized viewによって実行されるバックグラウンドタスクを制御するためのコマンドです。

これらを使用する際は、system.view_refreshes を監視してください。

SYSTEM REFRESH VIEW

指定した VIEW のスケジュール外リフレッシュを即時に実行します。

SYSTEM REFRESH VIEW [db.]name

SYSTEM WAIT VIEW

現在実行中のリフレッシュが完了するまで待機します。リフレッシュが失敗した場合は例外をスローします。リフレッシュが実行されていない場合は即座に終了し、前回のリフレッシュが失敗している場合は例外をスローします。

SYSTEM STOP [REPLICATED] VIEW, STOP VIEWS

指定したVIEW、またはすべての更新可能なVIEWの定期的な更新を無効化します。更新処理が進行中の場合は、その処理も中断します。

VIEWがReplicatedまたはSharedデータベース内にある場合、STOP VIEWは現在のレプリカにのみ影響し、STOP REPLICATED VIEWはすべてのレプリカに影響します。

SYSTEM STOP VIEW [db.]name

SYSTEM STOP VIEWS

SYSTEM START [REPLICATED] VIEW, START VIEWS

指定された VIEW、またはすべてのリフレッシュ可能な VIEW に対して、定期的なリフレッシュを有効にします。即時のリフレッシュは実行されません。

VIEW が Replicated または Shared データベース内にある場合、START VIEW は STOP VIEW の効果を元に戻し、START REPLICATED VIEW は STOP REPLICATED VIEW の効果を元に戻します。

SYSTEM START VIEW [db.]name

SYSTEM START VIEWS

SYSTEM CANCEL VIEW

現在のレプリカ上で指定されたビューのリフレッシュ処理が進行中であれば、それを中断してキャンセルします。進行中でなければ、何も行いません。

SYSTEM CANCEL VIEW [db.]name

SYSTEM WAIT VIEW

実行中のリフレッシュが完了するまで待機します。リフレッシュが実行されていない場合は、即座に戻ります。直近のリフレッシュ試行が失敗している場合は、エラーを返します。

新しいリフレッシャブルmaterialized viewをEMPTYキーワードなしで作成した直後に、初回リフレッシュの完了を待つために使用できます。

VIEWがReplicatedまたはSharedデータベースにあり、別のレプリカでリフレッシュが実行されている場合、そのリフレッシュが完了するまで待機します。

SYSTEM WAIT VIEW [db.]name