Какие представления сохраняют своё расписание?
Для представления в базе данныхReplicated обновления координируются через ClickHouse Keeper. В ClickHouse Cloud то же самое относится и к базе данных Shared. Представление семейства APPEND в любой из этих баз данных Cloud может отказаться от координации с помощью 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
default. Если вы используете собственный профиль system_profile, укажите его вместо default.
SYSTEM STOP VIEWS не подходит в качестве альтернативы, поскольку заданное этой командой состояние остановки не сохраняется после перезапуска.
Запускайте представления по одному
SYSTEM START VIEWS запускает все представления сразу, что приводит к такому же всплеску нагрузки. Поэтому запускайте представления по имени, по одному, и дожидайтесь завершения обновления каждого из них, прежде чем запускать следующее. Список представлений содержится в system.view_refreshes. В ClickHouse Cloud эта системная таблица локальна для каждого узла, поэтому проверяйте все узлы по отдельности:
SYSTEM REFRESH VIEW, не инициирует собственного обновления. Если время обновления представления наступило, пока оно было остановлено, то по расписанию оно уже просрочено, поэтому обновится сразу после запуска, а SYSTEM WAIT VIEW будет заблокирован на время выполнения этого обновления.
Представление, ожидающее обновления зависимости из REFRESH ... DEPENDS ON, ещё не обновляется, поэтому запускайте такие представления после тех, от которых они зависят. У циклической зависимости такого порядка нет, и если её представления не координируемы, перезапуск разрывает цикл: запустите все представления цикла, затем выполните тот же SYSTEM REFRESH VIEW, которым вы запускали цикл при его создании, и дождитесь завершения этого обновления. Если для запуска графа потребовалось несколько таких обновлений, выполните тот же набор снова. Если запустить обновление другого представления цикла, цикл может остаться в бездействии, поскольку представление возобновляет работу только после обновления всех его зависимостей. После запуска цикл обновляется самостоятельно, поэтому поочерёдный запуск требуется только до этого момента.
Что это означает для вашей автоматизации
Пока действует этот параметр, после незапланированного перезапуска все refreshable materialized view остаются остановленными, а только что созданное представление тоже не начнёт обновляться, пока его не запустят. Исключение —RESTORE для представлений с некоординируемыми обновлениями: эта операция запускает каждое такое представление, входящее в резервную копию, и оно может сразу оказаться просроченным и заново обработать исходные данные. Координируемое представление при восстановлении не запускается и остаётся остановленным, пока вы не запустите его вручную. Поручите запуск представлений той автоматизации, которая перезапускает ваши серверы и создаёт представления.