TABLE MODIFY TTL ON CLUSTER и все остальные DDL даже не пытаются запуститься, просто по таймауту отваливаются
Ап, может кто знает что подкрутить можно
чего? это же специально сделано так.
ну условно делается что-то тяжёлое с таблицей t1 on cluster минут на 20, в это время другой процесс запускает drop partition on cluster на t2, и он отваливается по таймауту и падает пайплайн у нас из-за этого, хотя drop это простая операция. Получается только отказываться от on cluster и запускать вручную на шардах?
эээ , при чем тут oncluster ? покажите с какой ошибкой падает ваш drop
DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000620939 is executing longer than distributed_ddl_task_timeout (=300) seconds. There are 1 unfinished hosts (0 of them are currently active), they are going to execute the query in background (version 21.3.15.4 (official build)) (from 10.64.128.14:54140) (in query: ALTER TABLE analytics_adjust_events_tmp_shard ON CLUSTER ch_shards DROP PARTITION 20210825
при этом видно что пока первый ddl не закончит работать, в ЗК в пути /clickhouse/task_queue/ddl/query-0000620939/active пусто, обработка запроса даже не начинается
ну on cluster тут ни при чем. Без oncluster, drop будет также ждать, потом ваш клиент отвалится по таймауту. TTL можно менять моментально если надо, но тогда не будет пересчитываться TTL info
не правда. Все вообще не так
так без on cluster drop проходить если запустить на каждой ноде отдельно
и зависнет на какой-нибудь где идет alter table modify ttl
даже если мы делаем drop в другой таблице?
нет. DDDL точно также не зависят от друг друга. DDDL это тупой хелпер, он делает ровно тоже самое что вы руками выполняя на каждой ноде
извините, не понял, нет - не зависнет? Когда висит запрос drop partittion on cluster я могу зайти на каждый шард и выполнить drop вручную
dddl запросы выполняются независимо, там нет никакой очереди.
Обсуждают сегодня