ФС была проверена, там ошибок нет, но вот целостность данных кликхауса, судя по всему, нарушилась.
После перезапуска в error-лог летит нечто такое:
{} <Error> Application: DB::Exception: Part 20211123_414_484_16 already exists: Cannot attach table `stats578`.`events11692` from metadata file /var/lib/clickhouse/store/155/1556174f-ea46-49f0-8152-6c693fd3f39e/events11692.sql from query ATTACH TABLE <...> ENGINE = MergeTree PARTITION BY toYYYYMMDD(time) ORDER BY date TTL date TO VOLUME 'hot', date + toIntervalDay(7) TO VOLUME 'cold' SETTINGS index_granularity = 8192, storage_policy = 'moving_from_ssd_to_hdd': while loading database `stats578` from path /var/lib/clickhouse/metadata/stats578
В гугле пока ничего конкретно на этот случай не нашёл, потому и дошёл сюда.
Основной вопрос: раз оно "already exists", то возможно, эти .sql файлы с ATTACH TABLE можно удалять?
Буду благодарен любым материалам/ссылкам/наводкам.
attach table `stats578`.events11692 -- пытается включить таблицу. Если вы удалите .sql , то таблицы events11692 не будет. Part already exists ... похоже что у вас 20211123_414_484_16 есть на двух дисках ssd и hdd каким образом это получилось надо читать в логе КХ я бы грепал лог по 20211123_414_484_16 и пытался понять что пошло не так и как это починить
Спасибо за ответ. В логах, увы, упомянутые вами части сообщения не встречаются нигде, кроме как в сегодняшних ошибках. Да и, полагаю, вопрос "что пошло не так" в моём случае не совсем актуален - нода ушла в ребут как раз в момент, когда кликхаус инициализировался после плановой (нормальной) перезагрузки. Там точно много чего наверняка пошло "не так" :) Для меня вопрос, скорее, обстоит в том, как эту ноду вернуть к жизни с минимально возможными потерями для данных.
пощите каталог 20211123_414_484_16 на обоих дисках, посмотрите что внутри, уберите в сторону например тот который на hdd
Попробую. Ещё раз спасибо 🤝
Посмотрел - там действительно были дубли подобных директорий (по имени part, как я понимаю). Выборочно проверил множество таких "дублей" - содержимое (список+хеши) совпадало и в slow, и в fast. Прикинул, что действительно больше смысла удалять это со стороны slow - и, в итоге, решил мини-циклом в баше. #!/usr/bin/bash DIR_DATA_FAST="/path/to/data/fast/dir" DIR_DATA_SLOW="/path/to/data/slow/dir" for partname in $(find "${DIR_DATA_FAST}/store" -maxdepth 3 -mindepth 3 -type d -name '202111*' -printf "%P\n") do if [ -d "${DIR_DATA_SLOW}/store/${partname}" ] then echo "DIR ${DIR_DATA_SLOW}/store/${partname} exists !!! removing" rm -rf "${DIR_DATA_SLOW}/store/${partname}" fi done Не уверен, сколько я в итоге мог потерять данных - хочется верить, что цифра таки стремится к нулю) По крайней мере, сервис теперь инициализируется и не спотыкается. Огромное спасибо, что подсказали, как оно работает и в какую сторону смотреть.
какая версия КХ у вас?
21.3.12.2
Обсуждают сегодня