Алексей продвигает CH в коридорах pgday #прямосейчас :)

Почему может возникать ошибка DB::Exception: DDL background thread not initialized.. ?

Очевидно, что нет воркера для выполнения DDL ) Собственно вопрос, что я делаю не так? ЗК настроен, репликация работает на всех шардах, все шарды и реплики заведены корректно

Разобрался в чем проблема. В конфиге отсутсовала нужная секция для DDL запросов. Теперь другая приблуда. Например у меня недоступно 4 реплики из кластера, то по идее запрос должен отработать а другие реплики должны подхватить его после того как поднимутся, но запрос зависает и я ловлю ошибку Watching query is executing too long (121 sec.)

а как users.xml перечитать?

Он вроде как автоматически перечитывается

remote_servers, dictionaries и еще какие то блоки автоматом обновляются

Без перезапуска

Всем привет. Написали статью про работу с CH и настройку пайплайна реалтайм обработки данных для Рамблер/топ-100. Буду рад комментам и вопросам – https://habrahabr.ru/company/rambler-co/blog/332202/

почему page_view меняется, дописываете клики? почему время float, почему user_id string? есть ли CH таблица с сессиями, с юзерами? какая топология кластера, какие впечатления у админов? какое отставание от реалтайма?

Кто-то подскажет почему create table on cluster зависает? )

о как я удачно выбрал собрать 54245-ый билд )

если у меня в тестовой таблице 46158 записей, то uniq() же является точным? данные вставляются одной пачкой. flaky тесты, могут падать на off by one error

а напомните, кому жаловаться про несобирающийся на макоси кликхаус?

?

а все, вспомнил )

на ипв6 жалуется из докера?)

знакомо, ребилд тоже не помог под 0.0.0.0 или ::

на ипв6 жалуется из докера?)

я нативный КХ собираю под макось, чтоб ради экспериментов не ходить на виртуалку

и у меня инклюд не находит

под линуксом при этом все собралось и отлично обновилось

аналогично, он и не под всякой осью заводится. Вот пот ubuntu17 на libc6 жалуется, насколько я помню. шаманить надо

аналогично, он и не под всякой осью заводится. Вот пот ubuntu17 на libc6 жалуется, насколько я помню. шаманить надо

ну у меня на серверах 7-ая центось

а вот на рабочей железке - osx

Запустил бы на серваке и тестил без головняка

аналогично, он и не под всякой осью заводится. Вот пот ubuntu17 на libc6 жалуется, насколько я помню. шаманить надо

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

Запустил бы на серваке и тестил без головняка

я имею привычку ехать в поезде и колупать проекты

запуск на серваке сломает ее

я имею привычку ехать в поезде и колупать проекты

Докер?

Докер?

нет, нативно собираю )

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

Но это совсем не виртуалка

Если мы говорим про ограничение в ресурсах - то большого оверхеда для экспериментов не будет. В отличии от полноценной виртуализации.

Но это совсем не виртуалка

ну это совсем виртуалка если на макоси

проще докер

оно делает по факту виртуалку через hypervisor framework

и быстрее

ставит там какой-то мелкий линукс

и гоняет там все

проще докер

проще, но ресурсов кот наплакал )

Вы правы

было б можно - я б уже давно так сделал

А в чем проблема с КХ на маке?

А в чем проблема с КХ на маке?

ну 45ый не собирается )

последний что я собирал был 36-ой

хочу обновиться

у меня почему-то -I один из нужных не прописывается для apple_rt

https://github.com/hatarist/homebrew-clickhouse ?

https://github.com/hatarist/homebrew-clickhouse ?

не, у меня свое :(

ибо не через хоумбрю собираю

впрочем сути не поменяет

ну так это то собирается

ну так это то собирается

вот прям 45ый последний?

там в формуле вообще 198-ой

ну devel 1.1.54214

ну devel 1.1.54214

ну так у меня сейчас есть рабочий 1.1.54236

а я собираю 1.1.54245

последний стейбл

А, ну я хз. У меня какая то версия не собиралась, я issue создал, товарищ через пару часов поправил

И все же, кто что знает по поводу такиз ошибок - 2017.07.04 12:40:00.854739 [ 2149477 ] <Warning> statistics_939.track_sharded (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20170704_20170704_68927_68927_0 from ZooKeeper: no node 2017.07.04 12:40:00.862021 [ 2149477 ] <Warning> statistics_939.track_sharded (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20170704_20170704_68925_68925_0 from ZooKeeper: no node 2017.07.04 12:40:00.865726 [ 2149477 ] <Warning> statistics_939.track_sharded (StorageReplicatedMergeTree, CleanupThread): Couldn't remove 20170704_20170704_68923_68923_0 from ZooKeeper: no node 2017.07.04 12:40:01.200600 [ 1651 ] <Error> track.Distributed.DirectoryMonitor: Code: 210, e.displayText() = DB::NetException: I/O error: Broken pipe: while reading from socket (172.33.90.30:9000), e.what() = DB::NetException, Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x2969826] 1. clickhouse-server(DB::WriteBufferFromPocoSocket::nextImpl()+0x5ad) [0x297de7d] 2. clickhouse-server(DB::Connection::sendData(DB::Block const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0xe5) [0x2b6f365] 3. clickhouse-server(DB::Connection::sendQuery(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long, DB::Settings const*, DB::ClientInfo const*, bool)+0xc35) [0x2b709b5] 4. clickhouse-server(DB::RemoteBlockOutputStream::writePrefix()+0x6a) [0x2c25eda] 5. clickhouse-server(DB::StorageDistributedDirectoryMonitor::processFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0x6f9) [0x2aa4cf9] 6. clickhouse-server(DB::StorageDistributedDirectoryMonitor::findFiles()+0x14c) [0x2aa680c] 7. clickhouse-server(DB::StorageDistributedDirectoryMonitor::run()+0xc5) [0x2aa6d05] 8. clickhouse-server() [0x36744ef] 9. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f03a5da46ba] 10. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f03a53c53dd] 2017.07.04 12:40:02.187307 [ 2149362 ] <Error> statistics_44.track_sharded (Merger): Part 20170531_20170531_3696841_3710521_192 intersects previous part 20170530_20170531_3539831_3697925_986 В какую сторону смотреть и как можно избавиться от этого ада?)

Я что-то подобное сегодня ловил

Не резолвились хосты с кх

Кх или зк берет именно хостнейм кх и по нему пытается стучаться, а не через ip )

У меня такое было

У нас везде хосты прописаны :( кажись в чем=то другом.

У меня магия с DDL ( Не работает ( Запрос зависает и все. Кто-то уже им пользовался?

А где можно почитать про ddl ?

А где можно почитать про ddl ?

В документации

Сейчас дам ссылку

https://clickhouse.yandex/docs/ru/query_language/queries.html#ddl-on-cluster

Thx

На 1.1.54245 и 1.1.54246 не взлетает :( Запросы тупо виснут и по таймауту в 120 секунд отваливаются

CREATE TABLE ttt ON CLUSTER statements ( EventDate Date, UserID UInt32, CounterID UInt32, EventTime DateTime ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/statements', '{replica}', EventDate, (CounterID, EventDate, intHash32(UserID)), 8192) Received exception from server: Code: 159. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Watching query is executing too long (121 sec.). Вот такая беда вобщем. В конфигах секция для ddl есть на всех серверах

Я надеюсь, что <distributed_ddl> включен в конфиге на всех серверах?

Да

Сейчас еще раз проверю

Да, на всех серверах в конфиге есть <distributed_ddl> <path>/clickhouse/task_queue/ddl</path> </distributed_ddl>

При этом репликация работает

Посмотрим.

Спасибо!

Вопрос: а какая задержка между insert в таблицу и через сколько можно оттуда их получить по select? Понятно что железо разное бывает.

Если вставлять не в Distributed таблицу, а напрямую, то никакой задержки нет.

Если вставлять не в Distributed таблицу, а напрямую, то никакой задержки нет.

Извиняюсь, не очень понятно. Они же должны как минимум в дисковый буфер улететь и потом прочитаться?

Когда клиент получил ответ на INSERT запрос, данные записаны в таблицу.

Ок, наверное мне стоило спросить что происходит между insert и ответом на него :)

А в это время данные записываются в таблицу :) Если более конкретно - данные записываются в файловую систему одной реплики (по-умолчанию). Если включить insert_quorum, то ждём подтверждения от нескольких реплик.

А когда компрессия происходит? При слиянии или сразу?

А когда компрессия происходит? При слиянии или сразу?

Сразу если вставленный кусок достаточно большой

На 1.1.54245 и 1.1.54246 не взлетает :( Запросы тупо виснут и по таймауту в 120 секунд отваливаются

А у вас как машинки кластера в конфигах прописаны? И какой у этих машинок hostname ?

Сейчас скину

<remote_servers> <statements> <shard> <weight>1</weight> <internal_replication>true</internal_replication> <replica> <host>10.20.116.11</host> <port>9000</port> </replica> <replica> <host>10.20.117.9</host> <port>9000</port> </replica> </shard> <shard> <weight>1</weight> <internal_replication>true</internal_replication> <replica> <host>10.20.116.12</host> <port>9000</port> </replica> <replica> <host>10.20.117.10</host> <port>9000</port> </replica> </shard> <shard> <weight>1</weight> <internal_replication>true</internal_replication> <replica> <host>10.20.118.8</host> <port>9000</port> </replica> <replica> <host>10.20.119.4</host> <port>9000</port> </replica> </shard> <shard> <weight>1</weight> <internal_replication>true</internal_replication> <replica> <host>10.20.118.7</host> <port>9000</port> </replica> <replica> <host>10.20.119.5</host> <port>9000</port> </replica> </shard> </statements> </remote_servers>

Скорее всего проблема в том, что машинка не понимает что это именно ей запрос прилетел

хосты типа clickhouse-s0r0 где s0 = shard 0, r0 = replica 0

Как сделать? Прописать хостнеймы в remote_servers?

Да, <host>clickhouse-s0r0</host>. Должно заработать

Ок, сейчас попробую и отпишусь

Надо будет в следующей версии дополнительно еще по IP машинки проверять