Пытаюсь подключить grafana к Clickhouse, подключение на Self signed ключах

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

Утро доброе. Подскажите пожалуйста, настроил репликацию (в Zookeeper кластере две ноды), тестирую разные сценарии. В первом варианте если создать таблицы на обеих нодах и далее их заполнять, то никаких проблем не возникает. Но если сначала создать таблицу на одной ноде (в частности на лидере) записать в нее некоторое кол-во данных, далее создать таблицу на второй ноде, то в дальнейшем если необходимо выполнить "OPTIMIZE TABLE" получаю ошибку: Code: 192, e.displayText() = DB::Exception: Received from host2:9000, xx.xx.xx.xx. DB::Exception: Unknown user default., e.what() = DB::Exception При этом - этот же запрос на лидере отрабатывает без проблем. В чем может быть причина?

Утро доброе. Подскажите пожалуйста, настроил репликацию (в Zookeeper кластере две ноды), тестирую разные сценарии. В первом варианте если создать таблицы на обеих нодах и далее их заполнять, то никаких проблем не возникает. Но если сначала создать таблицу на одной ноде (в частности на лидере) записать в нее некоторое кол-во данных, далее создать таблицу на второй ноде, то в дальнейшем если необходимо выполнить "OPTIMIZE TABLE" получаю ошибку: Code: 192, e.displayText() = DB::Exception: Received from host2:9000, xx.xx.xx.xx. DB::Exception: Unknown user default., e.what() = DB::Exception При этом - этот же запрос на лидере отрабатывает без проблем. В чем может быть причина?

Это вроде как фиксили. А какая версия?

Это вроде как фиксили. А какая версия?

18.13.0

Добрый день, та же проблема но с drop partition. 18.12.14. Это еще актуально ? https://github.com/yandex/ClickHouse/issues/1861

18.13.0

А к локальной (не лидер) реплике вы подключаетесь с пользователем/паролем?

Он вроде как должен форвардовать кредитеншалсы.

На лидера.

Да, и в настройках репликации тоже указан юзер. Но использует почему-то defaul

А к локальной (не лидер) реплике вы подключаетесь с пользователем/паролем?

Если вы имеете виду реплику на которой я выполняю "OPTIMIZE TABLE" то да, я к ней подключаюсь с пользователем и паролем

Уточню: при этом например такие запросы: INSERT, ALTER ADD/DROP COLUMN выполняются также без каких либо ошибок. Ну и с DROP PARTITION та же беда, что и у коллеги выше.

да

привет коллеги, тут же наверняка есть люди из кликхауса и/или из метрики, я работаю в стране где где яндекс не представлен почти никак, но внезапно я тут нескольким клиентам попиарил и то и то и они начали юзать; в общем я думал может яндексу интересно было бы выйти на новый рынок, напишите в лс если чо

Уточню: при этом например такие запросы: INSERT, ALTER ADD/DROP COLUMN выполняются также без каких либо ошибок. Ну и с DROP PARTITION та же беда, что и у коллеги выше.

Тут PR который (теоретически) должен был пофиксить эту проблему. https://github.com/yandex/ClickHouse/pull/2202

он от Apr 16, он или не помог или бага в другом месте

Тут PR который (теоретически) должен был пофиксить эту проблему. https://github.com/yandex/ClickHouse/pull/2202

Жаль что "теоретически"

а почему кликхаус перемерживает все парты при мутациях удаления части данных? есть таблица в ней лежит месяц, я удаляю за полмесяца данные вот таким запросом ALTER TABLE tablename DELETE WHERE Date < today()-15; парты разбиты дефолтно по дате

мне казалось он должен был мутировать только парты где дата старее 15, а судя по папкам куда идут мержи и увеличению в размере два раза папки с таблицей он перемержил вообще все и это как то не айс совсем

мне казалось он должен был мутировать только парты где дата старее 15, а судя по папкам куда идут мержи и увеличению в размере два раза папки с таблицей он перемержил вообще все и это как то не айс совсем

какая версия ClickHouse?

18.12.17 на днях обновился

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

18.12.17 на днях обновился

странно, этой оптимизации в первых релизах ALTER DELETE и правда не было, но позже появилась @ztlpn

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

вообще эта проблема была основной что меня сдерживало от апдейта и внедрения удаления через такой запрос

добрый день, уважаемые

кто-то настраивал внешний словарь с apache ignite?

драйвер собрал, в odbc прописан, выдает ошибку ClickHouse exception, code: 86, host: clickhouse1, port: 8123; Code: 86, e.displayText() = DB::Exception: Received error from remote server /columns_info?connection_string=DSN%3DDATA1_PS&table=PACK_STATISTICS. HTTP status code: 500 Internal Server Error, body: Error getting columns from ODBC 'Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = ODBC handle exception: Failed to set automatic commit.: Connection:Not applicable Server:Not applicable =========================== ODBC Diagnostic record #1: =========================== SQLSTATE = HYC00 Native Error Code = 0 Specified attribute is not supported. , e.what() = ODBC handle exception' , e.what() = DB::Exception

драйвер собрал, в odbc прописан, выдает ошибку ClickHouse exception, code: 86, host: clickhouse1, port: 8123; Code: 86, e.displayText() = DB::Exception: Received error from remote server /columns_info?connection_string=DSN%3DDATA1_PS&table=PACK_STATISTICS. HTTP status code: 500 Internal Server Error, body: Error getting columns from ODBC 'Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = ODBC handle exception: Failed to set automatic commit.: Connection:Not applicable Server:Not applicable =========================== ODBC Diagnostic record #1: =========================== SQLSTATE = HYC00 Native Error Code = 0 Specified attribute is not supported. , e.what() = ODBC handle exception' , e.what() = DB::Exception

Тут заковыка в самой реализации odbc.

Тут заковыка в самой реализации odbc.

можно подробней?

привет коллеги, тут же наверняка есть люди из кликхауса и/или из метрики, я работаю в стране где где яндекс не представлен почти никак, но внезапно я тут нескольким клиентам попиарил и то и то и они начали юзать; в общем я думал может яндексу интересно было бы выйти на новый рынок, напишите в лс если чо

Это может быть интересно @alexanderzaitsev

можно подробней?

Работает эта машинерия так - в ODBC-мост (отдельное приложение) приезжает запрос, который должен вывести типы колонок из внешей таблицы. В демон вгружается odbc-драйвер, создаётся коннект чтобы выполнить запрос select * from table where 1 = 0. Чтобы после запроса не было "висящей" тразнакции, там делается autocommit=true. Похоже, что odbc-драйвер от игнита не поддерживает эту функциональность.

Работает эта машинерия так - в ODBC-мост (отдельное приложение) приезжает запрос, который должен вывести типы колонок из внешей таблицы. В демон вгружается odbc-драйвер, создаётся коннект чтобы выполнить запрос select * from table where 1 = 0. Чтобы после запроса не было "висящей" тразнакции, там делается autocommit=true. Похоже, что odbc-драйвер от игнита не поддерживает эту функциональность.

Ошибка летит вот отсюда https://github.com/apache/ignite/blob/fb97066d314943a045cc9bb3270d42aa0304ef16/modules/platforms/cpp/odbc/src/connection.cpp#L535

Подскажите пожалуйста. В CH есть логика автоматического востановления из реплики при checksum mismatch ?

спасибо

Всем привет! У меня не работает создание таблички через CLUSTER ON, отваливается по таймауту Code: 159. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000000016 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 12 unfinished hosts (0 of them are currently active), they are going to execute the query in background. Зукипер и репеликация работают. Порт 9000 и 9009 доступен всем тачкам. Все хосты резолвятся. В system.clusters все тачки есть. При старте нет ниниких ворнингов о ddl. В логах кликхауса только эксепшн: 0. /usr/bin/clickhouse-server(StackTrace::StackTrace()+0x16) [0x56d06c6] 1. /usr/bin/clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x22) [0x2da2d92] 2. /usr/bin/clickhouse-server(DB::DDLQueryStatusInputSream::readImpl()+0x1096) [0x4e450c6] 3. /usr/bin/clickhouse-server(DB::IProfilingBlockInputStream::read()+0x25a) [0x47680ea] 4. /usr/bin/clickhouse-server(DB::AsynchronousBlockInputStream::calculate(MemoryTracker*)+0x5e) [0x2db2f7e] 5. /usr/bin/clickhouse-server(ThreadPool::worker()+0x19e) [0x587246e] 6. /usr/bin/clickhouse-server() [0x930310f] 7. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7faea62876ba] 8. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7faea5ab041d] В логах зукипера вообще ничего не вижу. Куда копать ваще?

Добрый день, вопрос по мерджам в ReplacingMergeTree и OPTIMIZE select name, rows, level from (select partition, name, rows, level, table from system.parts_columns where active=1 and table='tablename' and database='stats') where substring(name, 1, 6) = '201809' group by name, rows, level order by name DESC, level DESC; выдает следующий результат ┌─name────────────────────────────┬──────rows─┬─level─┬ │ 20180924_20180924_13014_13014_0 │ 535278 │ 0 │ │ 20180924_20180924_13013_13013_0 │ 535975 │ 0 │ │ 20180924_20180924_13012_13012_0 │ 535017 │ 0 │ │ 20180924_20180924_13011_13011_0 │ 536776 │ 0 │ │ 20180924_20180924_13005_13010_1 │ 3213635 │ 1 │ │ 20180924_20180924_13004_13004_0 │ 536000 │ 0 │ │ 20180924_20180924_13003_13003_0 │ 536232 │ 0 │ │ 20180924_20180924_13002_13002_0 │ 537835 │ 0 │ │ 20180924_20180924_13001_13001_0 │ 534529 │ 0 │ │ 20180924_20180924_13000_13000_0 │ 536108 │ 0 │ │ 20180924_20180924_12994_12999_1 │ 3213478 │ 1 │ │ 20180924_20180924_12988_12993_1 │ 3214099 │ 1 │ │ 20180901_20180924_0_12987_187 │ 204792586 │ 187 │ └─────────────────────────────────┴───────────┴───────┴ Запустил OPTIMIZE TABLE stats.tablename PARTITION '201809' FINAL; В результате выборка из таблицы system.parts стала такой ┌─name────────────────────────────┬──────rows─┬─level─┐ │ 20180924_20180924_13014_13014_0 │ 535278 │ 0 │ │ 20180924_20180924_13013_13013_0 │ 535975 │ 0 │ │ 20180924_20180924_13012_13012_0 │ 535017 │ 0 │ │ 20180924_20180924_13011_13011_0 │ 536776 │ 0 │ │ 20180924_20180924_13005_13010_1 │ 3213635 │ 1 │ │ 20180901_20180924_0_13004_188 │ 204792692 │ 188 │ └─────────────────────────────────┴───────────┴───────┘ В таблице system.merges процессов не осталось. Вставок в таблицу в момент оптимизации не было. Правильно ли я понимаю, что optimize не гарантирует что все куски будут слиты за один вызов?

Подскажите пожалуйста. В CH есть логика автоматического востановления из реплики при checksum mismatch ?

Часто появляется?

Часто появляется?

Пока один раз вылезло т.к. кластер относительно новый. Но датацентр - hetzner, а это означает что такое будет повторятся ) . Но у меня таблица эта не replicated, поэтому и возник такой вопрос. В cassandra есть похожий механизм.

Пока один раз вылезло т.к. кластер относительно новый. Но датацентр - hetzner, а это означает что такое будет повторятся ) . Но у меня таблица эта не replicated, поэтому и возник такой вопрос. В cassandra есть похожий механизм.

Да, битые куски будут скачены с другой реплики если они там есть

Здрасте. У меня версия сервера 18.6.0 (так говорит select version()`). Однако, не работает `ALTER TABLE ... UPDATE на SummingMergeTree. Говорит, что не знает команды UPDATE он. Code: 62, e.displayText() = DB::Exception: Syntax error: failed at position 51: UPDATE EventTime = toStartOfHour(EventTime) WHERE EventDate = '2018-09-01'. Expected one of: ALTER command, a list of ALTER commands, ON, ADD COLUMN, DROP COLUMN, CLEAR COLUMN, MODIFY COLUMN, MODIFY PRIMARY KEY, ATTACH PARTITION, DETACH PARTITION, DROP PARTITION, ATTACH PART, FETCH PARTITION, FREEZE PARTITION, DELETE WHERE, REPLACE PARTITION, e.what() = DB::Exception

Или я что-то не так делаю. Но версия сервера вроде бы как выше, чем 1.1.54388. Насколько я могу судить, 18 больше, чем 1

подскажите пожалуйста, что у меня не так с запросом?

не репликейтед таблицы не поддерживается, насколько я знаю

Здрасте. У меня версия сервера 18.6.0 (так говорит select version()`). Однако, не работает `ALTER TABLE ... UPDATE на SummingMergeTree. Говорит, что не знает команды UPDATE он. Code: 62, e.displayText() = DB::Exception: Syntax error: failed at position 51: UPDATE EventTime = toStartOfHour(EventTime) WHERE EventDate = '2018-09-01'. Expected one of: ALTER command, a list of ALTER commands, ON, ADD COLUMN, DROP COLUMN, CLEAR COLUMN, MODIFY COLUMN, MODIFY PRIMARY KEY, ATTACH PARTITION, DETACH PARTITION, DROP PARTITION, ATTACH PART, FETCH PARTITION, FREEZE PARTITION, DELETE WHERE, REPLACE PARTITION, e.what() = DB::Exception

ALTER TABLE ... UPDATE появился в 18.12.14: https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#clickhouse-release-181214-2018-09-13

Да, битые куски будут скачены с другой реплики если они там есть

спасибо большое, если будет воспроизводится часто, то переделаю на replicated

Ааа, о как. А в документацяии написано что-то про "Функциональность находится в состоянии beta и доступна начиная с версии 1.1.54388. Реализована поддержка *MergeTree таблиц (с репликацией и без)." Блин, может это про Delete имелось в виду

@blinkovivan спасибо, попробую обновиться

Ааа, о как. А в документацяии написано что-то про "Функциональность находится в состоянии beta и доступна начиная с версии 1.1.54388. Реализована поддержка *MergeTree таблиц (с репликацией и без)." Блин, может это про Delete имелось в виду

это было про ALTER TABLE ... DELETE

ясно, спасибо.

Хм. А он не может апдейтить колонку, которая является частью ключа. Вот же облом.

Зачем я вообще апдейчу: у меня SummingMergeTree. Есть куча метрик, где EventTime - это время кратное пятии миинутам. "пятиминутки". Я захотел обновить EventTime и сделать у них время, равное началу часа. И позволить SummingMergeTree помержить партишены и посумировать числа

т.е. произвести такое "сворачивание" метрик: пятиминутные в часовые.

кто-нибудь может поделиться подобной success story? Ну можно через промежуточную таблицу попробовать это реализовать, конечно: insert into table_temp select ..., toSrartOfHour(EventTime) as EventTime... а потом удалить метрики в основной таблице, а потом обратно перелить через Insert Into ... Select

но это как-то рогато ?

кто-нибудь может поделиться подобной success story? Ну можно через промежуточную таблицу попробовать это реализовать, конечно: insert into table_temp select ..., toSrartOfHour(EventTime) as EventTime... а потом удалить метрики в основной таблице, а потом обратно перелить через Insert Into ... Select

может https://clickhouse.yandex/docs/en/operations/table_engines/graphitemergetree/ подойдет?

кто-нибудь может поделиться подобной success story? Ну можно через промежуточную таблицу попробовать это реализовать, конечно: insert into table_temp select ..., toSrartOfHour(EventTime) as EventTime... а потом удалить метрики в основной таблице, а потом обратно перелить через Insert Into ... Select

Можно через CLEAR COLUMN https://github.com/kshvakov/ClickHouse-CPP-Meetup

@kshvakov о, отличный фокус. Но боюсь, что он сработает только при схлопывании до дня. т.к. EventTime берет дефолтное значение относительно EventDate (т.е. какого-то второго поля, а не самого себя. Вряд ли можно сделать EventTime DEFAULT toStartOfHour(EventTime) )

@kshvakov о, отличный фокус. Но боюсь, что он сработает только при схлопывании до дня. т.к. EventTime берет дефолтное значение относительно EventDate (т.е. какого-то второго поля, а не самого себя. Вряд ли можно сделать EventTime DEFAULT toStartOfHour(EventTime) )

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

Всем привет, столкнулся с неожиданной проблемой, cоздаю View ReplicatedMergeTree, и данные в ней и в таблице не совпадают. Может кто сталкивался? На что обратить внимание?

можно, да. Ввести дополнительное поле EventHour и сделать его значение дефолтным для EventTime. Наверное, нормально даже будет.

точно, спасибо, поиграюсь с CLEAR COLUMN

странно, этой оптимизации в первых релизах ALTER DELETE и правда не было, но позже появилась @ztlpn

@ztlpn почитал код в вашем пр , https://github.com/yandex/ClickHouse/pull/2694/files по логике вроде не должен он перезаписывать парты в которые delete не попал , тем более у меня простой случай удаление данных старше 15 дней.

Всем привет, столкнулся с неожиданной проблемой, cоздаю View ReplicatedMergeTree, и данные в ней и в таблице не совпадают. Может кто сталкивался? На что обратить внимание?

В логи посмотрите

В логи посмотрите

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

А по какой причиине SummingMergeTree после OPTIMIZE ... FINAL может не суммировать некоторые записи, которые вообще-то должен? Есть 6 записей. У них одинаковые пять полей, которые попадают в PK и по которым он делает группировку. Ожидаю, что получу на выходе одну запись. Получаю пять. Он одну суммирует с другой, и при это не выбирает рандомну запись, а вот просто конкретную

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

а они в один partition попадают ?

Хороший вопрос. А по умолчанию как он на партишены разбивает? Я, к сожалению, не указывал при создании таблицы ключевое слово PARTITION BY

я почему-то думал, что он партишионит их по EventDate (который указан первым аргументом в объявлениии движка). Но может быть и нет.

ладно, а если и не попадают, то как быть?

посмотрел в логи. Хм... там фигурируют партишены с именами типа 201809_1_61_13. Видимо, по умолчанию он их делит как-то вот так, с суффиксами какими-то. Ох.

я почему-то думал, что он партишионит их по EventDate (который указан первым аргументом в объявлениии движка). Но может быть и нет.

Ключ партиционирования и первичный ключ - это две разные вещи. По умолчанию, без использования PARTITION BY партиционивание идёт помесяцам. По ним же и OPTIMIZE работает

глянул список всезх партишенов. У меня только один и есть - по имени текущего месяца как и надо "201809".

Tima ну т.е. по месяцам относительно EventDate, верно? Что является первым аргументом при указании движка

да

Да

Нужно больше данных, команда создания таблицы и подобное

ну значит всё в одном партишине по любому.

А сделайте

SELECT uniq(toYYYYMM(EventDate)) FROM ...

Вдруг у вас записались некоторые даты не правильно

ровно 1 штука

так что всё ок

это чисто тестовый сгенерированный набор данных на 2400 позиций.

Добрый день, вопрос по мерджам в ReplacingMergeTree и OPTIMIZE select name, rows, level from (select partition, name, rows, level, table from system.parts_columns where active=1 and table='tablename' and database='stats') where substring(name, 1, 6) = '201809' group by name, rows, level order by name DESC, level DESC; выдает следующий результат ┌─name────────────────────────────┬──────rows─┬─level─┬ │ 20180924_20180924_13014_13014_0 │ 535278 │ 0 │ │ 20180924_20180924_13013_13013_0 │ 535975 │ 0 │ │ 20180924_20180924_13012_13012_0 │ 535017 │ 0 │ │ 20180924_20180924_13011_13011_0 │ 536776 │ 0 │ │ 20180924_20180924_13005_13010_1 │ 3213635 │ 1 │ │ 20180924_20180924_13004_13004_0 │ 536000 │ 0 │ │ 20180924_20180924_13003_13003_0 │ 536232 │ 0 │ │ 20180924_20180924_13002_13002_0 │ 537835 │ 0 │ │ 20180924_20180924_13001_13001_0 │ 534529 │ 0 │ │ 20180924_20180924_13000_13000_0 │ 536108 │ 0 │ │ 20180924_20180924_12994_12999_1 │ 3213478 │ 1 │ │ 20180924_20180924_12988_12993_1 │ 3214099 │ 1 │ │ 20180901_20180924_0_12987_187 │ 204792586 │ 187 │ └─────────────────────────────────┴───────────┴───────┴ Запустил OPTIMIZE TABLE stats.tablename PARTITION '201809' FINAL; В результате выборка из таблицы system.parts стала такой ┌─name────────────────────────────┬──────rows─┬─level─┐ │ 20180924_20180924_13014_13014_0 │ 535278 │ 0 │ │ 20180924_20180924_13013_13013_0 │ 535975 │ 0 │ │ 20180924_20180924_13012_13012_0 │ 535017 │ 0 │ │ 20180924_20180924_13011_13011_0 │ 536776 │ 0 │ │ 20180924_20180924_13005_13010_1 │ 3213635 │ 1 │ │ 20180901_20180924_0_13004_188 │ 204792692 │ 188 │ └─────────────────────────────────┴───────────┴───────┘ В таблице system.merges процессов не осталось. Вставок в таблицу в момент оптимизации не было. Правильно ли я понимаю, что optimize не гарантирует что все куски будут слиты за один вызов?

optimize насколько быстро отработал? Вы возможно ошиблись в имени партиции, как партиционировано у вас? сколько времени работает без кавычек OPTIMIZE TABLE stats.tablename PARTITION 201809 FINAL;

optimize насколько быстро отработал? Вы возможно ошиблись в имени партиции, как партиционировано у вас? сколько времени работает без кавычек OPTIMIZE TABLE stats.tablename PARTITION 201809 FINAL;

Стандартное помесячное. Минуты 3-5. Повторый запуск этой же команды добил оставшиеся куски

Стандартное помесячное. Минуты 3-5. Повторый запуск этой же команды добил оставшиеся куски

ну тогда это куски которые были вставлены за время работы optimize

мне казалось он должен был мутировать только парты где дата старее 15, а судя по папкам куда идут мержи и увеличению в размере два раза папки с таблицей он перемержил вообще все и это как то не айс совсем

https://github.com/yandex/ClickHouse/pull/2694 The parts that are not touched are copied using localBackup() and not simply renamed to avoid difficulties when status of the part commit operation in ZooKeeper is unknown. т.е. насколько я понимаю парты которые не должны изменятся мутацией, хардлинками копируются / переименовываются.

То есть он их копирует все таки? И размер таблицы в два раза растет при этом?

То есть он их копирует все таки? И размер таблицы в два раза растет при этом?

как таблицы, вы про файлы на диске?, как размер счиаете?