Народ, кто нибудь с таким сталкивался? два сервера в кластере +

zookeeper, Database Engine новомодный Atomic
табличка ReplicatedMergeTree
без нагрузки на INSERT

стопаю zookeeper
таблица переходит в состояние ReadOnly

стартую zookeeper
дожидаюсь пока ReadOnlyReplicas станет 0

и делаю на всякий случай
SYSTEM RESTART REPLICAS; SYSTEM SYNC REPLICA default.test_repl
на обоих серверах
исполняется
без ошибок

но после этого
DROP TABLE default.test_repl ON CLUSTER 'all-replicated' SYNC
валится

2021.01.24 14:07:08.723023 [ 47 ] {5fe1ce55-a6f7-4b6a-b1eb-e96d7baf0b1f} <Error> executeQuery: Code: 159, e.displayText() = DB::Exception: Watching task /clickhouse/test-cluster-for-alerts/task_queue/ddl/query-0000000001 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 2 unfinished hosts (0 of them are currently active), they are going to execute the query in background (version 21.1.2.15 (official build)) (from 127.0.0.1:48432) (in query: DROP TABLE default.test_repl ON CLUSTER "all-replicated" SYNC)

в логах ничего подозрительного
2021.01.24 14:04:08.032989 [ 111 ] {439be48c-f6d9-4fbd-b83b-aea200225a08} <Debug> DDLWorker: Processing task query-0000000001 (DROP TABLE default.test_repl ON CLUSTER `all-replicated` NO DELAY)
2021.01.24 14:04:08.038707 [ 111 ] {439be48c-f6d9-4fbd-b83b-aea200225a08} <Debug> DDLWorker: Executing query: DROP TABLE default.test_repl NO DELAY
2021.01.24 14:04:08.039701 [ 111 ] {67f828e5-c5fd-4146-af7a-5f893be0c44c} <Debug> executeQuery: (from 0.0.0.0:0, user: , using production parser) /* ddl_entry=query-0000000001 */ DROP TABLE default.test_repl NO DELAY
2021.01.24 14:04:08.044575 [ 111 ] {67f828e5-c5fd-4146-af7a-5f893be0c44c} <Information> default.test_repl (cd3a90b5-71f8-46aa-bf84-2299b1ebc61d): Stopped being leader
2021.01.24 14:04:08.052720 [ 111 ] {67f828e5-c5fd-4146-af7a-5f893be0c44c} <Debug> DatabaseCatalog: Waiting for table cd3a90b5-71f8-46aa-bf84-2299b1ebc61d to be finally dropped

что он там ждет то теперь?

А подскажите пожалуйста где вообще описан atomic? В документации не могу ничего о нем найти

смотрите митап от 1го октября

а просто drop ( без on cluster ) работает?

Да, проходят, имеет смысл завести какой нибудь issue?

наверное стоит создать issue кубернетис? имена хостов какие в drop on cluster в zk ?

да кубер, но я могу наверное попробовать и под docker-compose поведение воспроизвести да, есть ньюанс, имена хостов в кластере это имена k8s service они слегка отличаются от имен подов на которых это запускается... но имена реплик, в ReplicatedMergeTree это тоже имена сервиса один сервис, один под судя по всему, таблица на самом деле удаляется,но просто не приходит подтверждение когда делается ON CLUSTER ... SYNC...

аа, я понял о чем вы наверное из-за SYNC ждет 480s <database_atomic_delay_before_drop_table_sec>480</database_atomic_delay_before_drop_table_sec> ON CLUSTER 180s distributed_ddl_task_timeout 180 поменяйте в config.xml на 30 сек. <database_atomic_delay_before_drop_table_sec>30

спасибо большое, не знал про такую опцию но что-то вообще не помогло эта штука через system.settings не отображается... и не понятно есть она или нет похоже что оно вообще при SYNC с тойже ошибкой вылетает даже если вообще несуществующую таблицу попросить удалить сейчас воспроизведу через docker-compose и засабмичу баг

похоже дело в DNS именах хостов то есть если удалять несуществующую таблицу через DROP TABLE IF EXISTS default.any_table ON CLUSTER SYNC то вываливается ошибка docker-compose exec clickhouse-0-0-0 clickhouse-client -q "DROP TABLE IF EXISTS default.any_name ON CLUSTER 'default' SYNC" clickhouse-0-0 9000 0 1 0 Received exception from server (version 21.1.2): Code: 159. DB::Exception: Received from localhost:9000. DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000000001 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 1 unfinished hosts (0 of them are currently active), they are going to execute the query in background. когда Pod у меня это clickhouse-0-0-0 а Service это clickhouse-0-0 и в remote_servers прописан именно clickhouse-0-0:9000 (разрулил через alias в docker-compose) тогда видимо при DROP TABLE ... SYNC что-то ожидается в ddl Очереди из ZK ... и в результате не находится интересно что? имя хоста? поведение на docker-compose воспроизводится начиная с 20.10 когда SYNC вообще появился

блин поставил <database_atomic_delay_before_drop_table_sec>10</database_atomic_delay_before_drop_table_sec> перестало воспроизводиться ... видимо что то не так делаю

воспроизвелось в docker-compose <distributed_ddl_task_timeout>20</distributed_ddl_task_timeout> и <database_atomic_delay_before_drop_table_sec>1</database_atomic_delay_before_drop_table_sec> блин я не понимаю что не так с DNS пофигу, DNS не влияет похоже бага именно в atomic он не отдает в ddl queue в finished никаких результатов после физического удаления таблицы https://gist.github.com/Slach/a7f2946a108883f6b1d5585b1b5b6b0d