На 1.1.54242 установка соединения из JDBC падает в момент запроса таймзоны ("select timezone()") с эксепшном ClickHouse exception, code: 27, host: 192.168.11.11, port: 8123; Code: 27, e.displayText() = DB::Exception: Cannot parse input: expected eof before: false Если в пропертях запрещаю использовать таймзону сервера (то есть запрещаю ее селектить при коннекте) — соедениние устанавливается, но падает с той же самой ошибкой на любом другом запросе.

господа, ситуация с пакетами под rpm в том же виде ? использовать стороннюю сборку да ?

zigmund@bug:~> docker run -it --entrypoint /bin/bash yandex/clickhouse-server:1.1.54242 clickhouse@c3b822d9be68:/$ dpkg -l | grep click ii clickhouse-server-base 1.1.54236 amd64 Server binary for clickhouse ii clickhouse-server-common 1.1.54236 amd64 clickhouse-server-common

тег 1.1.54242, а внутри версия 1.1.54236

скажите пожалуйста а можно ли удалить кусок таблицы не за месяц а за день ?

кусок данных за день. тип таблицы mergeTree

партизиции я так понимаю по месяцам. а можно ли по дню? удалить день

партизиции я так понимаю по месяцам. а можно ли по дню? удалить день

партиции по месяцам. Можно бекапнуть месяц в соседнюю страницу без нужных записей. Удалить партицию. Залить обратно чистый месяц)

партиции по месяцам. Можно бекапнуть месяц в соседнюю страницу без нужных записей. Удалить партицию. Залить обратно чистый месяц)

а день?

а день?

Ну как известно, пока нет удаления и партиционирование пока только по месяцам.

Решение для этой проблемы - каждый день писать в новую таблицу

Читать через мердж

насколько это медленнее чем чтение из одной таблицы не замеряли?

подскажите плиз, кто нибудь сталкивался с рандомным появлением следующей ошибки 2017.06.27 17:16:42.269353 [ 5 ] <Error> HTTPHandler: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x29f82a6] 1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x22) [0x1092382] 2. clickhouse-server(DB::ReadBuffer::readStrict(char*, unsigned long)+0x136) [0x1dfcc56]

вставляю массово данные в таблицу при помощи rowbinary инструкций jdbc интерфейса, вне зависимости от набора колонок рано или поздно вылетает ошибка выше

насколько это медленнее чем чтение из одной таблицы не замеряли?

Мы замеряли. На запросах по одному дню, бывало до 10 раз медленнее.

RowBinary в jdbc возможно будет исправлено в ближайшем релизе - там были некоторые изменения (без точного кейса сказать сложно). Также будет исправлена работа с новой версией сервера.

то есть вот этот фейл с Cannot read all data похож на плохую имплементацию rowbinary ?

да новая версия то фиг с ним, там все понятно, видимо чуть поменялся протокол поэтому не работает, если копаться то заработает

а тут какая то магия рандомная, непонятно куда копать :) то ли это плохая имплементация на клиенте, то ли баг на сервере, то ли плохие настройки. Фейлится даже если писать только fixed size типы (просто чуть дольше работает, успевает вставить 20 млн строк)

Как реагировать на такое сообщение: <Error> ZooKeeper: There are 10000 active watches. There must be a leak somewhere.

Без данных которые должны были записаться и записались, сказать сложно. Были некоторые изменения записи в RowBinary в jdbc, возможно там была исправлена ошибка, это один из вариантов, да.

>RowBinary в jdbc возможно будет исправлено в ближайшем релизе Спасибо. Это про release 0.1.25 который вы только что зарелизили или про следующий? :)

0.1.25, можно попробовать.

Создал issue по pk: https://github.com/yandex/ClickHouse/issues/932

На 1.1.54242 установка соединения из JDBC падает в момент запроса таймзоны ("select timezone()") с эксепшном ClickHouse exception, code: 27, host: 192.168.11.11, port: 8123; Code: 27, e.displayText() = DB::Exception: Cannot parse input: expected eof before: false Если в пропертях запрещаю использовать таймзону сервера (то есть запрещаю ее селектить при коннекте) — соедениние устанавливается, но падает с той же самой ошибкой на любом другом запросе.

Спасибо за репорт

zigmund@bug:~> docker run -it --entrypoint /bin/bash yandex/clickhouse-server:1.1.54242 clickhouse@c3b822d9be68:/$ dpkg -l | grep click ii clickhouse-server-base 1.1.54236 amd64 Server binary for clickhouse ii clickhouse-server-common 1.1.54236 amd64 clickhouse-server-common

И вам спасибо :)

Ну как известно, пока нет удаления и партиционирование пока только по месяцам.

а предполагается в будущем удаление?

а предполагается в будущем удаление?

да

ура

может еще update будет?))

может еще update будет?))

а роадмепе есть начальная поддержка update и delete

а роадмепе есть начальная поддержка update и delete

что такое роадмап ?

что такое роадмап ?

"план разработки" в моем вольном переводе :D

"план разработки" в моем вольном переводе :D

это какая-то тестовая ветка ? или это просто планы?

дорожная карта

я знаю как переводится)

https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D0%B4%D0%BE%D1%80%D0%BE%D0%B6%D0%BD%D0%B0%D1%8F_%D0%BA%D0%B0%D1%80%D1%82%D0%B0

это какая-то тестовая ветка ? или это просто планы?

не просто, а ПЛАНЫ )

https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D0%B4%D0%BE%D1%80%D0%BE%D0%B6%D0%BD%D0%B0%D1%8F_%D0%BA%D0%B0%D1%80%D1%82%D0%B0

глуши троллейбус :))))

ахаха)) +1

спасибо будем ждать

а там есть null ?

ну мне казалось в русском уже давно устоялось не только в плане физического листа бумаги

может еще null будет ?

а того который есть мало?

а мы не обновлялись. он уже есть?

SELECT NULL ┌─NULL─┐ │ \N │ └──────┘ 1 rows in set. Elapsed: 0.001 sec.

а мы не обновлялись. он уже есть?

есть ограниченная поддержка)

Создал issue по pk: https://github.com/yandex/ClickHouse/issues/932

Похоже дубликат

огось. спасибо. страшно обновляться правда

Похоже дубликат

Да, это регулярно всплывает. Поправить в текущей архитектуре трудно.

Но рано или поздно мы поправим :)

огось. спасибо. страшно обновляться правда

нужно чаще обновляться)) Но прямо сейчас не надо, ибо там есть неприятная бага с broken pipe и distributed таблицами

нужно чаще обновляться)) Но прямо сейчас не надо, ибо там есть неприятная бага с broken pipe и distributed таблицами

?

Да, это регулярно всплывает. Поправить в текущей архитектуре трудно.

Не понимаю почему ему вообще приходит в голову не использовать pk в любой конструкции pk in (...)

И ещё вопрос: а что-то типа макросов планируется? а то больно громоздкий синтаксис.

макросов которые делают что?

Например #define getName(id) dictGetString('dict', 'name', id). Ну и ещё много чего . Проблемы конечно тоже понятны.

Например #define getName(id) dictGetString('dict', 'name', id). Ну и ещё много чего . Проблемы конечно тоже понятны.

плюсую, очень хочется о, в чате 777 человек :)

я как-то написал расширение sql CH присваниваниями и шаблонами, но это внешний синтаксический сахар и пока что-то не никто не торопится реализовать тоже самое в коробке.

#define normArrStr(arr) arrayJoin(arrayMap(x->cityHash64(x), arr))

а так понятно что надо, запросы на сотни строк читать невозможно.

А какая политика - все же реализовать стандарт sql или все же иметь свой удобный sql?

Просто если второе, то макросы второстепенны. Но вроде озвучивали первое.

Неожиданно: на холодную КХ сильно от кбд отстаёт с диска: 1236мс против 74мс.

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

Неожиданно: на холодную КХ сильно от кбд отстаёт с диска: 1236мс против 74мс.

Проблема решена - это прогрузка словаря была. КХ побеждает опять.

Раньше задавали вопрос по поводу ошибки в логах: "StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20170628_20170628_3050_3050_0 from ZooKeeper: no node" Но не нашел ответа. Нужно как-то реагировать на эти ошибки?

Завтра в Минске митап, запись видео будет?

Завтра в Минске митап, запись видео будет?

вроде уже говорили неделю назад, что нет

подскажите пожалуйста, в MergeTree колонка типа Date итак используется в качестве индекса ведь, ее не обязательно добавлять в PK?

ну да, а зачем. По date идет партиционирование

вчера репортил баги по jdbc 0.1.24 (rowbinary эпизодически терял соединение, к базе версии 1.1.54242 подключиться вообще не мог) — в версии jdbc 0.1.25 все работает идеально, большое спасибо команде Яндекса за фиксы.

Кто знает, как включить вертикальный мердж? На каком-то митапе говорили что тестируется более продвинутая версия фонового слияния. В документации нет про это. Полазив по коду, нашёл такое <merge_tree> <enable_vertical_merge_algorithm>1</enable_vertical_merge_algorithm> <vertical_merge_algorithm_min_rows_to_activate>8192</vertical_merge_algorithm_min_rows_to_activate> <vertical_merge_algorithm_min_columns_to_activate>11</vertical_merge_algorithm_min_columns_to_activate> </merge_tree> Но что-то непохоже что оно что-то включает или вообще работет.

Включено по-умолчанию несколько месяцев назад.

Добрый день, иногда падает база. В логах только вот это: 2017.06.28 10:18:09.839015 [ 7419 ] <Warning> TCPHandler: Client has not sent any data. 2017.06.28 10:20:09.851981 [ 7417 ] <Warning> TCPHandler: Client has not sent any data. 2017.06.28 10:20:16.962984 [ 7420 ] <Error> BaseDaemon: (from thread 7410) Terminate called without an active exception 2017.06.28 10:20:16.963002 [ 7420 ] <Error> BaseDaemon: ######################################## 2017.06.28 10:20:16.963017 [ 7420 ] <Error> BaseDaemon: (from thread 7410) Received signal Aborted (6). 2017.06.28 10:20:16.965259 [ 7420 ] <Error> BaseDaemon: 1. /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38) [0x7fbfd6d0c428] 2017.06.28 10:20:16.965282 [ 7420 ] <Error> BaseDaemon: 2. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0xa5) [0x34b2e45] 2017.06.28 10:20:16.965290 [ 7420 ] <Error> BaseDaemon: 3. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7fbfd77bc6ba] 2017.06.28 10:20:16.965297 [ 7420 ] <Error> BaseDaemon: 4. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fbfd6ddd82d] Можете подсказать с чем может быть это связано? Особой нагрузки нет. Версия сервера - 1.1.54236

Падения не на одном сервере, а бывают на совсем разных и в случайное время

Попробуйте обновить до 1.1.54242 и проверить ещё раз. Если будет другой стек трейс, то пришлите его.

Хорошо. Но всегда вот такой похожий. Включим query_log, может дело в специфическом запросе-убийце

Скажите пожалуйста кх в спящем режиме (без нагрузки) делает какие-то операции?? агрегации сортировки?

делает мердж партиций

делает мердж партиций

это может вызывать нагрузку ?

вполне

это может вызывать нагрузку ?

посмотрите в system.merges.

посмотрите в system.merges.

а куда смотреть?

SELECT * FROM system.merges

https://clickhouse.yandex/docs/ru/system_tables/system.merges.html

https://clickhouse.yandex/docs/ru/system_tables/system.merges.html

сенк!!

А можно вопрос о будущей реализации вставки в словари - как это будет осуществляться? Функция или может специальный тип у колонки?

Вставки в словари не будет. Таблицы на базе словарей будут доступны только на чтение.

подскажите, пжл, что с этим можно сделать? ошибка валится каждые 20 сек 2017.06.28 15:44:11.287728 [ 28 ] <Error> void DB::BackgroundProcessingPool::threadFunction(): Code: 173, e.displayText() = DB::Exception: Allocator: Cannot mmap., errno: 12, strerror: Cannot allocate memory: (while reading column oc39): (while reading from part /local/clickhouse//data/db/logs_local/20170205_20170205_301560_301572_1/ from mark 7 to 8): Cannot fetch required block. Stream MergeTree(/local/clickhouse//data/db/logs_local/20170205_20170205_301560_301572_1/, columns, oc39, marks, 0, 132), part 5, e.what() = DB::Exception, Stack trace: ошибка одна и та же именно эта, с куском 20170205_20170205_301560_301572_1. Есть вариант перелить партицию 201702 в новую таблицу, дропнуть партицию в исходной, залить заново из новой. Смущают миллиарды записей в этой партиции, хотелось бы без этого обойтись. 1.1.54236

Оператива на сервере не кончилась?