Есть таблица MergeTree. В неё каждый час загружается текущее состояние данных из mysql - таблица выгружается полностью, так как по ней в мускуле идёт большое количество апдейтов.
Чтобы для пользователей кликхауса таблица не моргала, скрипт перегрузки данных делает вот так:
1) Данные из TSV грузит в {table}_new;
2) Как только данные влились, делает рокировку: RENAME TABLE {table} TO {table}_old, {table}_new TO {table};
3) DROP TABLE {table}_old;
Проблема в том, что по факту в 2/3 случаев получается очень плохо:
- целевая таблица мигает - исчезает на сотни секунд;
- иногда вообще валится ошибка WRITE locking attempt on "{table}_new" has timed out! (120000ms) Possible deadlock avoided. Client should retry. IN:RENAME TABLE {table} TO {table}_old, {table}_new TO {table}
Увеление lock_acquire_timeout ни к чему не привело - в большей части случаев RENAME всё равно не успевает выполниться, плюс целевая таблица оказывается невидна на время куполнения RENAME.
Судя по system.query_log у нас нет запросов, которые выполнялись бы более 30 секунд.
Сама по себе таблица, на которой происходит проблема - небольшая, буквально 20ГБ в Clickhouse.
Собственно вопросы:
1) Что можно еще попробовать, чтобы решить проблемы с а) видимостью таблицы во время RENAME б) больщим временем выполнения RENAME?
2) Возможно, схема с RENAME TABLE вообще не рабочая, и не надо пытаться сейчас реашать проблему из предыдущего пункта, а есть работающие устоявшиеся практики для полной перегрузки таблиц?
попробуйте alter table ... replace partition ... from ... https://gist.github.com/den-crane/521975b5333c5dc7059bed4030f62f94 до 19.14 rename был атомарный (с global lock) и ваша схема работала, но иногда это приводило к дедлоку с зависанием КХ, сейчас пилится Engine=Atomic, но видимо еще не готов.
я кстати перепутал, надо для atomic использовать EXCHANGE TABLES atom.X1 AND atom.X2; https://gist.github.com/den-crane/521975b5333c5dc7059bed4030f62f94#file-rename_atomic-txt-L70
Обсуждают сегодня