materialized_views_ignore_errors
SELECT или в sink внутренней таблицы), записываются как предупреждения, а оператор INSERT завершается успешно. Если отключено (по умолчанию), такое исключение пробрасывается дальше, и оператор INSERT завершается ошибкой.
Этот параметр управляет только сообщениями об ошибках. Он не откатывает запись в исходную таблицу и не гарантирует, что исходный блок уже был зафиксирован в исходной таблице к моменту возникновения ошибки в конвейере зависимой view. Если параметр отключён (по умолчанию), INSERT завершается ошибкой при ошибке во view — повторите его с дедупликацией вставок (insert_deduplicate, deduplicate_blocks_in_dependent_materialized_views), чтобы обеспечить доставку exactly-once в исходную таблицу и все зависимые view. Если параметр включён, INSERT сообщает об успехе, несмотря на частичную доставку в view с ошибками и их последующие цепочки; используйте это только тогда, когда записи в исходную таблицу не должны блокироваться из-за проблем на стороне view (например, для таблиц system.*_log). Полное описание семантики см. в документации по CREATE VIEW.
materialized_views_populate_atomically
CREATE MATERIALIZED VIEW ... POPULATE атомарным: materialized view подписывается на новые вставки в исходную таблицу, а снимок существующих данных создаётся одновременно под кратковременной эксклюзивной блокировкой исходной таблицы, поэтому каждая строка, вставленная параллельно с заполнением, доставляется в materialized view ровно один раз — без пропусков и дублирования. Затем заполнение, которое может быть длительным, считывает закреплённый снимок, не удерживая блокировку.
Это атомарность локального пути вставки: эксклюзивная блокировка синхронизируется только со вставками, которые получают блокировку хранилища этой исходной таблицы на том же сервере, поэтому гарантия exactly-once распространяется на вставки, поступающие через этот сервер. Это не гарантия для всего кластера: строки, вставленные на другую реплику исходной таблицы ReplicatedMergeTree или через распределённый путь записи (например, в таблицу Distributed либо через ON CLUSTER) параллельно с заполнением, всё ещё могут быть пропущены или продублированы.
Для этого исходная таблица должна поддерживать чтение закреплённого снимка на определённый момент времени (семейство MergeTree и Memory). Для любых других источников (представления, Distributed, Merge, семейства Log или таблицы не в базе данных Atomic) используется устаревшее неатомарное поведение (с записью в журнал сервера): существующие данные считываются из отдельного, нескоординированного снимка, поэтому строки, вставленные во время заполнения, могут быть пропущены или продублированы. Установите эту настройку в false, чтобы принудительно использовать устаревшее поведение для всех источников. Применяется только к обычному CREATE MATERIALIZED VIEW; CREATE OR REPLACE / REPLACE всегда используют устаревшее неатомарное заполнение, как и materialized view, созданное в базе данных Replicated (где для POPULATE требуется database_replicated_allow_heavy_create), поскольку неудачное заполнение нельзя было бы согласованно откатить на всех репликах.
materialized_views_squash_parallel_inserts
parallel_view_processing, запрос INSERT будет создавать часть в целевой таблице для каждого max_insert_thread.