Здравствуйте. На некоторых столбцах таблицы (подневное партиционирование) стоит однодневный TTL (

"dateField + toIntervalDay(1)" ).
В результате слияний, дополнительно подгоняемых OPTIMIZE FINAL, партиции, устаревшие на несколько дней (и в которые больше не приходят данные) свернулись в единственный парт.
Но в некоторых из таких партиций-партов столбцы с суточным TTL не до конца обнуляются (иногда несколько десятков % записей оставались со своими исходными значениями в TTL-столбцах).

В файловой системе внутри соответствующих parts в файле ttl.txt все столбцы, которые должны были очиститься перечислены уже с нулями в min и max:( Т.е. если clickhouse ориентируется на ttl.txt, то он должен считать свою работу выполненной?
(А вот в system.parts для этих parts указаны правильные delete_ttl_info_max и delete_ttl_info_min).

Здесь что-то уже пошло не так, или такое может быть?

( Если к таким parts применить MATERIALIZE TTL IN PARTITION , то после завершения мутации TTL-столбцы полностью очищаются, как и должно было быть. )

может есть TTL only drop parts=true? хотя на колонки влиять не должен. если можете воспроизвести - откройте баг.

На таблицу установлен ttl_only_drop_parts=1. Но, действительно, он же для таблицы в целом, не должен препятствовать обнуление отдельных столбцов. И, в общем и целом, столбцы в старых партах обнуляются, вот только иногда не до конца. (Версия 20.10.7.4) > если можете воспроизвести - откройте баг Посмотрю, как дальше будет схлопывание происходить.

есть вариант что этот случай просто так реализован (колоночные ТТЛ + ttl_only_drop_parts)... хотя

это речь про summingMT ? а кто сказал что записи из партиции в партицию смогут перепрыгнуть? вы хакнули - сломали себе таблицу похоже это все делается через TTL group by современный КХ такое не позволяет create table t1(A Int64, D Date TTL D + interval 1 day, V Float64) Engine=SummingMergeTree partition by D order by A DB::Exception: Trying to set TTL for key column D.

Я в вопросе этого не указал:( - нет, там не SummingMergeTree, a просто ReplicatedMergeTree. За предыдущие дни в свёрнутых до 1 парта партициях (слияния форсировались ночными optimize final) иногда оставалась часть записей с не до конца очищенными COLUMN TTL столбцами (сутки: ( ...+ toIntervalDay(1))). Но поскольку у меня уже не поддерживаемая версия 20.10.7.4 и в любом случае надо на 21.3 переезжать, я в итоге перестал с этим эффектом разбираться. Вместо OPTIMIZE FINAL пока использую аккуратные MATERIALIZE TTL IN PARTITION.

я тогда видимо вообще все не так понял. Т.е. у вас ReplicatedMergeTree , вы пытаетесь колонки очищать toIntervalDay(1) но у вас часть строк остается неочищенными, несмотря на то что в партиции один парт? При этом эти поля с TTL, не являются частью partition by / order by.

Таблица ReplicatedMergeTree ( end_datetime типа DateTime - время самого события): ... PARTITION BY toYYYYMMDD(end_datetime) ORDER BY (user_id, end_datetime) TTL (toDate(end_datetime) + toIntervalDay(5) SETTINGS min_rows_for_wide_part = 4194304, ttl_only_drop_parts = 1; На используемом (тестовом) стенде проблемы с местом, поэтому чтобы выжать максимальное число дней в глубине хранения, поставил ... TTL toDate(end_datetime) + toIntervalDay(1) на все второстепенные столбцы. Поля, входящие в ключ, без TTL. merge_with_ttl_timeout = 14400 (дефолтный), но без дополнительного стимулирования он сам довольно лениво чистил. Пробовал периодическими MATERIALIZE TTL ClickHouse подгонять, но пару раз видимо переборщил, и нехорошее начиналось (типа того, что DJ описывал - https://t.me/clickhouse_ru/168468 ). В отличие от этого OPTIMIZE FINAL каждой ночью безопасный. Но столкнулся с тем, что при этом в старых партишнах, схлопнутых до 1 парта иногда для части записей столбцы, на которых стоит TTL toIntervalDay(1) оставались не очищенными. В итоге вернулся к периодическим MATERIALIZE TTL – но вдумчиво и аккуратно, только "MATERIALIZE TTL IN PARTITION". У меня устаревшая версия 20.10, так что, наверное, это не актуально – на 21.3 надо будет это заново смотреть.

y вас просто OPTIMIZE FINAL не срабатывает иногда, потому что места на диске нет. запускайте c optimize_throw_if_noop=1 -- увидите ошибку

>У меня устаревшая версия 20.10, так что, наверное, это не актуально – на 21.3 надо будет это заново смотреть. мои 2 копейки. я не видел глобальных исправлений связанных с ТТЛ выполненных в этом промежутке. можете тут смотреть https://github.com/ClickHouse/ClickHouse/issues/10128 полайкайте мой тикет плз (надо бы его отредактировать чтоб он на колочный ттл тоже был применим) https://github.com/ClickHouse/ClickHouse/issues/20451