привет!
есть distributed таблица на кластере из 2 шардов (по 2 реплики на каждом). Замечено, что при вставке большого количества строк данные начинают теряться. Опытным путем найдено число строк (~5,24млн), на котором резко строки начинают пропадать (работает для таблиц как с двумя, так и с сотней полей одинаково).
Что происходит и что здесь можно сделать?

ключ шардирования какой?

лтс будет поддерживаться год

Коллеги, а где вся кликхаусовская банда? на девовском канале тишина уже два дня...

Мигрировали на Vertica

лол

все приблизительно такие murmurHash2_32(product_cd) % 2

но в ней не будет всего того, о чем говорят на митапах? (вот например в последнем много для нас интересного в 20.5)

не будет

Ну и так понимаю,не-лтс релизы - это новые фичи, но по тонкому льду)

Ну известные баги там стараются тоже фиксить, просто в некоторых компаниях обновить мажорную версию может быть сильно запарно, а багфиксы проще.

Да, апдейт мажорной версии, как правило, сопряжен с большим количество изменений которые надо внести у себя. Надо чаще страдать :)

уточнение: вставляю данные из csv через clickhouse-client

как проверяешь пропадают ли строки или нет?

по количеству) вставляю в пустую таблицу

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

плюсую, то же могу сказать и про обработку из кафки через матвью - очеред прочитана, новых сообщений нет, но количество записей в целевой таблице меньше количества переданного в топик. Ошибок нет. Пробовал на 10млн - через часа два после прочитки последнего сообщения из топика кафки все данные появляются в целевой таблице, вероятно внутри клика как-то обрабатываются, утряхиваются...

спасибо, сейчас попробуем, отпишусь, если поможет)

Ребят, поискал в гите - не нашел такой баг (мож конечно и фича, или я сам дурак)

create table tab_name on cluster <cluster> as <teable_with_engine=Merge>  engine=ReplicatedMergeTree ...

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

2020.06.22 16:26:20.057518 [ 3772706 ] {} <Error> ThreadPool: Exception in ThreadPool(max_threads: 32, max_free_threads: 32, queue_size: 32, shutdown_on_exception: 1).: Code: 122, e.displayText() = DB::Exception: Table columns structure in ZooKeeper is different from local table structure: Cannot attach table <db>.<table_name> from metadata file /var/lib/clickhouse/metadata/<db>/<table_name>.sql from query ATTACH TABLE <table_name>

При проверке в ZK оказалось что он магическую колонку

_table String

счел как боевую, и собственно на нее и ругался
При этом в метаданных кх (/var/lib/clickhouse/metadata/<db>/<table_name>.sql, идентичных на машинах кластера) этой колонки естественно не было

Собственно вопрос: баг? / фича? (+= заводить в гите?)

*+ я теперь опасаюсь за потенциальные проблемы с _shard_num колонкой

create table tab_name on cluster <cluster> as <teable_with_engine=Merge>  engine=ReplicatedMergeTree ...

2020.06.22 16:26:20.057518 [ 3772706 ] {} <Error> ThreadPool: Exception in ThreadPool(max_threads: 32, max_free_threads: 32, queue_size: 32, shutdown_on_exception: 1).: Code: 122, e.displayText() = DB::Exception: Table columns structure in ZooKeeper is different from local table structure: Cannot attach table <db>.<table_name> from metadata file /var/lib/clickhouse/metadata/<db>/<table_name>.sql from query ATTACH TABLE <table_name>

_table String

При проверке в ZK оказалось что он магическую колонку
_table String

у тебя есть такая колонка в ддл?