SYSTEM

すべての内部Dictionaryを再読み込みします。 デフォルトでは、内部Dictionaryは無効になっています。 内部Dictionaryの更新結果にかかわらず、常にOk.を返します。

SYSTEM RELOAD DICTIONARIES クエリは、ステータスが LOADED の Dictionary (system.dictionaries の status カラムを参照) 、つまり過去に正常に読み込まれたことのある Dictionary を再読み込みします。 デフォルトでは、Dictionary は遅延読み込みされます (dictionaries_lazy_load を参照) 。そのため、起動時に自動で読み込まれるのではなく、dictGet 関数を使用したとき、または ENGINE = Dictionary のテーブルに対する SELECT による初回アクセス時に初期化されます。

構文

SYSTEM RELOAD DICTIONARIES [ON CLUSTER cluster_name]

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;

Dictionary dictionary_name をアンロードし、Dictionary の状態が LOADED の場合はメモリを解放します。 Dictionary は必要になった時点で再度遅延読み込みされます。

SYSTEM UNLOAD DICTIONARY dictionary_name

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

SELECT name, status FROM system.dictionaries;

SYSTEM UNLOAD DICTIONARIES クエリは、LOADED ステータスのすべてのDictionary (system.dictionaries の status カラムを参照) 、つまり以前に正常にロードされたDictionaryをアンロードします。

SYSTEM UNLOAD DICTIONARIES

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

構文

SYSTEM RELOAD MODELS [ON CLUSTER cluster_name]

model_path にある CatBoost モデルをアンロードします。

構文

SYSTEM RELOAD MODEL [ON CLUSTER cluster_name] <model_path>

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

構文

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

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

SYSTEM RELOAD ASYNCHRONOUS METRICS [ON CLUSTER cluster_name]

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

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

mark cache をクリアします。

メモリ内に MergeTree テーブルの主キーを保持しているプライマリインデックスキャッシュをクリアします。 そのサイズは、サーバーレベルの設定 primary_index_cache_size で設定します。

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

AvroConfluent フォーマットで使用される、URL ごとの Confluent スキーマレジストリの cache をクリアします。これにより、スキーマ取得 cache (id → schema) とスキーマ登録 cache (subject + schema → id) の両方が削除されるため、以降の読み取りと書き込みではレジストリサーバーが参照されます。これは、レジストリ側でスキーマが削除または書き換えられた場合や、テストでレジストリの冪等性を検証する際に有用です。

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

解析済みの Paimon メタデータファイル (マニフェストリストとマニフェスト) のインメモリキャッシュをクリアします。

関数 pointInPolygon で使用される、前処理済みの定数ポリゴンの cache をクリアします。設定されたサイズ上限 (サーバー設定 point_in_polygon_cache_size) は変更されないため、その後も cache は引き続きエントリを受け付けます。代わりに cache を無効にするには、point_in_polygon_cache_size を 0 に設定してください。

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

これらのキャッシュを個別にクリアする場合は、次を実行します。

• SYSTEM CLEAR TEXT INDEX TOKENS CACHE,
• SYSTEM CLEAR TEXT INDEX HEADER CACHE, または
• SYSTEM CLEAR TEXT INDEX POSTINGS CACHE

セカンダリ (データスキッピング) 索引のマークキャッシュをクリアします。

セカンダリ (データスキッピング) 索引の非圧縮ブロックのキャッシュをクリアします。

メモリマップドファイルのキャッシュをクリアします。

ユーザー空間ページキャッシュ、つまり基盤となるストレージから読み取ったデータを保持する ClickHouse 独自のインメモリキャッシュをクリアします。

ベクトル類似度索引キャッシュをクリアします。

外部への接続に使用される HTTP 接続プールの cache をクリアします。

S3クライアントのキャッシュをクリアします。

テーブルのマークを マークキャッシュ に読み込みます。セカンダリ索引のマークも マークキャッシュ に読み込まれます。

SYSTEM PREWARM MARK CACHE [ON CLUSTER cluster_name] [db.]table

MergeTree テーブルのプライマリインデックスを、プライマリインデックスキャッシュ に読み込みます。

SYSTEM PREWARM PRIMARY INDEX CACHE [ON CLUSTER cluster_name] [db.]table

指定したディスクのメタデータキャッシュをクリアします。

SYSTEM DROP DISK METADATA CACHE <disk_name>

ClickHouse のファイルシステムキャッシュのインメモリ状態を、実際にディスク上に存在するキャッシュファイルとリコンサイルし、キャッシュされた各ファイルセグメントの cache_name、path、およびダウンロード済みの size を返します。オプションでキャッシュ名を指定すると、この操作の対象を単一のキャッシュに限定できます。

SYSTEM SYNC FILESYSTEM CACHE ['<cache_name>']

分散キャッシュを削除します。分散キャッシュサーバーへのキャッシュ済み接続のみを削除するには CONNECTIONS を使用するか、特定の1台のサーバーを対象にするにはサーバー識別子を指定します。

SYSTEM DROP DISTRIBUTED CACHE [CONNECTIONS | 'server_id']

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 引数に渡したパスと同一でなければなりません。

使用不能になった 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 フォーマットの完全なレプリカ名でなければなりません。

非圧縮データcacheをクリアします。 非圧縮データcacheは、クエリ/USER/profile レベルの設定 use_uncompressed_cache で有効または無効にできます。 そのサイズは、サーバーレベルの設定 uncompressed_cache_size で構成できます。

コンパイル済み expression cache をクリアします。 コンパイル済み expression cache は、クエリ/ユーザー/プロファイルレベルの設定 compile_expressions で有効/無効を切り替えられます。

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

暗号化ヘッダー cache をクリアします。この cache には暗号化ファイルの先頭から読み取った暗号化ヘッダーが保持されており、それらを再度読み込まずに済むよう、実験的な use_reader_executor 読み取りパスで使用されます。サイズは encryption_header_cache_size サーバー設定で構成されます。

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

query cacheをクリアします。 タグが指定されている場合は、そのタグが付いたquery cacheのエントリのみが削除されます。

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

サポートされる対象:

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

SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE [FOR Protobuf/Files]

バッファされたログメッセージをシステムテーブル (例: system.query_log) にフラッシュします。ほとんどのシステムテーブルのデフォルトのフラッシュ間隔は 7.5 秒のため、主にデバッグ用途で役立ちます。 また、メッセージキューが空の場合でもシステムテーブルが作成されます。

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

すべてをフラッシュしたくない場合は、名前またはターゲットテーブルを指定して、個別のログを 1 つ以上フラッシュできます。

SYSTEM FLUSH LOGS query_log, system.query_views_log;

ClickHouse の設定を再読み込みします。設定が ZooKeeper に保存されている場合に使用します。SYSTEM RELOAD CONFIG では、ZooKeeper に保存された USER 設定は再読み込みされない点に注意してください。再読み込みされるのは、users.xml に保存された USER 設定のみです。すべての USER 設定を再読み込みするには、SYSTEM RELOAD USERS を使用します。

SYSTEM RELOAD CONFIG [ON CLUSTER cluster_name]

users.xml、ローカルディスクのアクセスストレージ、replicated (ZooKeeper 内) のアクセスストレージを含む、すべてのアクセスストレージを再読み込みします。

SYSTEM RELOAD USERS [ON CLUSTER cluster_name]

通常の方法で ClickHouse を停止します (service clickhouse-server stop / kill {$pid_clickhouse-server} など)

ClickHouse プロセスを強制終了します (kill -9 {$ pid_clickhouse-server} のように)

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

新しいインストルメンテーションポイントを追加します。インストルメントされた関数は、system.instrumentation システムテーブルで確認できます。同じ関数に複数のハンドラーを追加でき、それらはインストルメンテーションを追加した順序で実行されます。 インストルメントする関数は、system.symbols システムテーブルから取得できます。

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

構文

SYSTEM INSTRUMENT ADD FUNCTION HANDLER [ARGUMENTS]

ここで、FUNCTION は QueryMetricLog::startQuery のような関数、またはその一部分を表し、ハンドラーは以下のいずれかです

引数として指定したテキストと、関数の ENTRY または EXIT 時点のスタックトレースを出力します。

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'

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

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

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

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

関数の ENTRY から EXIT までにかかった時間を測定します。 プロファイリング結果は system.trace_log に保存され、 Chrome Event Trace Format に変換できます。

SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' PROFILE

次の方法で、単一のインストルメンテーションポイントを削除できます。

SYSTEM INSTRUMENT REMOVE ID

ALL キーワードを使用して、これらすべてを指定できます:

SYSTEM INSTRUMENT REMOVE ALL

サブクエリから得られる ID の集合:

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

または、指定したfunction_nameに一致するすべてのインストルメンテーションポイント:

SYSTEM INSTRUMENT REMOVE 'QueryMetricLog::startQuery'

インストルメンテーションポイントに関する情報は、system.instrumentationシステムテーブルから取得できます。

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

分散テーブルへのデータ挿入時に行われるバックグラウンドのデータ分散処理を無効にします。

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

ClickHouse がデータをクラスターのノードへ同期的に送信するよう強制します。いずれかのノードが利用できない場合、ClickHouse は例外をスローしてクエリの実行を停止します。クエリは成功するまで再試行できます。これは、すべてのノードが再びオンラインになれば成功します。

また、SETTINGS 句を使って一部の設定を上書きすることもできます。これは、max_concurrent_queries_for_all_users や max_memory_usage などの一時的な制限を回避するのに役立ちます。

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

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

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

ソケットを閉じ、指定したプロトコルの指定ポートでサーバーへの既存の接続を正常に終了します。

ただし、対応するプロトコル設定が 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' modifier が指定されている場合、サーバー設定の protocols セクションで定義された、指定した名前のカスタムプロトコルが停止されます。
• QUERIES ALL [EXCEPT .. [,..]] modifier が指定されている場合、EXCEPT 句で指定されたものを除き、すべてのプロトコルが停止されます。
• QUERIES DEFAULT [EXCEPT .. [,..]] modifier が指定されている場合、EXCEPT 句で指定されたものを除き、すべてのデフォルトプロトコルが停止されます。
• QUERIES CUSTOM [EXCEPT .. [,..]] modifier が指定されている場合、EXCEPT 句で指定されたものを除き、すべてのカスタムプロトコルが停止されます。

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

ただし、指定したポートおよびプロトコルのサーバーが 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']

ClickHouse では、MergeTree テーブルのバックグラウンド処理を管理できます。

MergeTree familyのテーブルのバックグラウンドマージを停止できます。

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

MergeTree familyのテーブルでバックグラウンドマージを開始できます。

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

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

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

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

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

MergeTree family のテーブルに対して、TTLテーブル式の TO VOLUME 句または TO DISK 句に基づくバックグラウンドでのデータ移動を停止できます。 テーブルが存在しない場合でも Ok. を返します。データベースが存在しない場合はエラーを返します。

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

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

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

指定した名前の凍結バックアップを、すべてのディスクから削除します。個別のパーツの凍結解除の詳細については、ALTER TABLE table_name UNFREEZE WITH NAME を参照してください。

SYSTEM UNFREEZE WITH NAME <backup_name>

テーブル内の非同期で読み込み中のすべてのデータパーツ (古いデータパーツ) が読み込み完了になるまで待機します。

SYSTEM WAIT LOADING PARTS [ON CLUSTER cluster_name] [db.]merge_tree_family_table_name

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

ReplicatedMergeTree ファミリーのテーブルで、挿入されたパーツに対するバックグラウンドフェッチを停止できます。 テーブルエンジンに関係なく、またテーブルやデータベースが存在しない場合でも、常に Ok. を返します。

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

ReplicatedMergeTree ファミリーのテーブルで、挿入されたパーツに対するバックグラウンドフェッチを開始できます。 テーブルエンジンに関係なく、またテーブルやデータベースが存在しない場合でも、常に Ok. を返します。

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

ReplicatedMergeTree ファミリーのテーブルで、新たに挿入されたパーツをクラスター内の他のレプリカに送信するバックグラウンド処理を停止できます。

SYSTEM STOP REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

ReplicatedMergeTree ファミリーのテーブルについて、新しく挿入されたパーツをクラスター内の他のレプリカへバックグラウンドで送信する処理を開始できます。

SYSTEM START REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

ReplicatedMergeTree ファミリーのテーブルについて、ZooKeeper に保存されているレプリケーションキュー内のバックグラウンド fetch タスクを停止できます。対象となるバックグラウンドタスクの種類は、merges、フェッチ、mutation、ON CLUSTER 句を含む DDL ステートメントです。

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

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

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

ReplicatedMergeTree テーブルで、レプリケーションログからレプリケーションキューへの新しいエントリの取り込みを停止します。

SYSTEM STOP PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

SYSTEM STOP PULLING REPLICATION LOG の効果を取り消します。

SYSTEM START PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]

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 は共通の 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 から新しいレプリケーションキューのエントリを取得しますが、何かが処理されるのを待機することはありません。

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

構文

SYSTEM SYNC DATABASE REPLICA replicated_database_name;

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

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

データが[存在している可能性がある]にもかかわらず、ZooKeeper のメタデータが失われた場合にレプリカを復元します。

readonly の ReplicatedMergeTree テーブルでのみ動作します。

次のような場合にクエリを実行できます。

• ZooKeeper ルート / が失われた場合。
• レプリカのパス /replicas が失われた場合。
• 個々のレプリカのパス /replicas/replica_name/ が失われた場合。

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

データは[存在している可能性がある]ものの、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;

すべての ReplicatedMergeTree テーブルについて、ZooKeeper セッションの状態を再初期化できます。現在の状態を信頼できる情報源である ZooKeeper と比較し、必要に応じて ZooKeeper のキューにタスクを追加します

ファイルシステムキャッシュをクリアできます。

SYSTEM CLEAR FILESYSTEM CACHE [ON CLUSTER cluster_name]

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

SYSTEM SYNC FILE CACHE [ON CLUSTER cluster_name]

指定したtable、またはすべてのtableの主キーを読み込みます。

SYSTEM LOAD PRIMARY KEY [db.]name

SYSTEM LOAD PRIMARY KEY

指定したテーブル、またはすべてのテーブルの主キーをアンロードします。

SYSTEM UNLOAD PRIMARY KEY [db.]name

SYSTEM UNLOAD PRIMARY KEY

リフレッシュ可能なマテリアライズドビュー が実行するバックグラウンドタスクを制御するコマンドです。

使用中は、system.view_refreshes を確認してください。

指定したビュー、またはすべてのリフレッシュ可能なビューの定期リフレッシュを停止します。リフレッシュが進行中の場合は、それもキャンセルします。

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

SYSTEM STOP VIEW [db.]name

SYSTEM STOP VIEWS

指定したビュー、またはすべてのリフレッシュ可能なビューの定期的なリフレッシュを有効にします。即時にリフレッシュがトリガーされることはありません。

ビューが Replicated または Shared データベース にある場合、START VIEW は STOP VIEW の効果を打ち消し、START REPLICATED VIEW は STOP REPLICATED VIEW の効果を打ち消します。START VIEW は PAUSE VIEW の効果も打ち消します。

SYSTEM START VIEW [db.]name

SYSTEM START VIEWS

指定したビュー、またはすべてのリフレッシュ可能なビューの定期的なリフレッシュを無効化します。 SYSTEM STOP VIEW とは異なり、SYSTEM PAUSE VIEW はすでに進行中のリフレッシュを中断しません。実行中のリフレッシュは完了まで継続され、以降のリフレッシュのみが停止されます。

元に戻すには、SYSTEM START VIEW または SYSTEM START VIEWS を使用します。

SYSTEM PAUSE VIEW [db.]name

SYSTEM PAUSE VIEWS

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

SYSTEM REFRESH VIEW [db.]name

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

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

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

SYSTEM WAIT VIEW [db.]name

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

SYSTEM CANCEL VIEW [db.]name

単一のテーブル、またはサーバー上の該当するすべてのテーブルのバックグラウンド処理を制御する、エンジンに依存しないコマンドです。対象は次のとおりです。

• リフレッシャブルmaterialized view (定期的なリフレッシュ) 、および
• 外部ソースから継続的にデータを取り込むストリーミングテーブルエンジン: Kafka、RabbitMQ、NATS、S3Queue、AzureQueue。

リフレッシャブルmaterialized viewでは、各動詞はリフレッシャブルmaterialized viewの管理で説明する対応する SYSTEM ... VIEW コマンドのエイリアスです。そのため、SYSTEM STOP [db.]name は SYSTEM STOP VIEW [db.]name とまったく同じように動作します。他の動詞についても同様です。

テーブル単位の形式とワイルドカード形式では、バックグラウンド処理を持たないテーブルの扱いが異なります。テーブル単位の形式 (SYSTEM STOP [db.]table) では、指定したテーブルがストリーミングエンジンでもリフレッシャブルmaterialized viewでもない場合、エラーが発生します。ワイルドカード形式では、そのようなテーブルは暗黙的にスキップされるため、常に安全に実行できます。

STOP と CANCEL は、可能な限り速やかに消費を中断します。Kafka、RabbitMQ、NATS では、ソースからの読み取りは停止しますが、すでに開始されている挿入は中断しません。つまり、materialized view への書き込みがすでに始まっているブロックは、完了してコミットされます。S3Queue と AzureQueue は、単一のパイプラインで読み取りと挿入を行います。重複排除が有効な場合 (デフォルト) は、挿入もキャンセルされ、ファイルは後で再処理されます。重複排除が無効な場合は、行の重複を避けるため、処理中のバッチが完了してコミットされます (上記のエンジンと同様) 。読み取り済みでまだコミットされていないデータは後で再度消費されるため、失われることはありません。ただし、再配信できずデータを破棄する JetStream なしのコア NATS は例外です。

PAUSE は実行中の挿入を中断しないため、通常はデータが失われることはありません。コア NATS は例外です。一時停止すると消費が停止し、すでに受信したもののまだ挿入されていないメッセージが破棄されます。また、コア NATS はそれらを再配信できません。

バックグラウンド処理を停止し、その状態を維持します。現在実行中の処理を中断し、SYSTEM START が実行されるまで新たな処理は実行されません。PAUSE + CANCEL と同等です。

SYSTEM STOP [db.]table
SYSTEM STOP ALL BACKGROUND

以前の SYSTEM STOP または SYSTEM PAUSE を取り消し、アクティビティを再開します。アクティビティが中断されることはありません。

SYSTEM START [db.]table
SYSTEM START ALL BACKGROUND

以降のバックグラウンド処理を停止しますが、現在実行中の処理は完了するまで待機します。

SYSTEM PAUSE [db.]table
SYSTEM PAUSE ALL BACKGROUND

現在実行中のアクティビティのみを中断します。今後のアクティビティはブロックされず、テーブルはスケジュールに従って引き続きリフレッシュまたは消費されます。進行中のアクティビティがない場合は何も行いません。

SYSTEM CANCEL [db.]table
SYSTEM CANCEL ALL BACKGROUND

スケジュール外で追加のサイクルを1回実行します。ストリーミングテーブル では、table が停止または一時停止中であっても、ただちに1回実行されます。リフレッシャブルmaterialized view では、SYSTEM REFRESH VIEW と同様に動作します。view が停止している場合、refresh は記憶され、SYSTEM START によって再開されると1回実行されます。

SYSTEM REFRESH [db.]table
SYSTEM REFRESH ALL BACKGROUND

各コマンドには、対象エンジンに対応する権限が必要です。リフレッシャブルmaterialized viewには SYSTEM VIEWS、ストリーミングテーブルには SYSTEM STREAMING ENGINES が必要です。どちらも SYSTEM BACKGROUND の子権限であるため、SYSTEM BACKGROUND を付与すると、このようなすべてのtableのバックグラウンド処理を制御できます。ALL BACKGROUND 形式は、ユーザーが制御を許可されているtableにのみ適用され、それ以外のtableは通知なくスキップされます。

指定した S3Queue または AzureQueue テーブルで、指定したファイルの処理が完了するか、恒久的な失敗になるまで待機します。ファイルがすでに処理済みの場合は、ただちに返ります。ファイルが恒久的に失敗している場合 (すべての再試行を使い切った場合) は、エラーを返します。

SYSTEM FLUSH OBJECT STORAGE QUEUE [db.]table_name PATH 'path'