```
### SYSTEM WAIT LOADING PARTS
テーブル内の非同期で読み込み中のすべてのデータパーツ (古いデータパーツ) が読み込み完了になるまで待機します。
```sql theme={null}
SYSTEM WAIT LOADING PARTS [ON CLUSTER cluster_name] [db.]merge_tree_family_table_name
```
## ReplicatedMergeTree テーブルの管理
ClickHouse では、[ReplicatedMergeTree](/ja/reference/engines/table-engines/mergetree-family/replication) テーブルに関連するバックグラウンドのレプリケーション処理を管理できます。
### SYSTEM STOP FETCHES
`ReplicatedMergeTree` ファミリーのテーブルで、挿入されたパーツに対するバックグラウンドフェッチを停止できます。
テーブルエンジンに関係なく、またテーブルやデータベースが存在しない場合でも、常に `Ok.` を返します。
```sql theme={null}
SYSTEM STOP FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM START FETCHES
`ReplicatedMergeTree` ファミリーのテーブルで、挿入されたパーツに対するバックグラウンドフェッチを開始できます。
テーブルエンジンに関係なく、またテーブルやデータベースが存在しない場合でも、常に `Ok.` を返します。
```sql theme={null}
SYSTEM START FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM STOP REPLICATED SENDS
`ReplicatedMergeTree` ファミリーのテーブルで、新たに挿入されたパーツをクラスター内の他のレプリカに送信するバックグラウンド処理を停止できます。
```sql theme={null}
SYSTEM STOP REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM START REPLICATED SENDS
`ReplicatedMergeTree` ファミリーのテーブルについて、新しく挿入されたパーツをクラスター内の他のレプリカへバックグラウンドで送信する処理を開始できます。
```sql theme={null}
SYSTEM START REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM STOP REPLICATION QUEUES
`ReplicatedMergeTree` ファミリーのテーブルについて、ZooKeeper に保存されているレプリケーションキュー内のバックグラウンド fetch タスクを停止できます。対象となるバックグラウンドタスクの種類は、merges、フェッチ、mutation、ON CLUSTER 句を含む DDL ステートメントです。
```sql theme={null}
SYSTEM STOP REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM START REPLICATION QUEUES
`ReplicatedMergeTree` ファミリーのテーブルに対して、ZooKeeper に保存されているレプリケーションキューからバックグラウンドのフェッチタスクを開始できます。実行可能なバックグラウンドタスクの種類は、マージ、フェッチ、ミューテーション、ON CLUSTER 句を伴う DDL ステートメントです:
```sql theme={null}
SYSTEM START REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM STOP PULLING REPLICATION LOG
`ReplicatedMergeTree` テーブルで、レプリケーションログからレプリケーションキューへの新しいエントリの取り込みを停止します。
```sql theme={null}
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` の効果を取り消します。
```sql theme={null}
SYSTEM START PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM SYNC REPLICA
`ReplicatedMergeTree` テーブルがクラスター内の他のレプリカと同期されるまで待機します。ただし、待機時間は `receive_timeout` 秒を超えません。
```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]
```
このステートメントを実行すると、`[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
指定した[レプリケートデータベース](/ja/reference/engines/database-engines/replicated)が、そのデータベースのDDLキューにあるすべてのスキーマ変更を適用し終えるまで待機します。
**構文**
```sql theme={null}
SYSTEM SYNC DATABASE REPLICA replicated_database_name;
```
### SYSTEM RESTART REPLICA
`ReplicatedMergeTree` テーブルの ZooKeeper セッションの状態を再初期化できます。現在の状態を正しい情報源である ZooKeeper と照合し、必要に応じてタスクを ZooKeeper のキューに追加します。
ZooKeeper のデータに基づくレプリケーションキューの初期化は、`ATTACH TABLE` ステートメントと同じ方法で行われます。短時間、テーブルは一切の操作を受け付けなくなります。
```sql theme={null}
SYSTEM RESTART REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name
```
### SYSTEM RESTORE REPLICA
データが\[存在している可能性がある]にもかかわらず、ZooKeeper のメタデータが失われた場合にレプリカを復元します。
readonly の `ReplicatedMergeTree` テーブルでのみ動作します。
次のような場合にクエリを実行できます。
* ZooKeeper ルート `/` が失われた場合。
* レプリカのパス `/replicas` が失われた場合。
* 個々のレプリカのパス `/replicas/replica_name/` が失われた場合。
レプリカはローカルで見つかったパーツをアタッチし、それらの情報を ZooKeeper に送信します。
メタデータ消失前にレプリカ上に存在していたパーツは、古くなっていない限り、他のレプリカから再取得されません (つまり、レプリカの復元はネットワーク経由ですべてのデータを再ダウンロードすることを意味しません) 。
すべての状態のパーツは `detached/` フォルダーに移動されます。データ消失前にアクティブだった (コミット済みの) パーツがアタッチされます。
### SYSTEM RESTORE DATABASE REPLICA
データは\[存在している可能性がある]ものの、ZooKeeperのメタデータが失われた場合にレプリカを復元します。
**構文**
```sql theme={null}
SYSTEM RESTORE DATABASE REPLICA repl_db [ON CLUSTER cluster]
```
**例**
```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) <- ルートの喪失。
SYSTEM RESTORE DATABASE REPLICA repl_db;
```
**構文**
```sql theme={null}
SYSTEM RESTORE REPLICA [db.]replicated_merge_tree_family_table_name [ON CLUSTER cluster_name]
```
代替構文:
```sql theme={null}
SYSTEM RESTORE REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name
```
**例**
複数のサーバーにテーブルを作成します。ZooKeeper 内のレプリカのメタデータが失われると、メタデータが不足しているため、そのテーブルは読み取り専用でアタッチされます。最後のクエリは、すべてのレプリカで実行する必要があります。
```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) <- ルートの消失。
SYSTEM RESTART REPLICA test;
SYSTEM RESTORE REPLICA test;
```
別の方法:
```sql theme={null}
SYSTEM RESTORE REPLICA test ON CLUSTER cluster;
```
### SYSTEM RESTART REPLICAS
すべての `ReplicatedMergeTree` テーブルについて、ZooKeeper セッションの状態を再初期化できます。現在の状態を信頼できる情報源である ZooKeeper と比較し、必要に応じて ZooKeeper のキューにタスクを追加します
### SYSTEM CLEAR|DROP FILESYSTEM CACHE
ファイルシステムキャッシュをクリアできます。
```sql theme={null}
SYSTEM CLEAR FILESYSTEM CACHE [ON CLUSTER cluster_name]
```
### SYSTEM SYNC FILE CACHE
負荷が高く、誤用されるおそれがあります。
`sync` システムコールを実行します。
```sql theme={null}
SYSTEM SYNC FILE CACHE [ON CLUSTER cluster_name]
```
### SYSTEM LOAD PRIMARY KEY
指定したtable、またはすべてのtableの主キーを読み込みます。
```sql theme={null}
SYSTEM LOAD PRIMARY KEY [db.]name
```
```sql theme={null}
SYSTEM LOAD PRIMARY KEY
```
### SYSTEM UNLOAD PRIMARY KEY
指定したテーブル、またはすべてのテーブルの主キーをアンロードします。
```sql theme={null}
SYSTEM UNLOAD PRIMARY KEY [db.]name
```
```sql theme={null}
SYSTEM UNLOAD PRIMARY KEY
```
## リフレッシュ可能なマテリアライズドビューの管理
[リフレッシュ可能なマテリアライズドビュー](/ja/reference/statements/create/view#refreshable-materialized-view) が実行するバックグラウンドタスクを制御するコマンドです。
使用中は、[`system.view_refreshes`](/ja/reference/system-tables/view_refreshes) を確認してください。
### SYSTEM STOP \[REPLICATED] VIEW, STOP VIEWS
指定したビュー、またはすべてのリフレッシュ可能なビューの定期リフレッシュを停止します。リフレッシュが進行中の場合は、それもキャンセルします。
ビューが Replicated または Shared データベースにある場合、`STOP VIEW` は現在のレプリカにのみ影響し、`STOP REPLICATED VIEW` はすべてのレプリカに影響します。
停止状態はサーバーの再起動後も維持されません。再起動後、ビューは設定されたリフレッシュスケジュールに従って再開されます。
Replicated または Shared データベースでは、`SYSTEM STOP VIEW` は現在のレプリカにのみ影響します。すべてのレプリカでリフレッシュを停止するには、`SYSTEM STOP REPLICATED VIEW` を使用してください。
```sql theme={null}
SYSTEM STOP VIEW [db.]name
```
```sql theme={null}
SYSTEM STOP VIEWS
```
### SYSTEM START \[REPLICATED] VIEW, START VIEWS
指定したビュー、またはすべてのリフレッシュ可能なビューの定期的なリフレッシュを有効にします。即時にリフレッシュがトリガーされることはありません。
ビューが Replicated または Shared データベース にある場合、`START VIEW` は `STOP VIEW` の効果を打ち消し、`START REPLICATED VIEW` は `STOP REPLICATED VIEW` の効果を打ち消します。`START VIEW` は `PAUSE VIEW` の効果も打ち消します。
```sql theme={null}
SYSTEM START VIEW [db.]name
```
```sql theme={null}
SYSTEM START VIEWS
```
### SYSTEM PAUSE VIEW, PAUSE VIEWS
指定したビュー、またはすべてのリフレッシュ可能なビューの定期的なリフレッシュを無効化します。
`SYSTEM STOP VIEW` とは異なり、`SYSTEM PAUSE VIEW` はすでに進行中のリフレッシュを中断しません。実行中のリフレッシュは完了まで継続され、以降のリフレッシュのみが停止されます。
元に戻すには、`SYSTEM START VIEW` または `SYSTEM START VIEWS` を使用します。
一時停止状態はサーバーの再起動後には保持されません。再起動後、ビューは設定されたリフレッシュスケジュールに従って再開されます。
Replicated または Shared データベースでは、`SYSTEM PAUSE VIEW` は現在のレプリカにのみ影響します。
```sql theme={null}
SYSTEM PAUSE VIEW [db.]name
```
```sql theme={null}
SYSTEM PAUSE VIEWS
```
### SYSTEM REFRESH VIEW
指定したビューのスケジュール外の即時リフレッシュを実行します。
```sql theme={null}
SYSTEM REFRESH VIEW [db.]name
```
### SYSTEM WAIT VIEW
実行中のリフレッシュが完了するまで待機します。リフレッシュが実行されていない場合は、即座に返されます。直近のリフレッシュ試行が失敗している場合は、エラーを報告します。
新しいリフレッシャブルmaterialized view を作成した直後 (EMPTY キーワードなし) に使用して、初回のリフレッシュが完了するまで待つことができます。
ビューが Replicated または Shared データベースにあり、別のレプリカでリフレッシュが実行されている場合は、そのリフレッシュが完了するまで待機します。
```sql theme={null}
SYSTEM WAIT VIEW [db.]name
```
### SYSTEM CANCEL VIEW
現在のレプリカ上で指定したビューのリフレッシュが進行中の場合は、それを中断してキャンセルします。進行中でない場合は何もしません。
```sql theme={null}
SYSTEM CANCEL VIEW [db.]name
```
## SYSTEM FLUSH OBJECT STORAGE QUEUE
指定した [S3Queue](/ja/reference/engines/table-engines/integrations/s3queue) または [AzureQueue](/ja/reference/engines/table-engines/integrations/azure-queue) テーブルで、指定したファイルの処理が完了するか、恒久的な失敗になるまで待機します。ファイルがすでに処理済みの場合は、ただちに返ります。ファイルが恒久的に失敗している場合 (すべての再試行を使い切った場合) は、エラーを返します。
```sql theme={null}
SYSTEM FLUSH OBJECT STORAGE QUEUE [db.]table_name PATH 'path'
```