Появилось после 018.10.01 06:08:35.927008 [ 48 ] <Error> default.graphite (ReplicatedMergeTreeAlterThread): void DB::ReplicatedMergeTreeAlterThread::run(): Code: 999, e.displayText() = ZooKeeperImpl::Exception: Session expired (Session expired), e.what() = ZooKeeperImpl::Exception,

Ну это зукиперы падали, обычно там данные в детач по моему попадают. А зачем вы зукиперы роняете ?

не ронял специально, в логе ЗК: 2018-10-01 06:08:35,895 [myid:8] - WARN [QuorumPeer[myid=8]/0.0.0.0:2181:Follower@87] - Exception when following the leader java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:392) at org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63) at org.apache.zookeeper.server.quorum.QuorumPacket.deserialize(QuorumPacket.java:83) at org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:99) at org.apache.zookeeper.server.quorum.Learner.readPacket(Learner.java:153) at org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:83) at org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:846) 2018-10-01 06:08:35,923 [myid:8] - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@362] - Exception causing close of session 0x0 due to java.io.IOException: ZooKeeperServer not running 2018-10-01 06:08:36,095 [myid:8] - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@362] - Exception causing close of session 0x0 due to java.io.IOException: ZooKeeperServer not running 2018-10-01 06:08:36,158 [myid:8] - WARN [SyncThread:8:FileTxnLog@338] - fsync-ing the write ahead log in SyncThread:8 took 4470ms which will adversely effect operation latency. See the ZooKeeper troubleshooting guide 2018-10-01 06:08:36,158 [myid:8] - WARN [SyncThread:8:SendAckRequestProcessor@64] - Closing connection to leader, exception during packet send

Ну у вас умер зукипер

Может оом киллер пришел за ним?

У меня умирал по месту на диске...

нет, памяти на хостах по 80-100Г свободно, и места ещё 10ТБ мин. Понятно, что ЗК тормозят так как на одних хостах с КХ, но почему данные пропали, не ясно. В логах вообще ничего не могу найти

Коллеги, подскажи может я что то делаю не так, есть словарь типа complex_key_cache который смотрит на HTTP запрос. При запросе большого количества элементов функция dictGet* периодически возвращает пустые данные вместо результата. Если уменьшить количество элементов до ~500 все становится нормально.

нет, памяти на хостах по 80-100Г свободно, и места ещё 10ТБ мин. Понятно, что ЗК тормозят так как на одних хостах с КХ, но почему данные пропали, не ясно. В логах вообще ничего не могу найти

в system.replication_queue что-нибудь есть? или пропали и из очередей тоже?

нет, памяти на хостах по 80-100Г свободно, и места ещё 10ТБ мин. Понятно, что ЗК тормозят так как на одних хостах с КХ, но почему данные пропали, не ясно. В логах вообще ничего не могу найти

Ну вы так не делайте и станет сразу все лучше

Коллеги, подскажи может я что то делаю не так, есть словарь типа complex_key_cache который смотрит на HTTP запрос. При запросе большого количества элементов функция dictGet* периодически возвращает пустые данные вместо результата. Если уменьшить количество элементов до ~500 все становится нормально.

Посмотрите логи веб сервера и руками запросы большие поделайте

в system.replication_queue что-нибудь есть? или пропали и из очередей тоже?

Там только сегодняшнее, видимо, пропали.

Коллеги, добрый день! Подскажите, что можно сделать с такой ошибкой? <Error> executeQuery: Code: 999, e.displayText() = DB::Exception: Cannot allocate block number in ZooKeeper: ZooKeeperImpl::Exception: No node, path: /clickhouse/tables/01/{table_name}/block_numbers/20150713/block Не проходят инсерты. detach partition не делается, такая же ошибка

и зукипер каждые несколько секунд пишет INFO Got user-level KeeperException when processing sessionid:0x1662f211bde0003 type:create cxid:0x6e7b zxid:0x1fcf57 txntype:-1 reqpath:n/a Error Path:/clickhouse/tables/02/{table_name}/block_numbers/20170713 Error:KeeperErrorCode = NoNode for /clickhouse/tables/02/{table_name}/block_numbers/20170713 (org.apache.zookeeper.server.PrepRequestProcessor)

День добрый. Можете подсказать почему в варианте 1 игнорируется индекс и читается вся таблица? Движек ReplacingMergeTree (Deleted в индексе нет) Вариант 1 SELECT splitByChar('=', arrayJoin(Tags))[2] AS value FROM graphite.graphite_tagged WHERE ((Tag1 LIKE '__name__=%') AND match(Tag1, '__name__=system.load')) AND (arrayJoin(Tags) LIKE 'ms=%') AND (Date >= '2018-09-19') AND (Deleted = 0) GROUP BY value ORDER BY value ASC LIMIT 10000 56 rows in set. Elapsed: 34.204 sec. Processed 789.86 million rows, 255.83 GB (23.09 million rows/s., 7.48 GB/s.) Вариант 2 SELECT splitByChar('=', arrayJoin(Tags))[2] AS value FROM graphite.graphite_tagged WHERE ((Tag1 LIKE '__name__=%') AND match(Tag1, '__name__=system.load')) AND (arrayJoin(Tags) LIKE 'ms=%') AND (Date >= '2018-09-19') GROUP BY value ORDER BY value ASC LIMIT 10000 56 rows in set. Elapsed: 1.701 sec. Processed 789.84 million rows, 23.23 GB (464.24 million rows/s., 13.65 GB/s.)

Там только сегодняшнее, видимо, пропали.

Если они были то они свалились в детачед если их нет то их просто там не было, если зукипер был мертв то таблицы были в риадонли

Коллеги, добрый день! Подскажите, что можно сделать с такой ошибкой? <Error> executeQuery: Code: 999, e.displayText() = DB::Exception: Cannot allocate block number in ZooKeeper: ZooKeeperImpl::Exception: No node, path: /clickhouse/tables/01/{table_name}/block_numbers/20150713/block Не проходят инсерты. detach partition не делается, такая же ошибка

Там же написано такой ноды в зукипере нет, вы что стёрли все данные из зукипера?

у нас зукипер упал с OutOfMemory, после того как его подняли появилась такая ошибка. Можно руками создать ноду в зукипере?

Мне кажется проще переместить данные, создать таблицу в кх, и аттачнуть данные

Ну или даже не аттачить а просто пусть сольет данные с реплики

А отчего у вас вдруг зукипер аут оф мемори он же потребляет памяти минимум

Все три зукипера умерли одновременно?

День добрый. Можете подсказать почему в варианте 1 игнорируется индекс и читается вся таблица? Движек ReplacingMergeTree (Deleted в индексе нет) Вариант 1 SELECT splitByChar('=', arrayJoin(Tags))[2] AS value FROM graphite.graphite_tagged WHERE ((Tag1 LIKE '__name__=%') AND match(Tag1, '__name__=system.load')) AND (arrayJoin(Tags) LIKE 'ms=%') AND (Date >= '2018-09-19') AND (Deleted = 0) GROUP BY value ORDER BY value ASC LIMIT 10000 56 rows in set. Elapsed: 34.204 sec. Processed 789.86 million rows, 255.83 GB (23.09 million rows/s., 7.48 GB/s.) Вариант 2 SELECT splitByChar('=', arrayJoin(Tags))[2] AS value FROM graphite.graphite_tagged WHERE ((Tag1 LIKE '__name__=%') AND match(Tag1, '__name__=system.load')) AND (arrayJoin(Tags) LIKE 'ms=%') AND (Date >= '2018-09-19') GROUP BY value ORDER BY value ASC LIMIT 10000 56 rows in set. Elapsed: 1.701 sec. Processed 789.84 million rows, 23.23 GB (464.24 million rows/s., 13.65 GB/s.)

Какая структура таблицы?

Какая структура таблицы?

CREATE TABLE IF NOT EXISTS graphite.graphite_tagged ( Date Date, Tag1 String, Path String, Tags Array(String), Version UInt32, Deleted UInt8 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/{layer}-{shard}/graphite_tagged', '{replica}', Date, (Tag1, Path, Date), 1024, Version);

Там же написано такой ноды в зукипере нет, вы что стёрли все данные из зукипера?

нет, не трогал зукипер

нет, не трогал зукипер

Да я это Дмитрию писал же а не вам

ок

CREATE TABLE IF NOT EXISTS graphite.graphite_tagged ( Date Date, Tag1 String, Path String, Tags Array(String), Version UInt32, Deleted UInt8 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/{layer}-{shard}/graphite_tagged', '{replica}', Date, (Tag1, Path, Date), 1024, Version);

Сложно сказать, смотрите лог КХ-сервера, но можно попробовать в where замените arrayJoin на arrayCount, внутри которого LIKE. И так же, убрать условия с Tag1, использовав функцию extractURLParameter(URL, name)

Сложно сказать, смотрите лог КХ-сервера, но можно попробовать в where замените arrayJoin на arrayCount, внутри которого LIKE. И так же, убрать условия с Tag1, использовав функцию extractURLParameter(URL, name)

По логам то он как раз из-за Deleted минует индекс, но хотелось понять почему

ребят, объясните плиз, для чего нужна репликация и когда ее стоит использовать

https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F_(%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D0%BA%D0%B0)

это я читал)

ребят, объясните плиз, для чего нужна репликация и когда ее стоит использовать

Когда нужна высокая доступность, когда нужно горизонтальное масштабирование

https://toster.ru/q/514054

Когда нужна высокая доступность, когда нужно горизонтальное масштабирование

при будущем объеме в 1 млн кликов в сутки, стоит заранее реализовывать с репликацией?

Это не связано

при будущем объеме в 1 млн кликов в сутки, стоит заранее реализовывать с репликацией?

Если вам не нужна высокая доступность и горизонтальное масштабирование то нет, ваш вопрос никак не связан с количеством данных, тут другие причины

Если вам не нужна высокая доступность и горизонтальное масштабирование то нет, ваш вопрос никак не связан с количеством данных, тут другие причины

недоступность БД будет нести убытки. Значит и мне нужна высокая доступность)

Ну вот значит без реплики никуда

при будущем объеме в 1 млн кликов в сутки, стоит заранее реализовывать с репликацией?

Для КХ это ерунда. Добавлял новые реплики, не скажу сколько мильярдов было (не один десяток), но 5 Тб прососало по репликации за пол дня примерно, даже не чихнуло, при том что запись новых данных не останавливал.

День добрый. Можете подсказать почему в варианте 1 игнорируется индекс и читается вся таблица? Движек ReplacingMergeTree (Deleted в индексе нет) Вариант 1 SELECT splitByChar('=', arrayJoin(Tags))[2] AS value FROM graphite.graphite_tagged WHERE ((Tag1 LIKE '__name__=%') AND match(Tag1, '__name__=system.load')) AND (arrayJoin(Tags) LIKE 'ms=%') AND (Date >= '2018-09-19') AND (Deleted = 0) GROUP BY value ORDER BY value ASC LIMIT 10000 56 rows in set. Elapsed: 34.204 sec. Processed 789.86 million rows, 255.83 GB (23.09 million rows/s., 7.48 GB/s.) Вариант 2 SELECT splitByChar('=', arrayJoin(Tags))[2] AS value FROM graphite.graphite_tagged WHERE ((Tag1 LIKE '__name__=%') AND match(Tag1, '__name__=system.load')) AND (arrayJoin(Tags) LIKE 'ms=%') AND (Date >= '2018-09-19') GROUP BY value ORDER BY value ASC LIMIT 10000 56 rows in set. Elapsed: 1.701 sec. Processed 789.84 million rows, 23.23 GB (464.24 million rows/s., 13.65 GB/s.)

у вас в обоих случаях Processed 789.84 million rows, т.е. индекс одинаково используется. Странно почему такая разница во времени из-за одной колонки. Я бы проверил время 1. если deleted перенести в select из where 2. выполнить запрос с настройкой optimize_move_to_prewhere = false 3. унести arrayJoin на уровень выше

омг, не могу подключиться к кликхаусу клиентом с ubuntu на сервере самосгенеренный сертификаты стоят, это может повлияать?

у вас в обоих случаях Processed 789.84 million rows, т.е. индекс одинаково используется. Странно почему такая разница во времени из-за одной колонки. Я бы проверил время 1. если deleted перенести в select из where 2. выполнить запрос с настройкой optimize_move_to_prewhere = false 3. унести arrayJoin на уровень выше

Вы не правы, разница ни в строках, а в Гб 255.83 GB против 23.23 GB

может быть столбец Deleted очень большой. что у него за тип данных?

CREATE TABLE IF NOT EXISTS graphite.graphite_tagged ( Date Date, Tag1 String, Path String, Tags Array(String), Version UInt32, Deleted UInt8 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/{layer}-{shard}/graphite_tagged', '{replica}', Date, (Tag1, Path, Date), 1024, Version);

0 или 1

Вы не правы, разница ни в строках, а в Гб 255.83 GB против 23.23 GB

да, я третья черепашка.

омг, не могу подключиться к кликхаусу клиентом с ubuntu на сервере самосгенеренный сертификаты стоят, это может повлияать?

Нет если коннектиться к 9000 порту

Нет если коннектиться к 9000 порту

эм... а если в конфиге кликхауса только ссл порты включены?

Ну а какая разница если вы коннектитесь к 9000 порту

Клиент же умеет только по тисипи наверно ходить на 9000

Так что других вариантов быть и не может

По логам то он как раз из-за Deleted минует индекс, но хотелось понять почему

Может быть проявляются какие-то особенности вытаскивания "индексных" выражений из "сложносочиненного" дерева условий WHERE? Попробуйте переставить условия местами или заключить всё кроме условия на индекс в скобки.

недоступность БД будет нести убытки. Значит и мне нужна высокая доступность)

еще при условии что вы не будете делать изменение и удаление данных, репликация может заменить backup

Может быть проявляются какие-то особенности вытаскивания "индексных" выражений из "сложносочиненного" дерева условий WHERE? Попробуйте переставить условия местами или заключить всё кроме условия на индекс в скобки.

спасибо, попробую поиграться

спасибо, попробую поиграться

Дайте знать потом.

Подскажите, как address из system.query_log распарсить. upd нашел https://clickhouse.yandex/docs/en/query_language/functions/ip_address_functions/

Всем привет! Есть ли какой-то способ научить sumMap работать со строками? Хотелось бы получить на выходе, например, (['a', 'c', 'd'], [5, 10, 5])

Всем привет! Есть ли какой-то способ научить sumMap работать со строками? Хотелось бы получить на выходе, например, (['a', 'c', 'd'], [5, 10, 5])

Можно "размножить" строки с помощью array join, произвести все нужные вычисления, а потом обратно собрать с помощью groupArray.

Или сделать ремаппинг строк в числа при помощи словаря.

Продублирую , так как нашел несколько человек с этой проблемой и решения ни у одного нет , как понять почему кх считает некоторые реплики не активными и не выполняет на них запросы on cluster ? @milovidov_an а может подскажете куда копать если он кластер не выполняется на втором шарде, сперва подумал в версии проблема, накатил ансиблом аналогичный тестовый стенд все выполняется он кластер без проблем , в system.clusters все реплики есть , порты все открыты клиентом и телнетом между серверам все коннектит , но на первом шарде запросы он кластер выполняются , даже если его запустить на репликах второго шарда, а на втором дает таймаут, при этом ошибок в еррор логе кх нет никаких на всех репликах , уже даже не знаю в какую сторону копать ↘️ Progress: 2.00 rows, 116.00 B (1.69 rows/s., 97.88 B/s.) 49%Received exception from server (version 18.12.17): Code: 159. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000000015 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.

Поддерживаю этого господина, у меня такая же хрень.

Такое ощущение, что кликхаус вообще не пробует читать из /clickhouse/task_queue/ddl/

Продублирую , так как нашел несколько человек с этой проблемой и решения ни у одного нет , как понять почему кх считает некоторые реплики не активными и не выполняет на них запросы on cluster ? @milovidov_an а может подскажете куда копать если он кластер не выполняется на втором шарде, сперва подумал в версии проблема, накатил ансиблом аналогичный тестовый стенд все выполняется он кластер без проблем , в system.clusters все реплики есть , порты все открыты клиентом и телнетом между серверам все коннектит , но на первом шарде запросы он кластер выполняются , даже если его запустить на репликах второго шарда, а на втором дает таймаут, при этом ошибок в еррор логе кх нет никаких на всех репликах , уже даже не знаю в какую сторону копать ↘️ Progress: 2.00 rows, 116.00 B (1.69 rows/s., 97.88 B/s.) 49%Received exception from server (version 18.12.17): Code: 159. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000000015 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.

если проблема серьезная и болит, продублируйте сюда с описанием как воспроизвести - https://github.com/yandex/ClickHouse/issues

Делаю импорт ~60 гб csv в SummingMergeTree через `clickhouse-client -query "INSERT INTO ... FORMAT CSV"`, процесс прибивает OOM. После рестарта в таблице оказывается число записей кратное 2^20. Настройки стандартные. Сервер небольшой, 8гб ОЗУ. Попробовал ограничить max_memory_usage_for_all_queries=4gb, упал на 40% импорта, вместо 10% как раньше. Какие параметры ещё подтюнить, чтобы успешно импортнуть данные?

если проблема серьезная и болит, продублируйте сюда с описанием как воспроизвести - https://github.com/yandex/ClickHouse/issues

да хрен знает как воспроизвести , если все сделать с нуля с теми же конфигами все работает , как говорится если бы я знал как воспроизвести я бы знал в чем причина, но тут у кх нет инстурментов описанных в доке, чтобы провести диагностику, и в логах ничего нет, и воспроизвести никак не получается(пробовал развернуть полностью аналогичный кластер тем же рецептом ансибла, все ок работает).

У меня есть 2 кластера, один новый на нём работает. Второй старый, который я обновлял несколько раз - на нём не работет. Может в этом причина.

У меня есть 2 кластера, один новый на нём работает. Второй старый, который я обновлял несколько раз - на нём не работет. Может в этом причина.

ну я тоже обновлял кластер много раз , но не вижу причин в этом чтобы оно не работало

Делаю импорт ~60 гб csv в SummingMergeTree через `clickhouse-client -query "INSERT INTO ... FORMAT CSV"`, процесс прибивает OOM. После рестарта в таблице оказывается число записей кратное 2^20. Настройки стандартные. Сервер небольшой, 8гб ОЗУ. Попробовал ограничить max_memory_usage_for_all_queries=4gb, упал на 40% импорта, вместо 10% как раньше. Какие параметры ещё подтюнить, чтобы успешно импортнуть данные?

Делите на части, что поделать

Продублирую , так как нашел несколько человек с этой проблемой и решения ни у одного нет , как понять почему кх считает некоторые реплики не активными и не выполняет на них запросы on cluster ? @milovidov_an а может подскажете куда копать если он кластер не выполняется на втором шарде, сперва подумал в версии проблема, накатил ансиблом аналогичный тестовый стенд все выполняется он кластер без проблем , в system.clusters все реплики есть , порты все открыты клиентом и телнетом между серверам все коннектит , но на первом шарде запросы он кластер выполняются , даже если его запустить на репликах второго шарда, а на втором дает таймаут, при этом ошибок в еррор логе кх нет никаких на всех репликах , уже даже не знаю в какую сторону копать ↘️ Progress: 2.00 rows, 116.00 B (1.69 rows/s., 97.88 B/s.) 49%Received exception from server (version 18.12.17): Code: 159. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000000015 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.

А что написано в конфигурации серверов про <distributed_ddl> (у меня например на одном сервере конфигурация по умолчанию тянулась с какой-то старой версии КХ, где часть настроек отсутствовала)? И что в логах про DDLWorker?

А что написано в конфигурации серверов про <distributed_ddl> (у меня например на одном сервере конфигурация по умолчанию тянулась с какой-то старой версии КХ, где часть настроек отсутствовала)? И что в логах про DDLWorker?

конфиги идентичные так как раскатываются ансиблом , я их три раза сравнивал по размеру байт в байт

а где смотреть логи ддлворкер ?

а где смотреть логи ддлворкер ?

в логах КХ по ключевому слову DDL / DDLWorker.

конфиги идентичные так как раскатываются ансиблом , я их три раза сравнивал по размеру байт в байт

И всё же - что написано в <distributed_ddl>?

сейчас все грепну

И можно потом глянуть в zookeeper.

И всё же - что написано в <distributed_ddl>?

<distributed_ddl> <!-- Path in ZooKeeper to queue with DDL queries --> <path>/clickhouse/task_queue/ddl</path> </distributed_ddl>

Гляньте ещё на всякий случай на месте ли ваши запросы: SELECT * FROM system.zookeeper WHERE path = '/clickhouse/task_queue/ddl' FORMAT VerticalRaw

Гляньте ещё на всякий случай на месте ли ваши запросы: SELECT * FROM system.zookeeper WHERE path = '/clickhouse/task_queue/ddl' FORMAT VerticalRaw

да три запроса моих висит там

да три запроса моих висит там

И список серверов я так понимаю там верный (около запроса). Так что в логах про DDLWorker?

И список серверов я так понимаю там верный (около запроса). Так что в логах про DDLWorker?

список правильный, в логах ошибок не вижу записей про ддл кроме тех что я привел в проблеме ↘️ Progress: 2.00 rows, 116.00 B (1.69 rows/s., 97.88 B/s.) 49%Received exception from server (version 18.12.17): Code: 159. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000000015 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.

А на тех хостах где не выполнилась задание?

Есть что-то?

на самом деле на них я сейчас и смотрю

на тех что выполнили тоже нет ошибки , после ошибки еще есть стектрейс но не уверен чем он тут может помочь

0. /usr/bin/clickhouse-server(StackTrace::StackTrace()+0x16) [0x9491e46] 1. /usr/bin/clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::alloc ator<char> > const&, int)+0x22) [0x3019952] 2. /usr/bin/clickhouse-server(DB::DDLQueryStatusInputSream::readImpl()+0x1096) [0x70b6116] 3. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x698ecfa] 4. /usr/bin/clickhouse-server(DB::AsynchronousBlockInputStream::calculate()+0x56) [0x6984316] 5. /usr/bin/clickhouse-server() [0x6984780] 6. /usr/bin/clickhouse-server(ThreadPool::worker()+0x19e) [0x9692b5e] 7. /usr/bin/clickhouse-server() [0x9e659ef] 8. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7fb0b58d16ba] 9. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fb0b4ef241d]

опа кажется я нашел

2018.09.30 10:29:59.492081 [ 40 ] <Debug> DDLWorker: Will not execute task query-0000000013: There is no a local address i n host list

в обычном логе

в обычном логе

Блин :) А перед этим вы в волшебном проверяли? :)

проверял в еррор логе

проверял в еррор логе

Ok. Значит проблема наверное где-то тут: https://github.com/yandex/ClickHouse/blob/c6ab6fa1a8a2b6b77a0253f6b98583c8e2db400a/dbms/src/Interpreters/DDLWorker.cpp#L301

А как у вас настроены названия хостов?

проблема что в хостс прописан хостнейм как 127.0.0.1

это в целом очевидно из ошибки

хотя тоже странно по идее хостс конфигурится ансиблом но видимо это в старом рецепте не учитывалось