materialized_views_ignore_errors
SELECT ou dans le sink de la table interne) sont consignées sous forme d’avertissement et l’instruction INSERT réussit. Si elle est désactivée (par défaut), une telle exception se propage et l’instruction INSERT échoue.
Ce paramètre contrôle uniquement le signalement des erreurs. Il n’annule pas une écriture dans la table source et ne garantit pas non plus que le bloc d’origine ait déjà été validé dans la table source lorsqu’une erreur se produit dans le pipeline d’une vue dépendante. Lorsqu’il est désactivé (par défaut), l’INSERT échoue en cas d’erreur sur une vue — relancez-le avec la déduplication d’insertion (insert_deduplicate, deduplicate_blocks_in_dependent_materialized_views) pour une livraison exactly-once vers la table source et toutes les vues dépendantes. Lorsqu’il est activé, l’INSERT est signalé comme réussi malgré une livraison partielle aux vues défaillantes et à leurs chaînes en aval ; utilisez-le uniquement lorsque les écritures dans la table source ne doivent pas être bloquées par des problèmes du côté des vues (par exemple, les tables system.*_log). Consultez la documentation CREATE VIEW pour la sémantique complète.
materialized_views_populate_atomically
CREATE MATERIALIZED VIEW ... POPULATE atomique : la vue s’abonne aux nouvelles insertions dans la table source et un instantané des données existantes est pris simultanément, sous un bref verrou exclusif sur la table source, afin que chaque ligne insérée pendant le remplissage soit transmise à la vue exactement une fois (sans être ni omise ni dupliquée). Le remplissage, potentiellement long, lit ensuite l’instantané figé sans maintenir de verrou.
Il s’agit d’une atomicité du chemin d’insertion local : le verrou exclusif ne se synchronise qu’avec les insertions qui acquièrent le verrou de stockage de cette table source sur le même serveur ; la garantie d’exactement une fois couvre donc les insertions arrivant via ce serveur. Il ne s’agit pas d’une garantie à l’échelle du cluster : les lignes insérées sur une autre réplique d’une source ReplicatedMergeTree, ou via un chemin d’écriture distribuée (par exemple, dans une table Distributed ou via ON CLUSTER) pendant le remplissage peuvent toujours être omises ou dupliquées.
La table source doit prendre en charge la lecture d’un instantané figé à un instant donné (la famille MergeTree et Memory). Pour toute autre source (une vue, Distributed, Merge, la famille Log ou une table ne se trouvant pas dans une base de données Atomic), le remplissage revient au comportement legacy non atomique (consigné dans le journal du serveur) : les données existantes sont lues à partir d’un instantané distinct et non coordonné, de sorte que les lignes insérées pendant le remplissage peuvent être omises ou dupliquées. Définissez ce paramètre sur false pour imposer le comportement legacy à toutes les sources. S’applique uniquement à CREATE MATERIALIZED VIEW simple ; CREATE OR REPLACE / REPLACE utilisent toujours le remplissage legacy non atomique, tout comme une vue créée dans une base de données Replicated (où POPULATE requiert database_replicated_allow_heavy_create), car l’échec d’un remplissage ne pourrait pas y être annulé de manière cohérente sur toutes les répliques.
materialized_views_squash_parallel_inserts
parallel_view_processing est activé, la requête INSERT générera une part dans la table de destination pour chaque max_insert_thread.