) следовало немного дальше прочесть

Нет там точно был вариант без зукипера в доке он точно был интернал репликейшен или типо того

сразу же написал про эту опцию ))

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

) следовало немного дальше прочесть

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

их всего времени что я потратил на изучение кх где то один процент я потратил на зукипер

java фобия

хотя java мне и самому не по душе

Ну там просто очень многое очень заморочно из джавы и на каких нибудт 128 мегабайт не запустить его толком

а был бы больше рад тут etcd какому нибудть

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

нужно только учитывать в случае каких то проблем с кх у вас будут разные данные на репликах , не всем это подходит

Да, там сказано в доке об этом. Но шард больше для опыта

Нежели как средство для реплики

А с ZooKeeper подольше повозиться прийдется

Не надо с ним возиться. ИМХО даже простейшая установка на одной ноде с парой настроек (есть тут: https://clickhouse.yandex/docs/ru/operations/tips/#zookeeper ), будет лучше чем костыли и "мы пойдем своим путём" с rsync.

Правильно конечно - 3 ноды.

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

а вопрос еще есть, что будет если зукипер не доступен? запись в реплицируемые таблицы блочится или нет ?

у меня там был даунтайм у зукипера сыпались какие то ошибки записи, еще не разбирался

С разнесением тут всё зависит от сценария. Вовсе не обязательно. Я бы сказал что разнесение по разным стойкам в серверной уже неплохо.

кликхаус уже просто распределен по шести датацентрам в европе и сша , а зк в одном месте стоит

а вопрос еще есть, что будет если зукипер не доступен? запись в реплицируемые таблицы блочится или нет ?

Если ZK недоступен - запись не работает, чтения продолжают работать.

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

думал что запись работает без проблем, пока их нет только не реплицируются данные

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

Подскажите как решить проблему : Code: 49. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: DDL background thread is not initialized..

Подскажите как решить проблему : Code: 49. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: DDL background thread is not initialized..

Включить distributed_ddl в конфигурационном файле. Это включено по-умолчанию. Но если у вас остался конфиг от старых версий - то там нет секции: <!-- Allow to execute distributed DDL queries (CREATE, DROP, ALTER, RENAME) on cluster. Works only if ZooKeeper is enabled. Comment it if such functionality isn't required. --> <distributed_ddl> <!-- Path in ZooKeeper to queue with DDL queries --> <path>/clickhouse/task_queue/ddl</path> <!-- Settings from this profile will be used to execute DDL queries --> <!-- <profile>default</profile> --> </distributed_ddl>

Это есть

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

У zk кстати есть режим работы ноды, толерантный к задержкам большим, как раз для георезервирования

Это есть

ZooKeeper есть?

Да

У zk кстати есть режим работы ноды, толерантный к задержкам большим, как раз для георезервирования

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

ZooKeeper есть?

Да

Да

А можете показать grep DDLWorker /var/log/clickhouse-server/clickhouse-server.log ?

Проблема возникла после того как на шардах удалили таблице. После чего начали создавать новые

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

https://zookeeper.apache.org/doc/r3.3.3/zookeeperObservers.html

Проблема возникла после того как на шардах удалили таблице. После чего начали создавать новые

а в зукипере почистилось пути после удаления таблиц ?

А можете показать grep DDLWorker /var/log/clickhouse-server/clickhouse-server.log ?

2018.03.29 19:19:09.234614 [ 2 ] <Debug> DDLWorker: Cleaning queue 2018.03.29 19:19:09.238020 [ 2 ] <Debug> DDLWorker: Processing tasks 2018.03.29 19:19:09.238716 [ 2 ] <Debug> DDLWorker: Waiting a watch 2018.03.29 19:27:20.243406 [ 2 ] <Debug> DDLWorker: Started DDLWorker thread 2018.03.29 19:27:20.257661 [ 2 ] <Debug> DDLWorker: Processing tasks 2018.03.29 19:27:20.261233 [ 2 ] <Debug> DDLWorker: Task query-0000000000 (DROP DATABASE dbname ON CLUSTER my_cluster) has been already processed 2018.03.29 19:27:20.262724 [ 2 ] <Debug> DDLWorker: Task query-0000000001 (DROP DATABASE dbname ON CLUSTER my_cluster) has been already processed 2018.03.29 19:27:20.264300 [ 2 ] <Debug> DDLWorker: Task query-0000000002 (DROP DATABASE dbname ON CLUSTER my_cluster) has been already processed 2018.03.29 19:27:20.267053 [ 2 ] <Debug> DDLWorker: Task query-0000000003 (DROP DATABASE dbname ON CLUSTER my_cluster) has been already processed 2018.03.29 19:27:20.268659 [ 2 ] <Debug> DDLWorker: Task query-0000000004 (DROP DATABASE dbname ON CLUSTER my_cluster) has been already processed 2018.03.29 19:27:20.268686 [ 2 ] <Debug> DDLWorker: Waiting a watch

а в зукипере почистилось пути после удаления таблиц ?

А что почистить надо ?

Ну судя по вашему логу что то у вас не так, как удаляли таблицы?

2018.03.29 19:19:09.234614 [ 2 ] <Debug> DDLWorker: Cleaning queue 2018.03.29 19:19:09.238020 [ 2 ] <Debug> DDLWorker: Processing tasks 2018.03.29 19:19:09.238716 [ 2 ] <Debug> DDLWorker: Waiting a watch 2018.03.29 19:27:20.243406 [ 2 ] <Debug> DDLWorker: Started DDLWorker thread 2018.03.29 19:27:20.257661 [ 2 ] <Debug> DDLWorker: Processing tasks 2018.03.29 19:27:20.261233 [ 2 ] <Debug> DDLWorker: Task query-0000000000 (DROP DATABASE dbname ON CLUSTER my_cluster) has been already processed 2018.03.29 19:27:20.262724 [ 2 ] <Debug> DDLWorker: Task query-0000000001 (DROP DATABASE dbname ON CLUSTER my_cluster) has been already processed 2018.03.29 19:27:20.264300 [ 2 ] <Debug> DDLWorker: Task query-0000000002 (DROP DATABASE dbname ON CLUSTER my_cluster) has been already processed 2018.03.29 19:27:20.267053 [ 2 ] <Debug> DDLWorker: Task query-0000000003 (DROP DATABASE dbname ON CLUSTER my_cluster) has been already processed 2018.03.29 19:27:20.268659 [ 2 ] <Debug> DDLWorker: Task query-0000000004 (DROP DATABASE dbname ON CLUSTER my_cluster) has been already processed 2018.03.29 19:27:20.268686 [ 2 ] <Debug> DDLWorker: Waiting a watch

Если вы сервер запустили в 2018.03.29 19:27:20, то все выглядит так, что должно работать

А ддл для удаления таблиц уже работает? , я просто когда тестил оно не работало или как то криво работало, о уже много апдейтов вышло и надобности в нем пока не было.

скорость разработки в нынешнее время поражает конечно, хотя я сам выкатываю апдейты в своем сервисе ежедневно )

Ну судя по вашему логу что то у вас не так, как удаляли таблицы?

drop database

Он кластер ?

Он кластер ?

да

по запросу SELECT * FROM system.zookeeper WHERE path = '/clickhouse/tables/1/' осталась одна запись, возможно как-то надо удалить запись эту ?

А на всех серверах выдало что ок удалилось ? и все сервера имели доступ к зукиперу в этот момент?

А на всех серверах выдало что ок удалилось ? и все сервера имели доступ к зукиперу в этот момент?

какая-то ошибка была при удалении вьюхи. Но шас не могу сказать какая.

Всем привет. Подскажите пожалуйста, правильно я понимаю, что условие where по результату агрегатной функции в одном запросе не может быть выполнено?, Т.е. запрос вида SELECT page_id, uniq(adv_id) AS adv_count, count() AS hits FROM page_stat WHERE adv_count >= 10 GROUP BY page_id падает с ошибкой и нужно делать что-то вроде SELECT page_id, adv_count, hits FROM ( SELECT page_id, uniq(adv_id) AS adv_count, count() AS hits FROM page_stat GROUP BY page_id ) WHERE adv_count >= 10

having

Вот ведь дурная моя голова...спасибо ;)

Привет, select * from <some db> where match(<haystack>, <re>) == 1 как то так этим пользоваться?

select * from <some db> where match(<haystack>, <re>)

/stat@combot

combot.org/chat/-1001080295593

Привет =)) Подскажите, пожалуйста, как с помощью КХ, продифференцировать значения(например есть временной ряд, по датам, и на выходе получить ряд состоящий из разницы текущего значения и предыдущего) Ну или тыкнуть в документацию =)

Привет =)) Подскажите, пожалуйста, как с помощью КХ, продифференцировать значения(например есть временной ряд, по датам, и на выходе получить ряд состоящий из разницы текущего значения и предыдущего) Ну или тыкнуть в документацию =)

https://clickhouse.yandex/docs/en/single/#runningdifferencex

Огромное спс

Добрый день, может быть существует какая-то аггрегатная функция, которая поможет из таблицы выделить некие группы событий. в таблице есть id сессии и время запросов с этим id. в течении суток может повторяться несколько раз. если разница между группами событий больше времени t то это уже новая сессия. вот как-то разбить на такие промежутки (посчитать их количество) возможно или это решается каким-то иным путем? (с 10 утра до 10:15 утра 10 запросов, с 12:00 до 12:25 - 40 запросов итд) или я совсем фантастики хочу ? :)

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

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

Вдруг поможет https://groups.google.com/forum/#!msg/clickhouse/ZCZaMFEvoWw/Zx4WqL4uDgAJ;context-place=msg/clickhouse/9OjvgDEuFuc/f1jRT8mZAQAJ

Вдруг поможет https://groups.google.com/forum/#!msg/clickhouse/ZCZaMFEvoWw/Zx4WqL4uDgAJ;context-place=msg/clickhouse/9OjvgDEuFuc/f1jRT8mZAQAJ

Спасибо, почитаю!

В процессе восстановления данных по процедуре https://groups.google.com/forum/#!topic/clickhouse/ETMmRj__wDk Возник вопрос: Исходя из документации Преобразование из MergeTree в ReplicatedMergeTree вариант восстановления. Удалить одну из реплик и восстановить данные в таблицу ReplicatedMergeTree из данных первой реплики появляется вторая что при больших объемах данных будет копироваться по сети очень долго. Есть возможность избежать этого процесса используя данные из второй реплики?

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

в доке написано Если на разных репликах данные отличаются, то сначала синхронизируйте их, либо удалите эти данные на всех репликах кроме одной. Что можно избежать этого процесса используя синхронизацию данных. Как ее выполнить? Важно что при падении зукипера отвалился только он, а данные есть от двух реплик.

rsync, вероятно

это не смешно )

Мне пока проще так...

Не, дело в том, что мы восстанавливаемся после разрушения zookeeper. При этом данные обеих реплик остаются нетронутыми. Однако при выполнении ATTACH на 1-й реплике автоматом восстанавливаются данные во второй. Получается, мы никак не используем данные из второй реплики, что очень хотелось бы дабы избежать копирования по сети.

подскажите, есть три шарда. Делаю запрос след. рода select sum(impression_cnt) as cnt, sum(click_cnt) as clicks, zone_id AS group_field from view_statistic_by_days_tz3_4_distributed WHERE (campaign_id IN (640)) AND event_date >= '2018-03-24' AND event_date <= '2018-03-30' GROUP BY group_field ORDER BY cnt DESC В ответ приходит Exception: Unexpected stack size in PKCondition::mayBeTrueInRange. И CH уходит в рестарт

Из еррор логов: 2018.03.30 09:01:21.534153 [ 526 ] <Error> BaseDaemon: (from thread 525) Received signal Segmentation fault (11). 2018.03.30 09:01:21.534171 [ 526 ] <Error> BaseDaemon: Address: NULL pointer. 2018.03.30 09:01:21.534183 [ 526 ] <Error> BaseDaemon: Access: read. 2018.03.30 09:01:21.534195 [ 526 ] <Error> BaseDaemon: Unknown si_code. 2018.03.30 09:01:21.620359 [ 526 ] <Error> BaseDaemon: 0. /usr/bin/clickhouse-server(tcmalloc::ThreadCache::ReleaseToCentralCache(tcmalloc::ThreadCache::FreeList*, unsigned long, int)+0x11b) [0x867e09b] 2018.03.30 09:01:21.620383 [ 526 ] <Error> BaseDaemon: 1. /usr/bin/clickhouse-server(tcmalloc::ThreadCache::ListTooLong(tcmalloc::ThreadCache::FreeList*, unsigned long)+0x1c) [0x867e13c] 2018.03.30 09:01:21.620402 [ 526 ] <Error> BaseDaemon: 2. /usr/bin/clickhouse-server(tc_deletearray+0x369) [0x8dbf939] 2018.03.30 09:01:21.620435 [ 526 ] <Error> BaseDaemon: 3. /usr/bin/clickhouse-server(std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()+0x56) [0x2cc1d36] 2018.03.30 09:01:21.620455 [ 526 ] <Error> BaseDaemon: 4. /usr/bin/clickhouse-server(DB::ExpressionAnalyzer::~ExpressionAnalyzer()+0x405) [0x7ccc4a5] 2018.03.30 09:01:21.620468 [ 526 ] <Error> BaseDaemon: 5. /usr/bin/clickhouse-server(DB::InterpreterSelectQuery::~InterpreterSelectQuery()+0x5b) [0x7ce6d0b] 2018.03.30 09:01:21.620486 [ 526 ] <Error> BaseDaemon: 6. /usr/bin/clickhouse-server(DB::InterpreterSelectQuery::~InterpreterSelectQuery()+0x11) [0x7ce6d51] 2018.03.30 09:01:21.620499 [ 526 ] <Error> BaseDaemon: 7. /usr/bin/clickhouse-server(DB::InterpreterSelectWithUnionQuery::~InterpreterSelectWithUnionQuery()+0x62) [0x7cf9492] 2018.03.30 09:01:21.620510 [ 526 ] <Error> BaseDaemon: 8. /usr/bin/clickhouse-server() [0x7d56f05] 2018.03.30 09:01:21.620539 [ 526 ] <Error> BaseDaemon: 9. /usr/bin/clickhouse-server(DB::executeQuery(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, DB::Context&, bool, DB::QueryProcessingStage::Enum)+0x8a) [0x7d573ea] 2018.03.30 09:01:21.620553 [ 526 ] <Error> BaseDaemon: 10. /usr/bin/clickhouse-server(DB::TCPHandler::runImpl()+0x37e) [0x2cd111e] 2018.03.30 09:01:21.620576 [ 526 ] <Error> BaseDaemon: 11. /usr/bin/clickhouse-server(DB::TCPHandler::run()+0x2b) [0x2cd1f2b] 2018.03.30 09:01:21.620589 [ 526 ] <Error> BaseDaemon: 12. /usr/bin/clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x85caf8f] 2018.03.30 09:01:21.620600 [ 526 ] <Error> BaseDaemon: 13. /usr/bin/clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x16a) [0x85cb36a] 2018.03.30 09:01:21.620611 [ 526 ] <Error> BaseDaemon: 14. /usr/bin/clickhouse-server(Poco::PooledThread::run()+0x77) [0x8be1c87] 2018.03.30 09:01:21.620623 [ 526 ] <Error> BaseDaemon: 15. /usr/bin/clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0x38) [0x8bdde98] 2018.03.30 09:01:21.620633 [ 526 ] <Error> BaseDaemon: 16. /usr/bin/clickhouse-server() [0x8d9675f] 2018.03.30 09:01:21.620644 [ 526 ] <Error> BaseDaemon: 17. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7fe5a94e46ba]

выяснил если изменить запрос на select sum(impression_cnt) as cnt, sum(click_cnt) as clicks, zone_id AS group_field from view_statistic_by_days_tz3_4_distributed WHERE (campaign_id = 640) AND event_date >= '2018-03-24' AND event_date <= '2018-03-30' GROUP BY group_field ORDER BY cnt DESC То сервер перестает падать

Не, дело в том, что мы восстанавливаемся после разрушения zookeeper. При этом данные обеих реплик остаются нетронутыми. Однако при выполнении ATTACH на 1-й реплике автоматом восстанавливаются данные во второй. Получается, мы никак не используем данные из второй реплики, что очень хотелось бы дабы избежать копирования по сети.

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

У вас сколько терабайт данных в кх лежит?

Возможно, но все равно немного странно. Мы пробуем процедуру на тестовом кластере - он без нагрузки. Просто залит некий набор данных и по идее данные должны быть идентичны в обеих репликах. Сейчас 2,5T, будет расти.

ну 2.5 если не охото ждать можно на переносном диске

просто изначальная ситуация не понятна

откуда у вас взялся аттач , если просто развалился зк

Изначальная ситуация - отрабатываем полную потерю ZK. Восстанавливаемся по рекомендованной процедуре: https://groups.google.com/forum/#!topic/clickhouse/ETMmRj__wDk

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

Бэкап ZK имеете в виду?

ну да если волнует такая ситуация почему бы и нет

Осталось понять, как его правильно бекапить...

Подскажите, пожалуйста - я правильно понимаю, что materialized view подключённый к движку kafka аккумулирует события, и select потом позволяет селектить по прошлым событиям? Как в таком случае view очищается?

Подскажите, пожалуйста - я правильно понимаю, что materialized view подключённый к движку kafka аккумулирует события, и select потом позволяет селектить по прошлым событиям? Как в таком случае view очищается?

Что значит очищается? Данные из движка kafka проходят через запрос вьюхи и попадает на диск. При чём тут очищение?

Я имел в виду хаускипинг - если вьюха постоянно накапливает данные, как её мейнтейнить?

Для каждой матвьюхи создается таблица с именем имяВьюхи.inner. Пробуйте эту таблицу мейнтейнить

Или рост неограниченный пока не дропнешь и пересоздашь?

А, понятно, спасибо

Про имя таблицы - имяВьюхи.inner - скорее всего нужно будет обернуть в такие кавычки ``

Подскажите пожалуйста, можно ли при вставке в формате CSV через command-line клиента, вставлять пустые значения, указав DEFAULT в колонке ?

нашел https://github.com/yandex/ClickHouse/issues/79

Подскажите, как предотвратить репликацию при ATTACH? данные есть в detach на обоих серверах, хотелось бы подключить их

Подскажите, как предотвратить репликацию при ATTACH? данные есть в detach на обоих серверах, хотелось бы подключить их

+1

я кажется понял в чем дело