таймзона UTC, я в Москве

он просто вам какбэ намекает что пора уже перебираться в UTC таймозну

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

Добрый день! Возможно на клике построить витрину актуальных данных с помощью вью?

а можете пожалуйста подсказать из-за чего слететь мог автоинкремент (или это риторический вопрос))) ? я не оч понимаю куда копать
data_version в system.parts это и есть префикс файлов .bin ?

если я их удалю (.bin), машина (на которой вызывался инсерт) выйдет из того цикла в котором пытется снова и снова долить данные (сейчас мультиплицирует - уже ~ x10) ?
или надо будет еще что-то подсказать зукиперу?

* благо сырье еще рядом, и долить именно этот шард возможно

Aggregatingmergetree/collapsingmergetree. Мне кажется это надо в первую очередь посмотреть.

обычно чтобы ответить мне нужно читать логи КХ в течении пары часов, потом еще думать часов 6

понял, спасибо, не смею), вы и так изрядно помогли с расследованием
*может подскажете где описана механика асинхронного инсерта? или это в сорсы закапываться и постигать?

при инсерте Distriubted таблица пишет их на диск в .bin файлы, есть шедулер который обходит каталоги и пытается сделать инсерт в шард

а кто-нибудь в курсе, в статистику клика, а именно bytes_read, входит размер словарей?

Привет! Последнее время стал ловить ошибки вида

Received exception from server (version 20.3.5):
Code: 107. DB::Exception: Received from ip:9000. DB::Exception: Cannot open file /var/lib/clickhouse/data/db/table1/202006_1474_1474_0/field.bin, errno: 2, strerror: No such file or directory: While executing MergeTree.

Кто-нибудь знает с чем это может быть связано?
Есть ощущение, что виной всему truncate. Т.к. до него такого замечено не было.
Проявляется по-разному. Делаешь инсерты - норм, делаешь - еще и при селекте падает такая ошибка.
Truncate на такую корапченную таблицу выручает. Но после проблема может снова проявиться, а может и не проявиться

Ошибка валит как на .bin, так и на .mrk

Ничего не переименовывал. Таблица обычная MergeTree на одной ноде

Received exception from server (version 20.3.5):
Code: 107. DB::Exception: Received from ip:9000. DB::Exception: Cannot open file /var/lib/clickhouse/data/db/table1/202006_1474_1474_0/field.bin, errno: 2, strerror: No such file or directory: While executing MergeTree.

а файл такой /var/lib/clickhouse/data/db/table1/202006_1474_1474_0/field.bin есть?

field как в таблице объявлена ? materialized ? default ?

конкретно тот случай уже убрали танкейтом. Но вот свежий
Code: 107, e.displayText() = DB::ErrnoException: Cannot open file /var/lib/clickhouse/data/system/query_log/202006_3245_3245_0/type.bin, errno: 2, strerror: No such file or directory: While executing MergeTree (version 20.3.5.21 (official build))

202006_3245_3245_0 такой папки нет в фс

До этого делал транкейт на эту таблицу и все было норм после него

Друзья, я понимаю что это не зукипер чат, но все таки. Есть кто-то кто использует КХ+Зукипер и мониторит зукипер ОКметром? У них есть такая фича - замерять replication lag (разница между zookeeper.current_transaction_number.follower и zookeeper.current_transaction_number.leader)
Так вот на одном из кластеров он у меня 10-20 сек, при том что есть кластера с лагом стремящимся к 0.
Я обмазался зукиперовской докой и почитал что нашел в доке КХ, и даже поискал по истории этого чата, но так и не нашел ответа на 3 главных вопроса:
1) Как вытащить номер транзакции с ноды зукипера?
2) Какие факторы кроме сетки могут влиять на задержки в репликации?
3) Насколько критично влияние задержки в репликации Зукипер кластера на репликацию КликХауса?

так же не знаю связано или нет, но в логах постоянно

2020.06.08 17:22:04.272711 [ 17814 ] {} <Error> void DB::SystemLog<LogElement>::flushImpl(const std::__1::vector<_Tp>&, uint64_t) [with LogElement = DB::MetricLogElement; uint64_t = long unsigned int]: Code: 252, e.displayText() = DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts., Stack trace (when copying this message, always include the lines below):