SYSTEM ステートメント
RELOAD EMBEDDED DICTIONARIES
すべての Internal dictionaries を再読み込みします。
デフォルトでは、内部辞書は無効になっています。
内部辞書の更新結果に関わらず、常に Ok.
を返します。
RELOAD DICTIONARIES
成功裏に読み込まれたすべての辞書を再読み込みします。
デフォルトでは、辞書は遅延読み込みされます (dictionaries_lazy_load を参照)。そのため、起動時に自動的に読み込まれるのではなく、最初のアクセス時に dictGet
関数を通じてまたは ENGINE = Dictionary
を持つテーブルから SELECT して初期化されます。SYSTEM RELOAD DICTIONARIES
クエリはそのような辞書を再読み込みします (LOADED)。
辞書の更新結果に関わらず、常に Ok.
を返します。
構文
RELOAD DICTIONARY
辞書 dictionary_name
を完全に再読み込みします。辞書の状態 (LOADED / NOT_LOADED / FAILED) に関わらず、常に再読み込みします。
常に Ok.
を返します。
辞書の状態は、system.dictionaries
テーブルをクエリすることで確認できます。
RELOAD MODELS
このステートメントおよび SYSTEM RELOAD MODEL
は、単に catboost モデルを clickhouse-library-bridge からアンロードします。catboostEvaluate()
関数は、最初のアクセス時にまだ読み込まれていない場合、モデルを読み込みます。
すべての CatBoost モデルをアンロードします。
構文
RELOAD MODEL
model_path
にある CatBoost モデルをアンロードします。
構文
RELOAD FUNCTIONS
すべての登録された 実行可能なユーザー定義関数 またはそのうちの一つを構成ファイルから再読み込みします。
構文
RELOAD ASYNCHRONOUS METRICS
すべての 非同期メトリクス を再計算します。非同期メトリクスは設定 asynchronous_metrics_update_period_s に基づいて定期的に更新されるため、このステートメントを使用して手動で更新する必要は通常ありません。
DROP DNS CACHE
ClickHouse の内部 DNS キャッシュをクリアします。時々 (古い ClickHouse バージョンの場合) インフラストラクチャを変更する際に (別の ClickHouse サーバーの IP アドレスを変更したり、辞書で使用されるサーバーを変更したりする場合) このコマンドを使用する必要があります。
より便利な (自動的な) キャッシュ管理については、disable_internal_dns_cache、dns_cache_max_entries、dns_cache_update_period パラメータを参照してください。
DROP MARK CACHE
マークキャッシュをクリアします。
DROP ICEBERG METADATA CACHE
アイスバーグメタデータキャッシュをクリアします。
DROP REPLICA
ReplicatedMergeTree
テーブルのデッドレプリカを次の構文を使用して削除できます。
クエリは ZooKeeper から ReplicatedMergeTree
レプリカパスを削除します。レプリカがデッドで、そのメタデータが DROP TABLE
よりも ZooKeeper から削除できない場合に便利です。無効な/古いレプリカのみを削除し、ローカルレプリカは削除できません。これには DROP TABLE
を使用してください。DROP REPLICA
はテーブルを削除せず、ディスクからデータやメタデータを削除しません。
最初のものは、database.table
テーブルの 'replica_name'
レプリカのメタデータを削除します。
2つ目は、データベース内のすべてのレプリケートされたテーブルに対して同じことを行います。
3つ目は、ローカルサーバー上のすべてのレプリケートされたテーブルに対して同じことを行います。
4つ目は、テーブルのすべての他のレプリカが削除されたときにデッドレプリカのメタデータを削除するのに便利です。テーブルパスを明示的に指定する必要があります。それは、テーブル作成時の ReplicatedMergeTree
エンジンの最初の引数として渡されたパスと同じでなければなりません。
DROP DATABASE REPLICA
デッドレプリカの Replicated
データベースは次の構文を使用して削除できます。
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
形式の完全なレプリカ名でなければなりません。
DROP UNCOMPRESSED CACHE
解凍されたデータキャッシュをクリアします。
解凍されたデータキャッシュは、クエリ/ユーザー/プロファイルレベルの設定 use_uncompressed_cache
によって有効化/無効化されます。
そのサイズは、サーバーレベルの設定 uncompressed_cache_size
で構成できます。
DROP COMPILED EXPRESSION CACHE
コンパイル済み式キャッシュをクリアします。
コンパイル済み式キャッシュは、クエリ/ユーザー/プロファイルレベルの設定 compile_expressions
によって有効化/無効化されます。
DROP QUERY CONDITION CACHE
クエリ条件キャッシュをクリアします。
DROP QUERY CACHE
クエリキャッシュをクリアします。 タグが指定された場合、指定されたタグを持つクエリキャッシュエントリのみが削除されます。
DROP FORMAT SCHEMA CACHE
format_schema_path
から読み込まれたスキーマのキャッシュをクリアします。
サポートされる形式:
- Protobuf
FLUSH LOGS
バッファリングされたログメッセージをシステムテーブル(例えば、system.query_log)にフラッシュします。主にデバッグに便利です。ほとんどのシステムテーブルはデフォルトのフラッシュ間隔が 7.5 秒です。 これにより、メッセージキューが空であってもシステムテーブルが作成されます。
すべてをフラッシュしたくない場合は、名前またはターゲットテーブルを指定して、一つ以上の個別ログをフラッシュできます。
RELOAD CONFIG
ClickHouse の設定を再読み込みします。設定が ZooKeeper に保存されている場合に使用します。SYSTEM RELOAD CONFIG
は ZooKeeper に保存されている USER
設定を再読み込みせず、users.xml
に保存されている USER
設定のみを再読み込みします。すべての USER
設定を再読み込みするには SYSTEM RELOAD USERS
を使用します。
RELOAD USERS
すべてのアクセスストレージを再読み込みします。これには、users.xml、ローカルディスクアクセスストレージ、ZooKeeper 内のレプリケートされたアクセスストレージが含まれます。
SHUTDOWN
通常、ClickHouse をシャットダウンします(service clickhouse-server stop
/ kill {$pid_clickhouse-server}
のように)。
KILL
ClickHouse プロセスを中断します(kill -9 {$ pid_clickhouse-server}
のように)。
分散テーブルの管理
ClickHouse は 分散 テーブルを管理できます。ユーザーがこれらのテーブルにデータを挿入すると、ClickHouse は最初にクラスター ノードに送信する必要があるデータのキューを作成し、その後非同期で送信します。キュー処理は STOP DISTRIBUTED SENDS
、FLUSH DISTRIBUTED、および START DISTRIBUTED SENDS
クエリを使用して管理できます。また、distributed_foreground_insert
設定を使用して、分散データを同期的に挿入することもできます。
STOP DISTRIBUTED SENDS
分散テーブルへのデータ挿入時のバックグラウンドデータ配信を無効にします。
prefer_localhost_replica
が有効な場合(デフォルト)、データはローカルシャードに挿入されます。
FLUSH DISTRIBUTED
ClickHouse にデータをクラスター ノードに同期的に送信させます。ノードが利用できない場合、ClickHouse は例外をスローし、クエリ実行を停止します。クエリを成功するまで再試行できます。これは、すべてのノードが再オンラインになると発生します。
特定の設定をオーバーライドするために SETTINGS
句を使用することもでき、一時的な制限を回避するのに役立つ場合があります (たとえば、max_concurrent_queries_for_all_users
や max_memory_usage
)。
各保留中のブロックは、最初の INSERT クエリからの設定でディスクに保存されるため、時には設定をオーバーライドしたいことがあります。
START DISTRIBUTED SENDS
分散テーブルへのデータ挿入時のバックグラウンドデータ配信を有効にします。
STOP LISTEN
ソケットを閉じて、指定されたポートと指定されたプロトコルのサーバーへの既存の接続を優雅に終了します。
ただし、対応するプロトコル設定が clickhouse-server 構成に指定されていない場合、このコマンドは効果がありません。
CUSTOM 'protocol'
修飾子が指定された場合、サーバー構成のプロトコルセクションで定義された指定された名前のカスタムプロトコルが停止します。QUERIES ALL [EXCEPT .. [,..]]
修飾子が指定された場合、すべてのプロトコルが停止されますが、EXCEPT
句で指定されたものは除きます。QUERIES DEFAULT [EXCEPT .. [,..]]
修飾子が指定された場合、すべてのデフォルトプロトコルが停止されますが、EXCEPT
句で指定されたものは除きます。QUERIES CUSTOM [EXCEPT .. [,..]]
修飾子が指定された場合、すべてのカスタムプロトコルが停止されますが、EXCEPT
句で指定されたものは除きます。
START LISTEN
指定されたプロトコルで新しい接続の確立を許可します。
ただし、SYSTEM STOP LISTEN コマンドを使用して指定されたポートとプロトコルでサーバーが停止されていない場合、このコマンドは効果がありません。
MergeTree テーブルの管理
ClickHouse は MergeTree テーブル内のバックグラウンド プロセスを管理できます。
STOP MERGES
MergeTree ファミリー内のテーブルのバックグラウンド マージを停止する機能を提供します。
DETACH / ATTACH
テーブルは、すべての MergeTree テーブルのマージが停止している場合でも、テーブルのバックグラウンド マージを開始します。
START MERGES
MergeTree ファミリー内のテーブルのバックグラウンド マージを開始する機能を提供します。
STOP TTL MERGES
MergeTree ファミリー内のテーブルに対して、TTL 式 に基づいて古いデータをバックグラウンドで削除する機能を提供します。
テーブルが存在しない場合やテーブルが MergeTree エンジンを持っていない場合でも、Ok.
を返します。データベースが存在しない場合はエラーを返します。
START TTL MERGES
MergeTree ファミリー内のテーブルについて、TTL 式 に基づいて古いデータをバックグラウンドで削除する機能を提供します。
テーブルが存在しない場合でも Ok.
を返します。データベースが存在しない場合はエラーを返します。
STOP MOVES
TTL テーブル式での TO VOLUME または TO DISK 句 に基づいて MergeTree ファミリー内のテーブルに対して、バックグラウンドでデータを移動する機能を提供します。
テーブルが存在しない場合でも Ok.
を返します。データベースが存在しない場合はエラーを返します。
START MOVES
TTL テーブル式での TO VOLUME および TO DISK 句 に基づいて MergeTree ファミリー内のテーブルに対して、バックグラウンドでデータを移動する機能を提供します。
テーブルが存在しない場合でも Ok.
を返します。データベースが存在しない場合はエラーを返します。
SYSTEM UNFREEZE
指定された名前のフローズンバックアップをすべてのディスクからクリアします。部分的にALTER TABLE table_name UNFREEZE WITH NAME でのフリーペアについては、詳細を参照してください。
WAIT LOADING PARTS
テーブルのすべての非同期ロードデータ部分 (古いデータ部分) が読み込まれるまで待ちます。
ReplicatedMergeTree テーブルの管理
ClickHouse は ReplicatedMergeTree テーブルにおけるバックグラウンドのレプリケーション関連プロセスを管理できます。
STOP FETCHES
ReplicatedMergeTree
ファミリー内のテーブルのために挿入された部分のバックグラウンドフェッチを停止する機能を提供します。
テーブルエンジンに関わらず常に Ok.
を返します。テーブルやデータベースが存在しない場合でも。
START FETCHES
ReplicatedMergeTree
ファミリー内のテーブルのために挿入された部分のバックグラウンドフェッチを開始する機能を提供します。
テーブルエンジンに関わらず常に Ok.
を返します。テーブルやデータベースが存在しない場合でも。
STOP REPLICATED SENDS
ReplicatedMergeTree
ファミリー内のテーブルのために新しく挿入された部分のバックグラウンド送信をクラスター内の他のレプリカに停止する機能を提供します。
START REPLICATED SENDS
ReplicatedMergeTree
ファミリー内のテーブルのために新しく挿入された部分のバックグラウンド送信をクラスター内の他のレプリカに開始する機能を提供します。
STOP REPLICATION QUEUES
ZooKeeper に保存されているレプリケーションキューからのバックグラウンド フェッチタスクを停止する機能を提供します。可能なバックグラウンドタスクの種類 - マージ、フェッチ、ミューテーション、ON CLUSTER 句付きの DDL ステートメント:
START REPLICATION QUEUES
ZooKeeper に保存されているレプリケーションキューからのバックグラウンド フェッチタスクを開始する機能を提供します。可能なバックグラウンドタスクの種類 - マージ、フェッチ、ミューテーション、ON CLUSTER 句付きの DDL ステートメント:
STOP PULLING REPLICATION LOG
ReplicatedMergeTree
テーブルのレプリケーションログからの新しいエントリをレプリケーションキューに読み込むのを停止します。
START PULLING REPLICATION LOG
SYSTEM STOP PULLING REPLICATION LOG
をキャンセルします。
SYNC REPLICA
ReplicatedMergeTree
テーブルがクラスター内の他のレプリカと同期するまで待ちますが、receive_timeout
秒を超えません。
このステートメントを実行した後、[db.]replicated_merge_tree_family_table_name
はコマンドを共通のレプリケートされたログから自分のレプリケーションキューにフェッチし、その後クエリはレプリカがフェッチしたコマンドを処理するのを待ちます。以下の修飾子がサポートされています。
STRICT
修飾子が指定された場合、クエリはレプリケーションキューが空になるのを待ちます。STRICT
バージョンは、レプリケーションキューで新しいエントリが常に現れる場合、成功しない場合があります。LIGHTWEIGHT
修飾子が指定された場合、クエリはGET_PART
、ATTACH_PART
、DROP_RANGE
、REPLACE_RANGE
およびDROP_PART
エントリが処理されるのを待ちます。 さらに、LIGHTWEIGHT 修飾子はオプションの FROM 'srcReplicas' 句をサポートしており、srcReplicas
はソースレプリカ名のカンマ区切りのリストです。この拡張により、特定のソースレプリカからのレプリケーションタスクのみに焦点を当てることで、よりターゲットを絞った同期が可能になります。PULL
修飾子が指定された場合、クエリはZooKeeper から新しいレプリケーションキューエントリをプルしますが、何も処理されるのを待ちません。
SYNC DATABASE REPLICA
指定された replicated database がそのデータベースの DDL キューからすべてのスキーマ変更を適用するまで待ちます。
構文
RESTART REPLICA
ReplicatedMergeTree
テーブルの Zookeeper セッションの状態を再初期化する機能を提供します。現在の状態をソースとして Zookeeper と比較し、必要に応じて Zookeeper キューにタスクを追加します。
Zookeeper データに基づいてレプリケーションキューの初期化は、ATTACH TABLE
ステートメントと同じ方法で行われます。一時的に、テーブルは操作を受け付けません。
RESTORE REPLICA
データが [可能性がある] が Zookeeper メタデータが失われた場合はレプリカを復元します。
読み取り専用の ReplicatedMergeTree
テーブルでのみ動作します。
次の後にクエリを実行できます。
- ZooKeeper ルート
/
の損失。 - レプリカパス
/replicas
の損失。 - 個々のレプリカパス
/replicas/replica_name/
の損失。
レプリカはローカルで見つかったパーツをアタッチし、それらについての情報を Zookeeper に送信します。メタデータが失われる前にレプリカに存在するパーツは、他のものから再取得されません (したがって、レプリカの復元はネットワーク経由でのすべてのデータを再ダウンロードすることを意味しません)。
すべての状態のパーツは detached/
フォルダに移動されます。データ損失の前にアクティブだったパーツ (コミットされた) はアタッチされます。
構文
代替構文:
例
複数のサーバーでテーブルを作成します。レプリカのメタデータが ZooKeeper で失われた後、メタデータが不足しているため、テーブルは読み取り専用としてアタッチされます。この最後のクエリは、すべてのレプリカで実行する必要があります。
別の方法は:
RESTART REPLICAS
すべての ReplicatedMergeTree
テーブルについて、Zookeeper セッションの状態を再初期化する機能を提供します。現在の状態を Zookeeper と比較し、必要に応じて Zookeeper キューにタスクを追加します。
DROP FILESYSTEM CACHE
ファイルシステムキャッシュを削除することを許可します。
SYNC FILE CACHE
これは非常に重く、誤用の可能性があります。
同期のシステムコールを行います。
LOAD PRIMARY KEY
指定されたテーブルまたはすべてのテーブルの主キーを読み込みます。
UNLOAD PRIMARY KEY
指定されたテーブルまたはすべてのテーブルの主キーをアンロードします。
リフレッシュ可能なマテリアライズドビューの管理
Refreshable Materialized Views によって実行されるバックグラウンドタスクを制御するコマンド
使用中は system.view_refreshes
に注意してください。
REFRESH VIEW
指定されたビューの即時スケジュール外リフレッシュをトリガーします。
REFRESH VIEW
現在実行中のリフレッシュが完了するのを待ちます。リフレッシュが失敗した場合は例外をスローします。リフレッシュが実行中でない場合、すぐに完了し、前回のリフレッシュが失敗した場合は例外をスローします。
STOP [REPLICATED] VIEW, STOP VIEWS
指定されたビューまたはすべてのリフレッシュ可能なビューの定期的なリフレッシュを無効にします。リフレッシュが進行中の場合は、それもキャンセルします。
ビューがレプリケートされたまたは共有データベースに存在する場合、STOP VIEW
は現在のレプリカにのみ影響し、STOP REPLICATED VIEW
はすべてのレプリカに影響します。
START [REPLICATED] VIEW, START VIEWS
指定されたビューまたはすべてのリフレッシュ可能なビューの定期的なリフレッシュを有効にします。即時リフレッシュはトリガーされません。
ビューがレプリケートされたまたは共有データベースに存在する場合、START VIEW
は STOP VIEW
の効果を元に戻し、START REPLICATED VIEW
は STOP REPLICATED VIEW
の効果を元に戻します。
CANCEL VIEW
指定されたビューに対して現在リフレッシュが進行中の場合、これを中断してキャンセルします。それ以外の場合は何もしません。
SYSTEM WAIT VIEW
実行中のリフレッシュが完了するのを待ちます。リフレッシュが実行中でない場合、即座に戻ります。最新のリフレッシュ試行が失敗した場合は、エラーを報告します。
新しいリフレッシュ可能なマテリアライズドビューを作成した直後に使用し(EMPTY キーワードなしで)、初期リフレッシュが完了するのを待つことができます。
ビューがレプリケートされたまたは共有データベースに存在し、他のレプリカでリフレッシュが実行中である場合、他のレプリカでそのリフレッシュが完了するのを待ちます。