SYSTEM RELOAD EMBEDDED DICTIONARIES
Ok.を返します。
SYSTEM RELOAD DICTIONARIES
SYSTEM RELOAD DICTIONARIES クエリは、ステータスが LOADED の Dictionary (system.dictionaries の status カラムを参照) 、つまり過去に正常に読み込まれたことのある Dictionary を再読み込みします。
デフォルトでは、Dictionary は遅延読み込みされます (dictionaries_lazy_load を参照) 。そのため、起動時に自動で読み込まれるのではなく、dictGet 関数を使用したとき、または ENGINE = Dictionary のテーブルに対する SELECT による初回アクセス時に初期化されます。
構文
SYSTEM RELOAD DICTIONARY
dictionary_name を、その状態 (LOADED / NOT_LOADED / FAILED) にかかわらず完全に再読み込みします。
Dictionary の更新結果にかかわらず、常に Ok. を返します。
system.dictionaries テーブルへのクエリで確認できます。
SYSTEM RELOAD MODELS
このステートメントおよび
SYSTEM RELOAD MODEL は、clickhouse-library-bridge から CatBoost モデルをアンロードするだけです。関数 catboostEvaluate()
は、モデルがまだロードされていない場合、最初にアクセスされた時点でモデルをロードします。SYSTEM RELOAD MODEL
model_path にある CatBoost モデルをアンロードします。
構文
SYSTEM RELOAD FUNCTIONS
SYSTEM RELOAD ASYNCHRONOUS METRICS
SYSTEM CLEAR|DROP DNS CACHE
disable_internal_dns_cache、dns_cache_max_entries、dns_cache_update_period パラメータを参照してください。
SYSTEM CLEAR|DROP MARK CACHE
SYSTEM CLEAR|DROP ICEBERG METADATA CACHE
SYSTEM CLEAR|DROP AVRO SCHEMA CACHE
AvroConfluent フォーマットで使用される、URL ごとの Confluent スキーマレジストリの cache をクリアします。これにより、スキーマ取得 cache (id → schema) とスキーマ登録 cache (subject + schema → id) の両方が削除されるため、以降の読み取りと書き込みではレジストリサーバーが参照されます。これは、レジストリ側でスキーマが削除または書き換えられた場合や、テストでレジストリの冪等性を検証する際に有用です。
SYSTEM DROP PARQUET METADATA CACHE
SYSTEM CLEAR|DROP TEXT INDEX CACHES
SYSTEM CLEAR TEXT INDEX HEADER CACHE,SYSTEM CLEAR TEXT INDEX DICTIONARY CACHE, またはSYSTEM CLEAR TEXT INDEX POSTINGS CACHE
SYSTEM DROP REPLICA
ReplicatedMergeTree テーブルの停止したレプリカは、次の構文で削除できます。
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 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 CLEAR|DROP UNCOMPRESSED CACHE
use_uncompressed_cache で有効または無効にできます。
そのサイズは、サーバーレベルの設定 uncompressed_cache_size で構成できます。
SYSTEM CLEAR|DROP COMPILED EXPRESSION CACHE
compile_expressions で有効/無効を切り替えられます。
SYSTEM CLEAR|DROP QUERY CONDITION CACHE
SYSTEM CLEAR|DROP QUERY CACHE
SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE
format_schema_path から読み込まれたスキーマのキャッシュをクリアします。
サポートされる対象:
- Protobuf: インポートされた Protobuf メッセージ定義をメモリから削除します。
- Files:
format_schema_sourceがqueryに設定されているときに生成され、format_schema_pathにローカルに保存されたキャッシュ済みスキーマファイルを削除します。 注: 対象を指定しない場合は、両方のキャッシュがクリアされます。
SYSTEM FLUSH LOGS
SYSTEM RELOAD CONFIG
SYSTEM RELOAD CONFIG では、ZooKeeper に保存された USER 設定は再読み込みされない点に注意してください。再読み込みされるのは、users.xml に保存された USER 設定のみです。すべての USER 設定を再読み込みするには、SYSTEM RELOAD USERS を使用します。
SYSTEM RELOAD USERS
SYSTEM の停止
service clickhouse-server stop / kill {$pid_clickhouse-server} など)
SYSTEM KILL
kill -9 {$ pid_clickhouse-server} のように)
SYSTEM INSTRUMENT
ENABLE_XRAY=1 を指定して ClickHouse をビルドした場合に利用できる LLVM の XRay 機能を使用して、インストルメンテーションポイントを管理します。
これにより、ソースコードを変更することなく、最小限のオーバーヘッドで本番環境でのデバッグやプロファイリングを行えます。
インストルメンテーションポイントが追加されていない場合、性能への影響はほぼありません。これは、200 命令を超える関数のプロローグとエピローグに、近くのアドレスへの追加ジャンプが 1 つ挿入されるだけだからです。
SYSTEM INSTRUMENT ADD
system.instrumentation システムテーブルで確認できます。同じ関数に複数のハンドラーを追加でき、それらはインストルメンテーションを追加した順序で実行されます。
インストルメントする関数は、system.symbols システムテーブルから取得できます。
関数に追加できるハンドラーには、3 種類あります。
構文
FUNCTION は QueryMetricLog::startQuery のような関数、またはその一部分を表し、ハンドラーは以下のいずれかです
LOG
ENTRY または EXIT 時点のスタックトレースを出力します。
SLEEP
ENTRY または EXIT のいずれかで、一定の秒数だけスリープします:
PROFILE
ENTRY から EXIT までにかかった時間を測定します。
プロファイリング結果は system.trace_log に保存され、
Chrome Event Trace Format に変換できます。
SYSTEM INSTRUMENT REMOVE
ALL パラメータを使用して、これらすべてを指定できます:
system.instrumentationシステムテーブルから取得できます。
分散テーブルの管理
STOP DISTRIBUTED SENDS、FLUSH DISTRIBUTED、および START DISTRIBUTED SENDS クエリで管理できます。また、distributed_foreground_insert 設定を使用して、分散データを同期的に挿入することもできます。
SYSTEM STOP DISTRIBUTED SENDS
prefer_localhost_replica が有効 (デフォルトで有効) な場合でも、データはローカル分片に挿入されます。SYSTEM FLUSH DISTRIBUTED
SETTINGS 句を使って一部の設定を上書きすることもできます。これは、max_concurrent_queries_for_all_users や max_memory_usage などの一時的な制限を回避するのに役立ちます。
保留中の各ブロックは、最初の INSERT クエリの設定を引き継いでディスクに保存されるため、場合によってはその設定を上書きしたいことがあります。
SYSTEM START DISTRIBUTED SENDS
SYSTEM STOP LISTEN
CUSTOM 'protocol'modifier が指定されている場合、サーバー設定の protocols セクションで定義された、指定した名前のカスタムプロトコルが停止されます。QUERIES ALL [EXCEPT .. [,..]]modifier が指定されている場合、EXCEPT句で指定されたものを除き、すべてのプロトコルが停止されます。QUERIES DEFAULT [EXCEPT .. [,..]]modifier が指定されている場合、EXCEPT句で指定されたものを除き、すべてのデフォルトプロトコルが停止されます。QUERIES CUSTOM [EXCEPT .. [,..]]modifier が指定されている場合、EXCEPT句で指定されたものを除き、すべてのカスタムプロトコルが停止されます。
SYSTEM START LISTEN
SYSTEM STOP LISTEN コマンドで停止されていない場合、このコマンドは何の効果もありません。
MergeTreeテーブルの管理
SYSTEM STOP MERGES
DETACH / ATTACH テーブルを実行すると、たとえそれ以前にすべての MergeTree テーブルでマージが停止されていた場合でも、そのテーブルのバックグラウンドマージが開始されます。SYSTEM START MERGES
SYSTEM STOP TTL MERGES
Ok. を返します。データベースが存在しない場合はエラーを返します。
SYSTEM START TTL MERGES
Ok. を返します。データベースが存在しない場合はエラーを返します。
SYSTEM STOP MOVES
Ok. を返します。データベースが存在しない場合はエラーを返します。
SYSTEM START MOVES
Ok. を返します。データベースが存在しない場合はエラーを返します。
SYSTEM SYSTEM UNFREEZE
SYSTEM WAIT LOADING PARTS
ReplicatedMergeTree テーブルの管理
SYSTEM STOP FETCHES
ReplicatedMergeTree ファミリーのテーブルで、挿入されたパーツに対するバックグラウンドフェッチを停止できます。
テーブルエンジンに関係なく、またテーブルやデータベースが存在しない場合でも、常に Ok. を返します。
SYSTEM START FETCHES
ReplicatedMergeTree ファミリーのテーブルで、挿入されたパーツに対するバックグラウンドフェッチを開始できます。
テーブルエンジンに関係なく、またテーブルやデータベースが存在しない場合でも、常に Ok. を返します。
SYSTEM STOP REPLICATED SENDS
ReplicatedMergeTree ファミリーのテーブルで、新たに挿入されたパーツをクラスター内の他のレプリカに送信するバックグラウンド処理を停止できます。
SYSTEM START REPLICATED SENDS
ReplicatedMergeTree ファミリーのテーブルについて、新しく挿入されたパーツをクラスター内の他のレプリカへバックグラウンドで送信する処理を開始できます。
SYSTEM STOP REPLICATION QUEUES
ReplicatedMergeTree ファミリーのテーブルについて、ZooKeeper に保存されているレプリケーションキュー内のバックグラウンド fetch タスクを停止できます。対象となるバックグラウンドタスクの種類は、merges、フェッチ、mutation、ON CLUSTER 句を含む DDL ステートメントです。
SYSTEM START REPLICATION QUEUES
ReplicatedMergeTree ファミリーのテーブルに対して、ZooKeeper に保存されているレプリケーションキューからバックグラウンドのフェッチタスクを開始できます。実行可能なバックグラウンドタスクの種類は、マージ、フェッチ、ミューテーション、ON CLUSTER 句を伴う DDL ステートメントです:
SYSTEM STOP PULLING REPLICATION LOG
ReplicatedMergeTree テーブルで、レプリケーションログからレプリケーションキューへの新しいエントリの取り込みを停止します。
SYSTEM START PULLING REPLICATION LOG
SYSTEM STOP PULLING REPLICATION LOG の効果を取り消します。
SYSTEM SYNC REPLICA
ReplicatedMergeTree テーブルがクラスター内の他のレプリカと同期されるまで待機します。ただし、待機時間は receive_timeout 秒を超えません。
[db.]replicated_merge_tree_family_table_name は共通の replicated log からコマンドを自身のレプリケーションキューに取り込み、その後クエリはレプリカが取り込まれたすべてのコマンドを処理し終えるまで待機します。次の修飾子がサポートされています。
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
SYSTEM RESTART REPLICA
ReplicatedMergeTree テーブルの ZooKeeper セッションの状態を再初期化できます。現在の状態を正しい情報源である ZooKeeper と照合し、必要に応じてタスクを ZooKeeper のキューに追加します。
ZooKeeper のデータに基づくレプリケーションキューの初期化は、ATTACH TABLE ステートメントと同じ方法で行われます。短時間、テーブルは一切の操作を受け付けなくなります。
SYSTEM RESTORE REPLICA
ReplicatedMergeTree テーブルでのみ動作します。
次のような場合にクエリを実行できます。
- ZooKeeper ルート
/が失われた場合。 - レプリカのパス
/replicasが失われた場合。 - 個々のレプリカのパス
/replicas/replica_name/が失われた場合。
すべての状態のパーツは
detached/ フォルダーに移動されます。データ消失前にアクティブだった (コミット済みの) パーツがアタッチされます。SYSTEM RESTORE DATABASE REPLICA
SYSTEM RESTART REPLICAS
ReplicatedMergeTree テーブルについて、ZooKeeper セッションの状態を再初期化できます。現在の状態を信頼できる情報源である ZooKeeper と比較し、必要に応じて ZooKeeper のキューにタスクを追加します
SYSTEM CLEAR|DROP FILESYSTEM CACHE
SYSTEM SYNC FILE CACHE
負荷が高く、誤用されるおそれがあります。
sync システムコールを実行します。
SYSTEM LOAD PRIMARY KEY
SYSTEM UNLOAD PRIMARY KEY
リフレッシュ可能なマテリアライズドビューの管理
system.view_refreshes を確認してください。
SYSTEM STOP [REPLICATED] VIEW, STOP VIEWS
STOP VIEW は現在のレプリカにのみ影響し、STOP REPLICATED VIEW はすべてのレプリカに影響します。
停止状態はサーバーの再起動後も維持されません。再起動後、ビューは設定されたリフレッシュスケジュールに従って再開されます。
Replicated または Shared データベースでは、
SYSTEM STOP VIEW は現在のレプリカにのみ影響します。すべてのレプリカでリフレッシュを停止するには、SYSTEM STOP REPLICATED VIEW を使用してください。SYSTEM START [REPLICATED] VIEW, START VIEWS
START VIEW は STOP VIEW の効果を打ち消し、START REPLICATED VIEW は STOP REPLICATED VIEW の効果を打ち消します。START VIEW は PAUSE VIEW の効果も打ち消します。
SYSTEM PAUSE VIEW, PAUSE VIEWS
SYSTEM STOP VIEW とは異なり、SYSTEM PAUSE VIEW はすでに進行中のリフレッシュを中断しません。実行中のリフレッシュは完了まで継続され、以降のリフレッシュのみが停止されます。
元に戻すには、SYSTEM START VIEW または SYSTEM START VIEWS を使用します。
一時停止状態はサーバーの再起動後には保持されません。再起動後、ビューは設定されたリフレッシュスケジュールに従って再開されます。
Replicated または Shared データベースでは、
SYSTEM PAUSE VIEW は現在のレプリカにのみ影響します。