materialized_views_ignore_errors
SELECT dela ou no sink da tabela interna) serão registradas como aviso, e a instrução INSERT será concluída com sucesso. Se estiver desabilitada (padrão), essa exceção será propagada, e a instrução INSERT falhará.
Essa configuração controla apenas como os erros são reportados. Ela não reverte uma gravação na tabela de origem nem garante se o bloco original já foi confirmado na tabela de origem quando ocorre um erro no pipeline de uma visão dependente. Quando desabilitada (padrão), o INSERT falha em caso de erro na visão — tente novamente com desduplicação de insert (insert_deduplicate, deduplicate_blocks_in_dependent_materialized_views) para entrega exatamente uma vez na tabela de origem e em todas as visões dependentes. Quando habilitada, o INSERT informa sucesso apesar da entrega parcial para visões com falha e suas cadeias subsequentes; use isso apenas quando as gravações na tabela de origem não puderem ser bloqueadas por problemas no lado da visão (por exemplo, tabelas system.*_log). Consulte a documentação de CREATE VIEW para ver a semântica completa.
materialized_views_populate_atomically
CREATE MATERIALIZED VIEW ... POPULATE atômico: a visão é inscrita para novos inserts na tabela de origem e, ao mesmo tempo, é criado um snapshot dos dados existentes, sob um breve lock exclusivo na tabela de origem, para que cada linha inserida durante o preenchimento seja entregue à visão exatamente uma vez (sem ser perdida nem duplicada). Em seguida, o preenchimento (possivelmente de longa duração) lê o snapshot fixado sem manter nenhum lock.
Trata-se de atomicidade local no caminho de insert: o lock exclusivo serializa apenas com inserts que adquirem o lock de armazenamento da tabela de origem no mesmo servidor, portanto a garantia de exatamente uma vez abrange inserts que chegam por esse servidor. Não é uma garantia para todo o cluster — linhas inseridas em outra réplica de uma origem ReplicatedMergeTree ou por meio de um caminho de gravação distribuída (por exemplo, em uma tabela Distributed ou via ON CLUSTER) durante o preenchimento ainda podem ser perdidas ou duplicadas.
Isso exige que a tabela de origem ofereça suporte à leitura de um snapshot fixado em um momento específico (a família MergeTree e Memory). Para qualquer outra origem (uma visão, Distributed, Merge, a família Log ou uma tabela que não esteja em um banco de dados Atomic), o preenchimento recorre ao comportamento legado não atômico (registrado no log do servidor): os dados existentes são lidos com um snapshot separado e não coordenado, de modo que linhas inseridas durante o preenchimento podem ser perdidas ou duplicadas. Defina esta configuração como false para forçar o comportamento legado em todas as origens. Aplica-se somente a CREATE MATERIALIZED VIEW simples; CREATE OR REPLACE / REPLACE sempre usam o preenchimento legado não atômico, assim como uma visão criada em um banco de dados Replicated (no qual POPULATE exige database_replicated_allow_heavy_create), pois não seria possível reverter de forma consistente, em todas as réplicas, um preenchimento que falhasse.
materialized_views_squash_parallel_inserts
parallel_view_processing estiver ativado, a consulta INSERT gerará uma parte na tabela de destino para cada max_insert_thread.