Есть асинхронная обертка для clickhouse-driver: https://github.com/mymarilyn/aioch

Если что, используется не нативная асинхронность (которой, вроде бы, в кх нет), а executor. Поэтому у людей вроде проблемы бывают

Если что, используется не нативная асинхронность (которой, вроде бы, в кх нет), а executor. Поэтому у людей вроде проблемы бывают

Чтобы нативную сделать, надо, к сожалению, весь код в лапшу async - await превратить. Как лучше сделать я пока не придумал. Если есть предложения — я готов к диалогу :)

Чтобы нативную сделать, надо, к сожалению, весь код в лапшу async - await превратить. Как лучше сделать я пока не придумал. Если есть предложения — я готов к диалогу :)

select/epool? :D

select/epool? :D

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

День добрый, подскажите такой момент: возможно ли настроить мат.вьюху таким образом, чтобы она хранила argMax колонки из replacingMergeTree таблицы?

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

над подумать :)

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

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

Пока нет

Но Алексей говорит, в скором времени должно появиться как побочная фича

над подумать :)

Пишите в issues или PR если что

Поясните, плиз, если для реплики стоит replicated_can_become_leader=0, и умирают все реплики, у которых replicated_can_become_leader=1, станет ли лидером реплика с флагом 0 из оставшихся, когда больше нет реплик с replicated_can_become_leader=1? или репликация сломается?

И где можно почитать про работу https://clickhouse.yandex/docs/en/utils/clickhouse-copier/ в контексте решардинга? Особености работы - оффлайн решардниг, онлайн. Или у кого-то есть опыт такой, просьба поделиться) Из прочтения доки решение задачи добавления нового шарда и перекидывание на него части данных похоже осуществляется созданием новых частичных дублей решардируемых таблиц на уже существующих шардах. Так ли это?

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

Да, просто пишите в новый. Если вы данные удаляете, то они в какой-то момент выровняются по размеру.

Спасибо @kshvakov

А возможно ли как-то удалить партиции у материлизованной вьюхи?

А возможно ли как-то удалить партиции у материлизованной вьюхи?

Да, в .inner. таблице для этой въюхи

у меня есть подозрение, что должна существовать функция topKIf, но что-то я ее даже в исходниках не нахожу. это я грежу наяву? )

Installing new version of config file /etc/init.d/clickhouse-server ... /var/lib/dpkg/info/clickhouse-server.postinst: 24: [: unexpected operator /var/lib/dpkg/info/clickhouse-server.postinst: 24: [: unexpected operator /var/lib/dpkg/info/clickhouse-server.postinst: 24: [: unexpected operator

ругается на if [ "$OS" == "rhel" ] || [ "$OS" == "centos" ] || [ "$OS" == "fedora" ]; then

у меня есть подозрение, что должна существовать функция topKIf, но что-то я ее даже в исходниках не нахожу. это я грежу наяву? )

а, все, понял https://clickhouse.yandex/docs/ru/agg_functions/combinators/#-if

Да, та ошибка - в пакете версии 1.1.54381. До 1.1.54378 апгрейдится без проблем

Господа, я не в курсе, где изменилась логика у listen, но стоит где-то это документировать. Сейчас было две записи listen - на :: и на 127.0.0.1 После апгрейда до 54381 таки потребовалось вторую удалить.

ну а зачем вам вторая то ? если вы и так все интерфейсы слушаете?

По-хорошему - незачем. Но и ругаться надо как-то более прилично в логах, чем "уже кто-то занял порт на 127.0.0.1"

А так - это тестовый сервер, там всяких извращений есть...

Коллеги, подскажите, пожалуйста, что нужно сделать чтобы избежать такой ошибки: [160] ClickHouse exception, code: 160, host: groot-clickhouse.vcp.digitalaccess.ru, port: 80; Code: 160, e.displayText() = DB::Exception: Pattern application proves too difficult, exceeding max iterations (1000000), e.what() = DB::Exceptionпри использовании функций sequenceCount и sequenceMatch. Можно где-то увеличить кол-во итераций? или может что-то другое сделать..? при этом сами условия выглядят просто: sequenceCount('(?1).*(?2)(?t>=300).*(?3)')(datetime_server , ui_type='description' , ui_type='payment_form' , name = 'purchase' and object_id = 6 )и для одной строки по которой происходит круппировка никак не может набраться 1млн строк

киньте пожалуйста ссылкой, где написано как правильно настраивается кластер из 2+ нод

ну шарды и реплики разные вещи

киньте пожалуйста ссылкой, где написано как правильно настраивается кластер из 2+ нод

https://clickhouse.yandex/docs/en/single/#table_engines-replication

а с ZooKeeper и Docker как это добро настраивается?

а с ZooKeeper и Docker как это добро настраивается?

Там же всё написано.

Ребята, а что делать, если данные после вставки “зависли” в темповой директории distributed? Был выполнен запрос вида INSERT INTO SELECT FROM, который отработал успешно, но в целевую таблицу попала только часть данных. Причём insert_distributed_sync = 1. e.g. 1TB clickhouse/data/some_table_distributed/default@192%2E15%2E0%2E100:9000,default@192%2E15%2E0%2E100:9000 При этом в логах видно безуспешные попытки вставить эти данные: 2018.05.18 15:38:25.348033 [ 84 ] <Error> some_table_distributed.Distributed.DirectoryMonitor: Code: 209, e.displayText() = DB::NetException: Timeout exceeded while writing to socket (192.15.0.100:9000), e.what() = DB::NetException, Stack trace: Здесь нужно увеличить send_timeout? Или может какая-то настройка оси может мешать? ClickHouse version 1.1.54380

с этого хоста, где some_table_distributed, вы можете подключиться к clickhouse-client -h 192.15.0.100?

юзеру default в users.xml разрешено подключаться к 192.15.0.100?

telnet 192.15.0.100 9000?

Там же всё написано.

прочитал все, так и не нашел, где описана настройка кластера с ZooKeeper и Docker

прочитал все, так и не нашел, где описана настройка кластера с ZooKeeper и Docker

Из вашего вопроса не понятно, зачем вам вообще Docker, что вы хотите контейнеризовывать, а главное, зачем. Docker не является необходимым компонентом CH

прочитал все, так и не нашел, где описана настройка кластера с ZooKeeper и Docker

Вот же Чтобы использовать репликацию, укажите в конфигурационном файле адреса ZooKeeper кластера. Пример: <zookeeper> <node index="1"> <host>example1</host> <port>2181</port> </node> <node index="2"> <host>example2</host> <port>2181</port> </node> <node index="3"> <host>example3</host> <port>2181</port> </node> </zookeeper>

Из вашего вопроса не понятно, зачем вам вообще Docker, что вы хотите контейнеризовывать, а главное, зачем. Docker не является необходимым компонентом CH

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

Вот же Чтобы использовать репликацию, укажите в конфигурационном файле адреса ZooKeeper кластера. Пример: <zookeeper> <node index="1"> <host>example1</host> <port>2181</port> </node> <node index="2"> <host>example2</host> <port>2181</port> </node> <node index="3"> <host>example3</host> <port>2181</port> </node> </zookeeper>

если я привильно понял ZooKeeper уже есть в составе docker контейнера ?!

с этого хоста, где some_table_distributed, вы можете подключиться к clickhouse-client -h 192.15.0.100?

Спасибо за ответ. Да, всё подключается, коннекты ко всем узлам есть — сеть внутренняя. Если и были какие-то сбои, то сейчас всё нормально. Но в логах время попыток текущее, потому и удивляет.

если я привильно понял ZooKeeper уже есть в составе docker контейнера ?!

Какого контейнера? Поставьте Zookeeper и пропишите его в настройки

в чате было только, что кто-то собирает CH в докере, ничего про ZK. ZK вообще вспомогательная вещь, для репликации только. CH не поставляется в репозитории с ZK как обязательной зависимостью и данные хранить в контейнере, вроде бы, очень порочная практика. используйте volume mapping

а отдельно zk в докере можете взять любой, например, здесь. https://github.com/31z4/zookeeper-docker 3.5.3 хорошо работает, даже несмотря на бета

Коллеги, добавил запись в конфиге, не работает

<format_csv_delimiter>###</format_csv_delimiter>

ссылка не работает https://clickhouse.yandex/docs/ru/docs/ru/operations/settings/settings/#format_csv_delimiter

в кавычки взять не помогло

Господа, я не в курсе, где изменилась логика у listen, но стоит где-то это документировать. Сейчас было две записи listen - на :: и на 127.0.0.1 После апгрейда до 54381 таки потребовалось вторую удалить.

Изменился флаг reuse port чтоб несколько серверов на одном ип-порт не могли запуститься. Как побочный эффект - :: и 0.0.0.0 считаются одним адресом и одновременно их слушать нельзя. тоесть оставить :: самый универсальный вариант. если очень нужно старое поведение - можно написать в конфиг <listen_reuse_port>0</listen_reuse_port>

Ясно.

здрасти. У меня не работает DELETE, не подскажете в чем дело?

а UPDATE?

здрасти. У меня не работает DELETE, не подскажете в чем дело?

delete чего?)

Так делиты обещали выложить в конце мая

?

Так делиты обещали выложить в конце мая

крутяк!

Привет Есть ли какой-либо таймаут у операций CREATE/DROP TABLE, ATTACH PARTITION?

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

Возможно ли кешировать запрос SELECT что бы потом его можно было использовать в секции FROM для запросов UNION ALL ? Как это реализовано в PostgreSQL c помощью WITH

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

а у Вас проблемы сразу с кластером зукиперов?

а у Вас проблемы сразу с кластером зукиперов?

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

даже кликхаус не рестартует нормально, только через kill -9

такой вопрос подскажет кто-то: на одной реплике сказал detach partition 201709, скопировал данные из папки detached в detached на реплику другого шарда, сказал на той реплике attach partition. На ней данные подцепились, но на другую реплику этого шарда что-то данные не спешат реплицироваться, в system.replication_queue таски на эту партицию вижу, однако данные что-то не приезжают, смотрю по system.parts

в system.replication_queue у этих тасков не меняется last_attempt_time: 2018-05-18 17:58:02

так и висит

position: 3 node_name: queue-0002396724 type: GET_PART create_time: 2018-05-18 17:58:02 required_quorum: 0 source_replica: 1clickhouse0003 new_part_name: 20170902_20170930_11_11_0 parts_to_merge: [] is_detach: 0 is_currently_executing: 1 num_tries: 1 last_exception: last_attempt_time: 2018-05-18 17:58:02 num_postponed: 0 postpone_reason: last_postpone_time: 0000-00-00 00:00:00 а, тут есть колонка is_currently_executing: 1, типа все нормально? а не вижу в parts, потому что куски большие, еще скопировались что-ли

такой вопрос подскажет кто-то: на одной реплике сказал detach partition 201709, скопировал данные из папки detached в detached на реплику другого шарда, сказал на той реплике attach partition. На ней данные подцепились, но на другую реплику этого шарда что-то данные не спешат реплицироваться, в system.replication_queue таски на эту партицию вижу, однако данные что-то не приезжают, смотрю по system.parts

А где находится папка detached

в папке таблицы

Возможно ли кешировать запрос SELECT что бы потом его можно было использовать в секции FROM для запросов UNION ALL ? Как это реализовано в PostgreSQL c помощью WITH

create table tttXF4ddd7225X engine=Memory as select * from system.one select * from tttXF4ddd7225X; select * from system.one union all select * from tttXF4ddd7225X а да еще есть CREATE [TEMPORARY] TABLE, но там сессия нужна.

сорян, в папке таблицы увидел директории ./tmp_fetch_201709*, по объему видно что все нормально, копируется!

зря вообще паниковал

Почему могут не создаваться партиции на части шардов? А именно: КХ много в логах ругается на "Cannot read all data" и "No part ... in table". Вставка идёт в Distributed таблицу. При этом, каких-либо ошибок работы с данными - не видно. Все данные пишутся и читаются, ошибки именно на уровне КХ. Версия 1.1.54380. P.S. по подобной ошибке поискал в чате - чего-то полезного не нашёл.

Ещё раз спрошу, т.к. пока не смог понять причину. Конфиги/макросы проверил - всё хорошо. Таблиц множесто - могли перепутаться пути в зоокипере при переносе в шарды, но проверил - не нашёл такого.

Ещё раз спрошу, т.к. пока не смог понять причину. Конфиги/макросы проверил - всё хорошо. Таблиц множесто - могли перепутаться пути в зоокипере при переносе в шарды, но проверил - не нашёл такого.

А на какие именно действия в логе он ругается?

Ещё раз спрошу, т.к. пока не смог понять причину. Конфиги/макросы проверил - всё хорошо. Таблиц множесто - могли перепутаться пути в зоокипере при переносе в шарды, но проверил - не нашёл такого.

Что-то такое было, я делал detach partition, потом шел в проблемную реплику, удалял эту партицию из папки detached, и потом делал attach partition. Проблемная реплика скачивала с нормальной эту партицию.

Опубликованы презентации с C++ митапа: https://yandex.github.io/clickhouse-presentations/meetup15/architecture/ https://yandex.github.io/clickhouse-presentations/meetup15/lightning/mipt.pdf https://yandex.github.io/clickhouse-presentations/meetup15/lightning/badoo.pdf https://yandex.github.io/clickhouse-presentations/meetup15/lightning/ninja.pdf https://yandex.github.io/clickhouse-presentations/meetup15/lightning/erlyvideo.key https://yandex.github.io/clickhouse-presentations/meetup15/mergetree/mergetree.pdf Видео чуть позже.

А на какие именно действия в логе он ругается?

На селекты. Лог выглядит так: шард выводит ошибку "No part", другой шард (с которого выбирается) - говорит "Cannot read all data".

Что-то такое было, я делал detach partition, потом шел в проблемную реплику, удалял эту партицию из папки detached, и потом делал attach partition. Проблемная реплика скачивала с нормальной эту партицию.

Спасибо, попробую. Ругается на таких партиций десяток, но если что скриптом пройдусь.

Никто не напомнит, полосу пропуская репликации никак нельзя ограничить в конфиге?

Спасибо, попробую. Ругается на таких партиций десяток, но если что скриптом пройдусь.

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

На селекты. Лог выглядит так: шард выводит ошибку "No part", другой шард (с которого выбирается) - говорит "Cannot read all data".

Если ошибка возвращается на SELECT запрос - значит плохо с данными на файловой системе. Сервер должен пометить куски как битые, отложить в сторону, скачать их с реплики. Если такое происходит постоянно - может быть на сервере есть какой-то посторонний процесс, который делает какие-то манипуляции с данными в файловой системе сам? Также такое может быть, если сервер поднялся с битой файловой системой (возможны самые разные спецэффекты, например, бесконечное выполнение readdir) - в этом случае, при наличии реплики, сервер проще всего переналить.

Что-то такое было, я делал detach partition, потом шел в проблемную реплику, удалял эту партицию из папки detached, и потом делал attach partition. Проблемная реплика скачивала с нормальной эту партицию.

Спасибо, попробовал, помогло.

Если ошибка возвращается на SELECT запрос - значит плохо с данными на файловой системе. Сервер должен пометить куски как битые, отложить в сторону, скачать их с реплики. Если такое происходит постоянно - может быть на сервере есть какой-то посторонний процесс, который делает какие-то манипуляции с данными в файловой системе сам? Также такое может быть, если сервер поднялся с битой файловой системой (возможны самые разные спецэффекты, например, бесконечное выполнение readdir) - в этом случае, при наличии реплики, сервер проще всего переналить.

Похоже, дело было в недоступности zookeeper в один из дней. Сейчас смотрел - ругается только на партиции за один из дней. Как понимаю, из-за недоступности zookeeper - не создались партиции на части серверов (и для всех таблиц, соответственно).

Недоступность ZooKeeper не влияет на корректность данных. Во время недоступности ZK нет возможности вставить новые данные, приостановлен процесс репликации. SELECT продолжает корректно работать.

Недоступность ZooKeeper не влияет на корректность данных. Во время недоступности ZK нет возможности вставить новые данные, приостановлен процесс репликации. SELECT продолжает корректно работать.

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

ругается на if [ "$OS" == "rhel" ] || [ "$OS" == "centos" ] || [ "$OS" == "fedora" ]; then

fixed - https://github.com/yandex/ClickHouse/commit/22d6afd2ad385ae2dfe8170738323b21e432b49c#diff-519ba54a38ff8522c32c8d2fc0740f80R25

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

SELECT table, name, formatReadableSize(sum(data_compressed_bytes)) AS compressed, formatReadableSize(sum(data_uncompressed_bytes)) AS uncompressed, sum(data_uncompressed_bytes) / sum(data_compressed_bytes) AS ratio FROM system.columns WHERE database != 'system' GROUP BY table, name ORDER BY table, ratio DESC;

SELECT table, name, formatReadableSize(sum(data_compressed_bytes)) AS compressed, formatReadableSize(sum(data_uncompressed_bytes)) AS uncompressed, sum(data_uncompressed_bytes) / sum(data_compressed_bytes) AS ratio FROM system.columns WHERE database != 'system' GROUP BY table, name ORDER BY table, ratio DESC;

болльшое спасибо

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

Возможно, если в ZK оказались неправильные данные - например, если его состояние откатили на предыдущий снапшот.

о, я молодец, простым запросом с count и group by смог в Segmentation fault (11) ввеси CH =)

логи есть смысл кому-то отправлять или лучше issue завести?

начало (возможно интригующее): 2018.05.17 18:51:29.405085 [ 60 ] <Error> BaseDaemon: ######################################## 2018.05.17 18:51:29.405098 [ 60 ] <Error> BaseDaemon: (from thread 75) Received signal Segmentation fault (11). 2018.05.17 18:51:29.405106 [ 60 ] <Error> BaseDaemon: Address: NULL pointer. 2018.05.17 18:51:29.405113 [ 60 ] <Error> BaseDaemon: Access: read. 2018.05.17 18:51:29.405119 [ 60 ] <Error> BaseDaemon: Unknown si_code. 2018.05.17 18:51:29.423342 [ 60 ] <Error> BaseDaemon: 0. /usr/bin/clickhouse-server() [0x8084338] 2018.05.17 18:51:29.423402 [ 60 ] <Error> BaseDaemon: 1. /usr/bin/clickhouse-server(void DB::Aggregator::executeImplCase<false, DB::AggregationMethodString<HashMapTable<StringRef, HashMapCellWithSavedHash<StringRef, char*, DefaultHash<StringRef>, HashTableNoState>, Defau ltHash<StringRef>, HashTableGrower<8ul>, Allocator<true> > > >(DB::AggregationMethodString<HashMapTable<StringRef, HashMapCellWithSavedHash<StringRef, char*, DefaultHash<StringRef>, HashTableNoState>, DefaultHash<StringRef>, HashTableGrower<8ul>, Allocator<true> > >&, DB ::AggregationMethodString<HashMapTable<StringRef, HashMapCellWithSavedHash<StringRef, char*, DefaultHash<StringRef>, HashTableNoState>, DefaultHash<StringRef>, HashTableGrower<8ul>, Allocator<true> > >::State&, DB::Arena*, unsigned long, std::vector<DB::IColumn const*, s td::allocator<DB::IColumn const*> >&, DB::Aggregator::AggregateFunctionInstruction*, std::vector<unsigned long, std::allocator<unsigned long> > const&, std::vector<StringRef, std::allocator<StringRef> >&, char*) const+0xc3) [0x80dd003]

Ребят, а это возможно в MergeTree добавить один из столбцов в primary key?