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

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

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

​

スケジュールが維持されるビュー

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

​

余分なリフレッシュによってデータが重複することもある

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

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

​

サーバー起動時にすべてのビューを停止したままにする

サーバー自身の設定プロファイルで stop_refreshable_materialized_views_on_startup を設定します。このプロファイルは system_profile で指定されたものを指し、指定がない場合は default_profile、それもなければ default にフォールバックします。この設定は実験的機能です。

/etc/clickhouse-server/users.d/refreshable_materialized_views.xml

<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 では代わりになりません。このコマンドで設定される停止状態は、再起動すると失われるためです。

​

ビューを1つずつ開始する

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

SYSTEM START VIEW my_database.my_view;
SYSTEM WAIT VIEW my_database.my_view;

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

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

​

自動化への影響

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