Which views keep their schedule?
Refreshes are coordinated through ClickHouse Keeper for a view in aReplicated database. In ClickHouse Cloud, the same is true for a Shared database. An APPEND-family view in either Cloud database can opt out of coordination with SETTINGS all_replicas = 1; on an open-source ClickHouse server, only a Replicated database has this coordination. A view without coordination holds its last refresh time in memory only, so a restart leaves it overdue on any ordinary schedule. RANDOMIZE FOR does not spread these refreshes out.
The extra refreshes can also duplicate data
AnAPPEND view appends another full result. An uncoordinated APPEND INCREMENTAL view loses its in-memory cursor on restart unless its transactional target committed the cursor, so it reprocesses rows it had already appended.
Staging the start as described below limits how many refreshes run at once, but it still runs them. An APPEND view avoids the extra append if you start it only when its next refresh is due anyway. An APPEND INCREMENTAL view that lost its cursor gains nothing from the timing, because whenever it next runs it reprocesses the whole source table and appends that result, so keep it stopped until you can absorb or remove the duplicated rows.
Keep every view stopped when the server comes up
Setstop_refreshable_materialized_views_on_startup in the server’s own settings profile, which is the profile named by system_profile, falling back to default_profile and then to default. This setting is experimental:
/etc/clickhouse-server/users.d/refreshable_materialized_views.xml
default profile. Replace it with your custom system_profile when you use one.
SYSTEM STOP VIEWS is not an alternative, because the stopped state it sets does not survive a restart.
Start the views one at a time
SYSTEM START VIEWS starts all of the views at once, which produces the same burst, so start each view by name and let its refresh finish before starting the next one. system.view_refreshes lists them. In ClickHouse Cloud, this system table is node-local, so inspect each node:
SYSTEM REFRESH VIEW it adds no refresh of its own. A view whose refresh time passed while it was stopped is already overdue on that schedule, so it refreshes as soon as it is started, and SYSTEM WAIT VIEW blocks while that refresh runs.
A view that is waiting for a REFRESH ... DEPENDS ON prerequisite is not refreshing yet, so start those views after the ones they depend on. A circular dependency has no such order, and a restart breaks the cycle whenever its views are not coordinated: start every member, then run the same SYSTEM REFRESH VIEW you ran to start the cycle when you created it, and wait for that refresh. A graph that took more than one such refresh to start needs the same set again. Triggering a different member can leave the cycle idle, because a view resumes only once every one of its prerequisites has refreshed. Once triggered the cycle refreshes on its own, so the one-at-a-time pacing stops at the trigger.
What this means for your automation
While the setting is in place, an unplanned restart leaves every refreshable materialized view stopped, and a newly created view does not begin refreshing until it is started either.RESTORE is the exception for a view whose refreshes are not coordinated: it starts every such view it includes, and that view may then be immediately overdue and replay its source. A coordinated view is not started by the restore, so it stays stopped until you start it. Make whatever automation restarts your servers and creates your views responsible for starting them.