> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# サーバー再起動時にリフレッシャブルmaterialized viewはどうなるか

> サーバーの再起動時にリフレッシャブルmaterialized viewが一斉にリフレッシュされることがある理由と、それらを 1 つずつ再開する方法について説明します。

<Warning>
  ClickHouse Keeper を介してリフレッシュが協調していないリフレッシャブルmaterialized viewは、前回のリフレッシュ時刻を保持しません。そのため、サーバーが準備完了になるとすぐに再びリフレッシュされる可能性があります。このようなビューを多数抱えるサーバーや、大規模なデータセットを対象とするビューを持つサーバーでは、負荷を最も吸収しにくい再起動直後のタイミングで、データセット全体を対象とするリフレッシュが一斉に多数実行されるおそれがあります。
</Warning>

<h2 id="which-views-keep-their-schedule">
  スケジュールが維持されるビュー
</h2>

[`Replicated`](/ja/reference/engines/database-engines/replicated) データベース内のビューでは、リフレッシュは ClickHouse Keeper を介して協調されます。ClickHouse Cloud では、[`Shared`](/ja/cloud/reference/shared-catalog) データベースでも同様です。これらいずれの Cloud データベースでも、`APPEND` 系のビューは `SETTINGS all_replicas = 1` を指定することで協調の対象外にできます。一方、オープンソース版 ClickHouse のサーバーでは、この協調が行われるのは `Replicated` データベースのみです。協調の対象外のビューは、最後のリフレッシュ時刻をメモリ上にしか保持しません。そのため、再起動すると、通常のスケジュールであればどのようなものでもリフレッシュが予定時刻を過ぎた状態になります。なお、`RANDOMIZE FOR` を指定しても、これらのリフレッシュは分散されません。

<h2 id="the-extra-refreshes-can-also-duplicate-data">
  余分なリフレッシュによってデータが重複することもある
</h2>

`APPEND` ビューは、完全な結果をもう一度追記します。協調されていない `APPEND INCREMENTAL` ビューは、トランザクション対応のターゲットがカーソルをコミットしていない限り、再起動時にインメモリのカーソルを失います。その結果、すでに追記済みの行を再処理することになります。

以下で説明するように起動を段階的に行えば、同時に実行されるリフレッシュの数は抑えられますが、リフレッシュそのものは実行されます。`APPEND` ビューでは、どのみち次のリフレッシュが予定されているタイミングに合わせて起動すれば、余分な追記を回避できます。一方、カーソルを失った `APPEND INCREMENTAL` ビューでは、タイミングを調整しても効果はありません。次にいつ実行されてもソーステーブル全体を再処理し、その結果を追記するためです。重複した行を許容または削除できる状態になるまで、停止したままにしておいてください。

<h2 id="keep-every-view-stopped-when-the-server-comes-up">
  サーバー起動時にすべてのビューを停止したままにする
</h2>

サーバー自身の設定プロファイルで [`stop_refreshable_materialized_views_on_startup`](/ja/reference/settings/session-settings/other#stop_refreshable_materialized_views_on_startup) を設定します。このプロファイルは `system_profile` で指定されたものを指し、指定がない場合は `default_profile`、それもなければ `default` にフォールバックします。この設定は実験的機能です。

```xml title="/etc/clickhouse-server/users.d/refreshable_materialized_views.xml" theme={null}
<clickhouse>
    <profiles>
        <default>
            <stop_refreshable_materialized_views_on_startup>1</stop_refreshable_materialized_views_on_startup>
        </default>
    </profiles>
</clickhouse>
```

この例では、デフォルトの `default` プロファイルを使用しています。独自の `system_profile` を使用している場合は、そちらに置き換えてください。

[`SYSTEM STOP VIEWS`](/ja/reference/statements/system#stop-view-stop-views) では代わりになりません。このコマンドで設定される停止状態は、再起動すると失われるためです。

<h2 id="start-the-views-one-at-a-time">
  ビューを1つずつ開始する
</h2>

[`SYSTEM START VIEWS`](/ja/reference/statements/system#start-view-start-views) はすべてのビューを一斉に開始するため、同じように負荷が集中してしまいます。各ビューを名前で指定して個別に開始し、そのリフレッシュが完了してから次のビューを開始してください。ビューの一覧は [`system.view_refreshes`](/ja/reference/system-tables/view_refreshes) で確認できます。ClickHouse Cloud では、このシステムテーブルはノードローカルであるため、ノードごとに確認してください:

```sql theme={null}
SYSTEM START VIEW my_database.my_view;
SYSTEM WAIT VIEW my_database.my_view;
```

ビューを開始しても、そのスケジュールが再開されるだけであり、[`SYSTEM REFRESH VIEW`](/ja/reference/statements/system#refresh-view) とは異なり、独自のリフレッシュが追加されることはありません。停止中にリフレッシュ時刻を過ぎたビューは、スケジュール上すでに期限を超過しているため、開始するとすぐにリフレッシュされます。また、そのリフレッシュの実行中は [`SYSTEM WAIT VIEW`](/ja/reference/statements/system#wait-view) がブロックされます。

[`REFRESH ... DEPENDS ON`](/ja/reference/statements/create/view#refresh-dependencies) で指定した前提ビューを待機しているビューは、まだリフレッシュを行っていません。そのため、こうしたビューは依存先のビューを開始した後に開始してください。循環依存にはこのような順序が存在しないため、ビュー同士が協調していない状態で再起動すると、サイクルが途切れます。すべてのメンバーを開始した後、作成時にサイクルを開始するために実行したものと同じ `SYSTEM REFRESH VIEW` を実行し、そのリフレッシュの完了を待ってください。開始時にこうしたリフレッシュを複数回必要としたグラフでは、同じ一連のリフレッシュを再度実行する必要があります。別のメンバーをトリガーすると、サイクルがアイドル状態のままになることがあります。ビューが再開されるのは、そのすべての前提ビューがリフレッシュされた後に限られるためです。一度トリガーされれば、サイクルは自律的にリフレッシュを繰り返すため、1 つずつ開始する手順はトリガーの時点で完了です。

<h2 id="what-this-means-for-your-automation">
  自動化への影響
</h2>

この設定が有効な間は、予期しない再起動が発生するとすべてのリフレッシャブルmaterialized viewが停止したままとなり、新たに作成したビューも開始するまではリフレッシュされません。ただし、リフレッシュが協調されていないビューについては `RESTORE` が例外です。`RESTORE` は対象に含まれるそのようなビューをすべて開始するため、そのビューはリストア直後からリフレッシュ期限を過ぎた状態となり、ソースデータを再処理する可能性があります。一方、協調されたビューはリストアによって開始されないため、明示的に開始するまで停止したままです。サーバーの再起動やビューの作成を行う自動化処理の中で、これらのビューの開始も行うようにしてください。