опасно удалить mutation_xxx.txt файл из директории в таблицы?
лучше KILL MUTATION сделайте
Для этого доступ в клиент нужен, на сколько понимаю, а с этим как раз и проблема
https://clickhouse.com/docs/en/interfaces/http/ send_timeout=3600&receive_timeout=3600 в URL Добавьте
если у вас есть доступ к каталогу /var/lib/clickhouse то у вас есть клиент clickhouse-client отлично работает на сервере и это просто симлинк
Проблема в том, что у меня сервер в контейнере, который по стечению обстоятельств падает при запуске, а падает из-за таблицы, которой нужно откатить измение, чтобы контейнер заработал
контейнер в кубере? или просто docker ? вы мутацию с alter table точно не путаете? есть логи контейнера? или в /var/lib/docker поищите clickhouse-server.err.log на хосте
Проблему удалось решить исправлением кода таблицы в файлах клика. Спасибо за помощь Теперь разбираюсь, почему так произошло. Буду очень благодарен за помощь в поиске ответа на вопрос Как могла произойти ситуация, что при создании таблицы через клиент ошибок не было и таблица функционировала, но после перезагрузки докер контейнера, на котором был сервер, сервер начал перманентно падать из-за ошибки в объявлении таблицы(ошибка связана с недопустимостью использования DateTime64 в качестве версии для ReplacingMT, версия кх 20.4)
какая ошибка при загрузке? какая версия clickhouse-server?
Ошибка https://dpaste.org/L89F Версия 20.4.9.110
DateTime64 совсем недавно разрешили использовать для VER 21.6, 2021-06-05 Enable DateTime64 to be a version column in ReplacingMergeTree. #23992 (kevin wan).
Проблема а том, что до перезагрузки сервера ошибки не было, а таблица фунционировала
вы сделали даунгрейд КХ. Вы создали таблицу в более новой версии, это 1000000% гарантии, я готов сделать ставку на $10000
Как можно это проверить? Где можно найти логи, фиксирующие апгрейд/даунгрейд?
КХ в логах пишет свою версию постоянно, открываете лог до перезагрузки и смотрите
ну я правильно понимаю вы запустили ALTER TABLE ... MODIFY COLUMN registration_time DateTime64(5, 'Europe/Moscow') ? а потом что сделали? контейнер ребутнули? запрос завершился при этом или нет?
Да, только ALTER TABLE ... был успешно(!) выполнен n дней назад. Независимо от этого сегодня был рестартован контейнер с сервером
а в system.query_log этот запрос видно?
в query_log вообще несколько записей полугодичной давности. Видимо, логирование отключено(не ругайте, не я не делал, я лишь разбираюсь) Но то, что запрос был выполнен косвенно подтверждает файл мутации, на сколько понимаю
Номер карты скинуть или почтовым переводом отправите?) Стабильно воспроизводится, если создать ReplacingMT таблицу с версией на поле DateTime, а после сменить тип поля на DateTime64 - ошибки нет, но, если перезагрузить сервер, подняться уже не может
ну таких условий в задаче не было. Можно еще и руками файл подправить. а что можно поменять тип DateTime на DateTime64 и там данные нормальные, это странно ?
Про номер карты, конечно, шутка, но каких условий не было? Да, с данными все в порядке
я в общем представлял себе что был create table ... И такой create table с datetime64 в качестве ver можно сделать совсем недавно, у DateTime64 не было кода который разрешает такой create table, сам replacing работал случайно правильно для DateTime64.
В любом случае, спасибо вам и BloodJazMan за помощь Поимание ситуации многократно облегчило мне жизнь
Обсуждают сегодня