Доброе утро, коллеги! Может вы что-то подскажите по следующей ситуации. Загружаем

словари в витрины в CH по следующему алгоритму:
- создали 2 таблицы с одинаковой структурой: целевая и tmp; имена разные.
- ключ партиционирования batch_id (все записи грузятся с одним batch_id, но день ото дня он разный)
- загрузили данные в tmp
- 2 операции move partition: старый батч из целевой -> в tmp, и новый из tmp -> в целевую.
- при следующей загрузке - truncate tmp. И алгоритм выше.
Грузим ежедневно 100500 словарей, все автоматизировано, алгоритм одинаковый для всех.

Но один конкретный словарь периодически остаётся пустым.

По приложению, через которое грузим (etl) ошибок нет.
Если тут же повторить загрузку конкретно для этого словаря - данные появляются.
По логам CH: 2 запроса, один insert, второй move. Ошибок нет. Insert успешно, на 824тыс.записей.

Не отрабатывает insert. Move потом успешно перемещает ничего в целевую.
Куда хоть копать?

Единственное, таблицы старые, после их создания меняли маску пути в зукипере на uuid. Пересоздала словарь - не помогло.

движок какой у tmp и в целевой? ReplicatedMergeTree?

да

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

> - загрузили данные в tmp если тут INSERT и tmp Replicated тогда если это теже самые значения. INSERT скипнется.. хотя у вас batch_id меняется... может не меняется? может повторяться среди последних 100 insert?

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

system.part_log смотрели по времени на NewPart ?

посмотрела, все корректно: - 5-9 строки - загрузка, которая вернула пустую таблицу - 1-4 - повтор загрузки, который вернут корректный результат - 8 строка - как раз вставка в tmp, батч 50032 ( = 3 строке из повторной загрузки)

а можно system.query_log query и event_time все таки посмотреть чтобы понять в каком порядке и что именно вы делаете? я правильно понимаю.. вы это запускаете только на одной реплике? или паралельно сразу на нескольких репликах? расшарьте на pastila.nl ?

пара глупых вопросов: нужен "дамп" с таблицы system.query_log, верно? в каком виде и с фильтрацией по интересующим таблицам? что значит "и event_time"? да, выполняем на одной машине, на вторую "реплицируется" через ZK

SELECT query, event_time FROM system.query_log WHERE has(tables,'...') OR has(tables,'...') AND event_date=... AND event_time BETWEN ... почитайте про system.query_log вообще

Maria Besedina
в каком формате нужно выложить на pastila.nl ? что...

select * from system.query_log where (has(tables, 'ims.dic_meg_pos') or has(tables, 'service_part.ims_dic_meg_pos')) and event_date = '2023-10-26' and event_time between '2023-10-26 13:00:00' and '2023-10-26 13:46:00' order by event_time_microseconds desc ;

ну... все верно... катинкой то результат зачем шарить? pastila.nl он для текста... попробуйте использовать clickhouse-client вместо JetBrains это надежнее и информативнее...

глядя на картинку вы паралельно партиции пытаетесь move делать? так?

все последовательно очистили service_part залили в service_part партицию 50032 узнали, какая партиция в ims (49955) переместили ims->service_part партицию 49955 переместили service_part->ims партицию 50032

ну логи показывают что это не так

да, согласна, последние 2 альтера в параллель

Maria Besedina
в каком формате нужно выложить на pastila.nl ? что...

будем общаться картинками, может ощуитте на себе всю боль

да

результат этих операций: 49955 - в service_part и null - в ims

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

ну попробуйте ALTER все таки последовательно сделать ... а не паралельно... если partition by у вас это batch_id то вроде бы должно норм отработать... ну и в логах поискать что там было в /var/log/clickhouse-server/clickhouse-server.log по query_id из system.query_log

спасибо! попробую

у нас уровень лога Warning нужно до debug поднять, верно?

лучше до Trace

спасибо