Всем привет! Недавно обнаружили, что после вставки большой пачки через

clickhouse-client в редких случаях встречаем странное поведение. А конкретно - пачка вставляется, но вставщик получает ошибку по таймауту, дальше срабатывает уже самописная логика где идёт перевставка пачки снова. Это ведет к дублям данных. Выглядит это так:
insert_error=$(cat $ FILE | clickhouse-client --receive_timeout=180 --send_timeout=180 --host $CH_HOST -u $CH_USER --password $CH_PASSWORD --port $CH_PORT 2>&1)
STATUS=$?
if [ $STATUS -eq 0 ]; then
отстук метрики
else
вставляем снова через 180 секунд
fi
В штатном режиме пачки хоть и больше ляма строк, но вставляться за минуту успевают в большинстве. Исключение составляют затупы сети, либо зукипера, либо самого клика.
Можно ли эту проблему обойти каким то образом? Почему клик может не отдавать успешный статус код, если он вставил пачку? Или это баг и нужно открывать тикет на гитхабе? Это пограничные неприятные случаю из-за которых приходиться мутации вызывать с удалением данных.
Вот пример ошибки в таким моменты:
Code: 209. DB::NetException: Timeout exceeded while reading from socket (159.69.160.212:9000): while receiving packet from 150.60.150.210:9000
Версия сервера - 22.2.2.1
Версия клиента - 21.2.2.8

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

Клик не даёт гарантий вставки если она асинхронная, у нас же проставлен параметр ожидать вставки пачки во все реплики и оно работает в 99% случаев. Но раз в пару месяцев стреляет неприятно

Дак и на асинхронную он даёт гарантию

если синхронная - тоже никаких гарантий. Если у вас большая пачка вставляется, часть данных может вставиться, а часть упадёт тут вот можете поиграться с настройками для атомарной вставки https://kb.altinity.com/altinity-kb-queries-and-syntax/atomic-insert/#insert-with-adjusted-settings-atomic

Ну всмысле, если клику ты отдал данные, а он тебе ответил ок, это разве не гарантия?

если ОК вернул, то всё хорошо, но ретраить вставку если была ошибка - плохая идея обычно)

Но ведь, он сохраняет хэш последних вставок и если ты ретрайнишь, то в теории он может понять, что это одно и тоже и не вставить

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

Это да

Дык а как тогда манажить вставкой, если произошла ошибка? Руками идти смотреть system.query_log?

мы исходим из самого плохого варианта, часть данных вставилась поэтому вставка в таблицу tmp со структурой такой же как и в основной таблице truncate table tmp insert into tmp alter table main attach partition from tmp если что-то идёт не так при вставке, мы просто ретраим, таблица затранкейтится и дуюлей не будет

понял, в моём случае одновременно работают 10+ вставщиков, поэтому не уверен что такая схема прокатит, но на карандаш идею взял, спасибо

Кстати. А как текущая схема спасает когда "часть данных вставилась"? Вот прошла чистка, вы вставили пачку, а там 50% дошло и вставилось, далее аттач?

До атттача не доходит если инсерт упал