А подскажите плиз куда копать дальше. Что-то залип. Есть табличка ReplacingMergeTree

над которой периодически выполняют OPTIMIZE TABLE ... ON CLUSTER sharding_name PARTITION 20230524 FINAL, т.к. в нее допихиваются данные, которые с дублями.
Кластер без репликации (только 5 шардов).
В какой-то момент внезапно, а может не очень, перестали удалятся дубли.
Появилось подозрение, что OPTIMIZE отрабатывает на 2 хостах из 5ти, причем один из нормально работающих это собственно сервер к которому коннектится клиент, делающий этот запрос.

Вижу в логах, что периодически удаляются таски на всех хостах <Information> DDLWorker: Task query-0000404897 is outdated, deleting it

task_queue большая.

SELECT count(1)
FROM system.zookeeper
WHERE path = '/clickhouse/task_queue/ddl'
┌─count()─┐
│ 1003 │
└─────────┘

Но я так понимаю тут всё в том числе и выполненное.

system.distributed_ddl_queue - нет не финишированных на здоровых и не очень хостах.

BackgroundPools пустые.

Но почему таски протухают понять не могу. Нагрузки на серверах нет. В какие-то лимиты может уперся?

Или возможно совсем не туда смотрю?

UPD: если пройтись по всем серверам и локально выполнить OPTIMIZE - дубли удаляются конкретно на этом хосте.

так а что выдается результате optimize on cluster ? on cluster показывают табличку такую со списком серверов

Выполнил сейчас еще раз OPTIMIZE уже сам. Завершился успешно на всех 5ти хостах. После этого дубли удалились.. Но через некоторое время опять появляются. Завтра еще с датаинженерами посмотрю регламентные процессы. Но если говорить про расчет хеша для шардирования... Всё равно какая-то ерунда... SELECT dt, shard, shard_calc, records, round((records / s) * 100, 0) AS pct FROM ( SELECT toDate(session_start) AS dt, mod(intHash64(session_id), 5) + 1 AS shard_calc, shardNum() AS shard, count(1) AS records, sum(records) OVER (PARTITION BY toDate(session_start)) AS s FROM sessions WHERE (toDate(session_start) >= '2023-05-24') AND (toDate(session_start) <= '2023-05-24') GROUP BY dt, shard, shard_calc ) ORDER BY dt DESC, shard ASC, shard_calc ASC Query id: f76b1ccf-d46e-45d7-bc37-490f9861fc9f ┌─────────dt─┬─shard─┬─shard_calc─┬─records─┬─pct─┐ │ 2023-05-24 │ 1 │ 1 │ 6137 │ 4 │ │ 2023-05-24 │ 1 │ 2 │ 6083 │ 4 │ │ 2023-05-24 │ 1 │ 3 │ 6038 │ 4 │ │ 2023-05-24 │ 1 │ 4 │ 6052 │ 4 │ │ 2023-05-24 │ 1 │ 5 │ 6131 │ 4 │ │ 2023-05-24 │ 2 │ 1 │ 6262 │ 4 │ │ 2023-05-24 │ 2 │ 2 │ 6153 │ 4 │ │ 2023-05-24 │ 2 │ 3 │ 6035 │ 4 │ │ 2023-05-24 │ 2 │ 4 │ 6074 │ 4 │ │ 2023-05-24 │ 2 │ 5 │ 6128 │ 4 │ │ 2023-05-24 │ 3 │ 1 │ 6162 │ 4 │ │ 2023-05-24 │ 3 │ 2 │ 6217 │ 4 │ │ 2023-05-24 │ 3 │ 3 │ 6085 │ 4 │ │ 2023-05-24 │ 3 │ 4 │ 6294 │ 4 │ │ 2023-05-24 │ 3 │ 5 │ 6100 │ 4 │ │ 2023-05-24 │ 4 │ 1 │ 6178 │ 4 │ │ 2023-05-24 │ 4 │ 2 │ 6120 │ 4 │ │ 2023-05-24 │ 4 │ 3 │ 5960 │ 4 │ │ 2023-05-24 │ 4 │ 4 │ 6130 │ 4 │ │ 2023-05-24 │ 4 │ 5 │ 6153 │ 4 │ │ 2023-05-24 │ 5 │ 1 │ 6209 │ 4 │ │ 2023-05-24 │ 5 │ 2 │ 6148 │ 4 │ │ 2023-05-24 │ 5 │ 3 │ 6278 │ 4 │ │ 2023-05-24 │ 5 │ 4 │ 6222 │ 4 │ │ 2023-05-24 │ 5 │ 5 │ 6207 │ 4 │ └────────────┴───────┴────────────┴─────────┴─────┘ Какие-то чудеса, в которые не хочется верить... а intHash64 от UInt64 нормально работает?

/clickhouse/task_queue/ddl сюда в том числе ошибки должны писаться... поищи через system.query_log по времени, на других хостах вообще запусклись твои DDL или нет?

Спасибо за подсказку. Я эти логи и в зукипере смотрел как раз. С этой проблемой разобрался тогда еще. Посмотрел код коллег - там было что-то типа: INSERT INTO distributed_over_replacingmergetree_table; sleep(X); OPTIMIZE replacingmergetree_table ON CLUSTER cluster; "Люблю" sleep в коде ) В какой-то момент объемы данных перестали успевать долетать до всех шардов за X времени. В итоге OPTIMIZE отрабатывал, но до фактической вставки на некоторых нодах.

sleep(X);sleep(X).... как быстрый костыль ))

Вряд-ли sleep(3) секунды мог работать нормально