> ## 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.

# Что происходит с refreshable materialized view при перезапуске сервера

> Почему при перезапуске сервера все refreshable materialized view могут обновиться одновременно и как запускать их заново по одному.

<Warning>
  Если обновления refreshable materialized view не координируются через ClickHouse Keeper, представление не помнит время своего последнего обновления и поэтому может обновиться снова, как только сервер будет готов к работе. Если на сервере много таких представлений или они построены над большими наборами данных, одновременно может запуститься множество обновлений по полному набору данных — и именно тогда, когда сервер меньше всего способен выдержать такую нагрузку.
</Warning>

<h2 id="which-views-keep-their-schedule">
  Какие представления сохраняют своё расписание?
</h2>

Для представления в базе данных [`Replicated`](/ru/reference/engines/database-engines/replicated) обновления координируются через ClickHouse Keeper. В ClickHouse Cloud то же самое относится и к базе данных [`Shared`](/ru/cloud/reference/shared-catalog). Представление семейства `APPEND` в любой из этих баз данных Cloud может отказаться от координации с помощью `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`](/ru/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`, укажите его вместо `default`.

[`SYSTEM STOP VIEWS`](/ru/reference/statements/system#stop-view-stop-views) не подходит в качестве альтернативы, поскольку заданное этой командой состояние остановки не сохраняется после перезапуска.

<h2 id="start-the-views-one-at-a-time">
  Запускайте представления по одному
</h2>

[`SYSTEM START VIEWS`](/ru/reference/statements/system#start-view-start-views) запускает все представления сразу, что приводит к такому же всплеску нагрузки. Поэтому запускайте представления по имени, по одному, и дожидайтесь завершения обновления каждого из них, прежде чем запускать следующее. Список представлений содержится в [`system.view_refreshes`](/ru/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`](/ru/reference/statements/system#refresh-view), не инициирует собственного обновления. Если время обновления представления наступило, пока оно было остановлено, то по расписанию оно уже просрочено, поэтому обновится сразу после запуска, а [`SYSTEM WAIT VIEW`](/ru/reference/statements/system#wait-view) будет заблокирован на время выполнения этого обновления.

Представление, ожидающее обновления зависимости из [`REFRESH ... DEPENDS ON`](/ru/reference/statements/create/view#refresh-dependencies), ещё не обновляется, поэтому запускайте такие представления после тех, от которых они зависят. У циклической зависимости такого порядка нет, и если её представления не координируемы, перезапуск разрывает цикл: запустите все представления цикла, затем выполните тот же `SYSTEM REFRESH VIEW`, которым вы запускали цикл при его создании, и дождитесь завершения этого обновления. Если для запуска графа потребовалось несколько таких обновлений, выполните тот же набор снова. Если запустить обновление другого представления цикла, цикл может остаться в бездействии, поскольку представление возобновляет работу только после обновления всех его зависимостей. После запуска цикл обновляется самостоятельно, поэтому поочерёдный запуск требуется только до этого момента.

<h2 id="what-this-means-for-your-automation">
  Что это означает для вашей автоматизации
</h2>

Пока действует этот параметр, после незапланированного перезапуска все refreshable materialized view остаются остановленными, а только что созданное представление тоже не начнёт обновляться, пока его не запустят. Исключение — `RESTORE` для представлений с некоординируемыми обновлениями: эта операция запускает каждое такое представление, входящее в резервную копию, и оно может сразу оказаться просроченным и заново обработать исходные данные. Координируемое представление при восстановлении не запускается и остаётся остановленным, пока вы не запустите его вручную. Поручите запуск представлений той автоматизации, которая перезапускает ваши серверы и создаёт представления.