Alexey Zatelepin

> Ведь наверно CH сохраняет крайние значения колонок, по которому делается нарезка партиций и не обращается к лишним кускам? Верно. > А что мешает это делать в таблицах в це...

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

Интересно. Получается, удаленный клиент записывал данные в Distributed таблицу, и ошибка возникала на серверах, куда происходила запись (не на шардах), а если локальный клиент...

На недавнем митапе был доклад: https://youtu.be/7Wcq6_9727A?t=24m59s Вкратце: в целом работает, но есть множество проблем с парсингом запросов, которые генерирует tableau. Пр...

Ну да, похоже сервер на старте запускает мерж кусков и тут же падает. Вписать drop в метадату - оригинальное решение, но не сработает :) Может, всё-таки обновиться, хотя бы не...

А можете пример такого запроса показать? Пытаюсь повторить примерно так: seq 0 999999 | parallel -j10 'clickhouse-client --query "SELECT nonexistent{}();"' 2>/dev/null, память...

New это как раз могут быть как свежие данные, которые льются в таблицу, так и успешно помутированные данные. А сколько вообще в таблице активных кусков с data_version < 352802...

Так записи с разным значением ключа партиционирования попадут в разные партиции, соответственно ничего реплейситься не будет. Или значение ключа как раз остаётся неизменным?

Попробовал с похожим (насколько это возможно) запросом - всё равно не получается повторить. А с какой версии вы обновлялись? И что это за функции вообще? Это у вас какие-то са...

А почему вы выключили internal_replication? Сейчас если на обе реплики записывать, то одна из реплик просто выкинет кусок из-за дедупликации, а потом всё равно его скачает.

а сколько у вас партиций в таблице? select count(distinct partition_id) from system.parts where database = '<database>' and table = '<table>'

А что будет, если просто попробовать прочитать проблемный столбец проблемного куска? Например, так: SELECT sum(cityHash64(oc39)) FROM db.logs_local WHERE _part='20170205_20170...

Как именно вы копировали данные на новый кластер ZK? ClickHouse берёт id-ки кусков из sequential нод ZK, если там внутренние счетчики обнулились, то ничего работать не будет.

Дропать партицию можно, ускорит вряд ли. Переименовывать тоже можно. А что в логах, system.replication_queue для этой таблицы?

Интересно, что в трейсе есть функция __libc_free, хотя у нас должен jemalloc использоваться. Это официальная сборка?

Попробуем поймать... Скажите, с какой версии обновились? Какая конфигурация кластера? Чем отличаются Distributed таблицы, в которые INSERT работает, от тех, в которые не работ...

А в чём причина отставания и нагоняется ли оно? Попробуйте посмотреть в таблицу system.replication_queue, нет ли проблем с выполнением лога репликации.

С таким же временем? По дефолту там 50мс, так что должно быть меньше... Ну и connect timeout не может быть больше max_execution_time, может у вас оно изменено.

Останавливается всё это как? сервер не начинает принимать запросы? или просто не идут другие мержи?

Как это может работать? :) Если добавить в ключ новое поле, а данные в кусках не обновить, то мержи могут выдавать неправильный результат.