1) на том сервере в каталоге с Distributed таблицей не лежит много-много всяких "отсутствующих" инсертов?

2) в обоих шардах равномерно "пропадают" данные или только в одном?

1) Имеется ввиду в /var/lib/clickhouse/data ? Да, на ноде, через которую запись, лежит много /detached/ частей, все сохраняются. 2) При вставке на любую из нод – сохраняется только в локальной шарде, то есть не уходит на соседние сервера, насколько я понимаю.

А что в system.replication_queue?

Пусто

Вот получается, что ZK ругается на NodeExists, данные кладутся в /detached/ignored_* и все, непонятно как его пнуть )

Хм. Т.е. данные "застревают" в Distributed не доходя до ReplicatedMergeTree. Может быть Distributed не может подключиться к другим серверам? И только если на локалхост попадает то инсерт идет?

Хм. Т.е. данные "застревают" в Distributed не доходя до ReplicatedMergeTree. Может быть Distributed не может подключиться к другим серверам? И только если на локалхост попадает то инсерт идет?

Между нодами нет проблем соединяться + запросы на Distributed идут очень хорошо. Гипотеза хорошая, но тогда не понимаю физического смысла ругани ZK ?

А есть кореляция между неудавшимися инсертами и записями в логах зукипера?

А есть кореляция между неудавшимися инсертами и записями в логах зукипера?

Записи идут каждые 5 секунд, записи в логах зукипера появляются каждые 1-3 минуты. Но появились они как раз тогда, когда данные начали теряться.

а ALTER TABLE [db.]table DELETE WHERE не умеет on cluster ? Или можно сделать это на дистрибьютед таблицу ?

проверил руками умеет

Записи идут каждые 5 секунд, записи в логах зукипера появляются каждые 1-3 минуты. Но появились они как раз тогда, когда данные начали теряться.

Попробуйте включить insert_distributed_sync=1 может тогда скажет что у него не так?

Коллеги, подскажите, а вызов OPTIMIZE TABLE db.name PARTITION partition FINAL гарантирует, что после вызова все дубликаты будут удалены?

для ReplacingMergeTree

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

Коллеги, подскажите, а вызов OPTIMIZE TABLE db.name PARTITION partition FINAL гарантирует, что после вызова все дубликаты будут удалены?

До следующего инсерта... :)

а как ключевое слово FINAL влияет на этот процесс?

а как ключевое слово FINAL влияет на этот процесс?

А в документации нет ответа на этот вопрос?

а как ключевое слово FINAL влияет на этот процесс?

на процесс следующего инсерта по сути никак

Добрый день. Не подскажете через alter table нельзя же указать ключ семплирования SAMPLE BY, только через create table? Хочу потестить Distributed и max_parallel_replicas>1 без перезаливки

Ребят, в докере вот такая штука в логе пишется при старте сервера. Application: It looks like the process has no CAP_NET_ADMIN capability, 'taskstats' performance statistics will be disabled. It could happen due to incorrect ClickHouse package installation. You could resolve the problem manually with 'sudo setcap cap_net_admin=+ep /usr/bin/clickhouse'. Note that it will not work on 'nosuid' mounted filesystems. It also doesn't work if you run clickhouse-server inside network namespace as it happens in some containers. После этого сервер отключается

А перед этим еще вот такая штука 2018.09.21 13:16:30.828709 [ 3 ] <Error> bool DB::{anonymous}::checkPermissionsImpl(): Code: 412, e.displayText() = DB::Exception: Can't receive Netlink response: error -2, e.what() = DB::Exception, Stack trace: 0. /usr/bin/clickhouse-server(StackTrace::StackTrace()+0x16) [0x9491e46] 1. /usr/bin/clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x22) [0x3019952] 2. /usr/bin/clickhouse-server() [0x9499185] 3. /usr/bin/clickhouse-server(DB::TaskStatsInfoGetter::TaskStatsInfoGetter()+0xf0) [0x9499370] 4. /usr/bin/clickhouse-server(DB::TaskStatsInfoGetter::checkPermissions()+0xe1) [0x9499541] 5. /usr/bin/clickhouse-server(DB::ThreadStatus::initPerformanceCounters()+0x10d) [0x949a85d] 6. /usr/bin/clickhouse-server(DB::ThreadStatus::initializeQuery()+0x292) [0x718ec02] 7. /usr/bin/clickhouse-server(DB::CurrentThread::initializeQuery()+0x2d) [0x718ec8d] 8. /usr/bin/clickhouse-server(DB::BackgroundProcessingPool::threadFunction()+0xad1) [0x72fdb51] 9. /usr/bin/clickhouse-server() [0x9e659ef] 10. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f84364116ba] 11. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f8435a3241d]

Кто-то такое лечил?

а как посмотреть текущее значение finished_mutations_to_keep ? в system.settings почему то его нет

system.merge_tree_settings

system.merge_tree_settings

на последнем митапе рассказывали про всякие там метрики и пр. штуки и предупреждали, что во всяких докерах это работать не будет и все такое. Я вот 18.12.17 в докере на 16 убунте пытаюсь стартануть и получаю ошибку выше. Это как-то связано с тем, что у меня 16 убунта?

Можно как-то этот профайлер выключить вообще?

А в документации нет ответа на этот вопрос?

не очень понятен результат. Допустим я вызвал оптимизацию партиций OPTIMIZE TABLE db.name PARTITION partition, этот процесс занял 5 минут. Как я понимаю этим 5 минут и происходило слияние нескольких кусков в один. Если бы я вызвал OPTIMIZE TABLE db.name PARTITION partition FINAL , то рзультат слияния и оптимизации был бы такой же или другой?

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

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

а мержи закончились ?

а мержи закончились ?

а куда смотреть, чтобы понять?

я вот сейчас просто смотрю в лог кх

А что за браузер?

Хром последний на федоре

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

Попробуйте включить insert_distributed_sync=1 может тогда скажет что у него не так?

Ох, спасибо, сразу грохнулся, есть теперь новые вводные ) Как разберемся – отпишусь.

не очень понятен результат. Допустим я вызвал оптимизацию партиций OPTIMIZE TABLE db.name PARTITION partition, этот процесс занял 5 минут. Как я понимаю этим 5 минут и происходило слияние нескольких кусков в один. Если бы я вызвал OPTIMIZE TABLE db.name PARTITION partition FINAL , то рзультат слияния и оптимизации был бы такой же или другой?

OPTIMIZE без FINAL объединяет КАКИЕ-ТО куски (те которые согласно представлению КХ более всего в этом нуждаются). В результате кусков будет просто меньше. OPTIMIZE FINAL объединяет все куски одной партиции. В результате останется один большой кусок.

OPTIMIZE без FINAL объединяет КАКИЕ-ТО куски (те которые согласно представлению КХ более всего в этом нуждаются). В результате кусков будет просто меньше. OPTIMIZE FINAL объединяет все куски одной партиции. В результате останется один большой кусок.

Не обязательно же один большой кусок, да? Если размер куска выставлен в 150Gb, а данных на 350 например, то будет три куска. Правильно?

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

а почему кх перемержил все куски при alter delete хотя там был задет всего один месяц ?

Хром последний на федоре

видел тут вопрос по версии. сейчас стабильная версия хрома, которая у меня и есть — 69.0.3497.92.

видел тут вопрос по версии. сейчас стабильная версия хрома, которая у меня и есть — 69.0.3497.92.

Сначала прочитал хром на последней федоре. Потом перечитал что это последний хром на какой-то федоре :) Сейчас попробовал - действительно на одностраничной версии картиники не работают.

Не обязательно же один большой кусок, да? Если размер куска выставлен в 150Gb, а данных на 350 например, то будет три куска. Правильно?

Я не уверен, но по-моему FINAL игноронирует настройки на максимальный размер куска.

Угу. Похоже на то: https://github.com/yandex/ClickHouse/blob/bf53c4a31d4966c07ccc00f4170ca7f34811812c/dbms/src/Storages/StorageReplicatedMergeTree.cpp#L3022

предположим у вас два шарда, с таблицами tableX_ и tableY_, они шардированы вместе как вы уже сказали и вам надо сджойнить локально shard1: tableX_, tableY_ shard2: tableX_, tableY_ на обоих шардах создаете дистрибьютид tableX, tableY которые смотрят на tableX_, tableY_ запускаете запрос на любом шарде select a,b from (select a from tableX where foo=bar all inner join (select b from tableY_ where x = y) using id) он будет инициатором и пошлет сам себе и второму шарды запрос select a,b from (select a from tableX_ where foo=bar all inner join (select b from tableY_ where x = y) using id)

в том и дело, что у меня это не работает для джойнов. для вложенных селектов (IN, которые полагаются на тот же принцип): // запрос к distributed таблице с условием по локальному шарду // работает select a from tableX where x in (select x from tableY_) vs // запрос к distributed таблице с join по локальному шарду // tableX, tableY шардированы по sip64(id) // НЕ работает select a,b from (select a from tableX all inner join (select b from tableY_) using id) // table default.tableY_ does not exist

не очень понятен результат. Допустим я вызвал оптимизацию партиций OPTIMIZE TABLE db.name PARTITION partition, этот процесс занял 5 минут. Как я понимаю этим 5 минут и происходило слияние нескольких кусков в один. Если бы я вызвал OPTIMIZE TABLE db.name PARTITION partition FINAL , то рзультат слияния и оптимизации был бы такой же или другой?

Гляжу на код, похоже я был не совсем прав. OPTIMIZE TABLE - выбирает для объединения какие-то куски (при выборе старается чтоб размер финального куска не превышал max_bytes_to_merge_at_max_space_in_pool), делает это так же как фоновые слияния OPTIMIZE TABLE PARTITION xxx - выбирает для объединения все куски указанной партиции (если кусок всего один - не делает ничего). OPTIMIZE TABLE PARTITION xxx FINAL - выбирает для объединения все куски указанной партиции (если кусок всего один - переписывает его ещё раз). OPTIMIZE TABLE FINAL - делает OPTIMIZE TABLE PARTITION xxx FINAL во всех партициях.

в том и дело, что у меня это не работает для джойнов. для вложенных селектов (IN, которые полагаются на тот же принцип): // запрос к distributed таблице с условием по локальному шарду // работает select a from tableX where x in (select x from tableY_) vs // запрос к distributed таблице с join по локальному шарду // tableX, tableY шардированы по sip64(id) // НЕ работает select a,b from (select a from tableX all inner join (select b from tableY_) using id) // table default.tableY_ does not exist

Ничего не понимаю. Если у вас есть таблицы 1) tableX_distributed которая "смотрит" на tableX_sharded_replicated 2) tableY_distributed которая "смотрит" на tableY_sharded_replicated и запускаете SELECT .. FROM tableX_distributed INNER JOIN tableY_distributed. и хотите добиться чтобы на каждом шарде были выполнены SELECT .. FROM tableX_sharded_replicated INNER JOIN tableY_sharded_replicated а результат объединен, то это соответствует настройке distributed_product_mode=local.

Можете на каждом шарде посмотреть какой запрос прилетает от distributed, если есть сомнения.

в том и дело, что у меня это не работает для джойнов. для вложенных селектов (IN, которые полагаются на тот же принцип): // запрос к distributed таблице с условием по локальному шарду // работает select a from tableX where x in (select x from tableY_) vs // запрос к distributed таблице с join по локальному шарду // tableX, tableY шардированы по sip64(id) // НЕ работает select a,b from (select a from tableX all inner join (select b from tableY_) using id) // table default.tableY_ does not exist

на обоих шардах CREATE TABLE tableX_ ( id Int64, a Int64 ) ENGINE = ReplicatedMergeTree ('/clickhouse/{cluster}/tables/{shard}/tableX_','{replica}') PARTITION BY tuple() order by tuple(); CREATE TABLE tableY_ ( id Int64, a Int64) ENGINE = ReplicatedMergeTree ('/clickhouse/{cluster}/tables/{shard}/tableY_','{replica}') PARTITION BY tuple() order by tuple(); CREATE TABLE tableX as tableX_ ENGINE = Distributed (segmented_mirrored,currentDatabase(),'tableX_',rand ()); CREATE TABLE tableY as tableY_ ENGINE = Distributed (segmented_mirrored,currentDatabase(),'tableY_',rand ()); на первом insert into tableX_ values(1,1); insert into tableY_ values(1,1); на втором insert into tableX_ values(2,2); insert into tableY_ values(2,2); select a from tableX where id in (select id from tableY_) 2 1 select a from (select a,id from tableX all inner join (select a,id from tableY_) using id) 2 1

на обоих шардах CREATE TABLE tableX_ ( id Int64, a Int64 ) ENGINE = ReplicatedMergeTree ('/clickhouse/{cluster}/tables/{shard}/tableX_','{replica}') PARTITION BY tuple() order by tuple(); CREATE TABLE tableY_ ( id Int64, a Int64) ENGINE = ReplicatedMergeTree ('/clickhouse/{cluster}/tables/{shard}/tableY_','{replica}') PARTITION BY tuple() order by tuple(); CREATE TABLE tableX as tableX_ ENGINE = Distributed (segmented_mirrored,currentDatabase(),'tableX_',rand ()); CREATE TABLE tableY as tableY_ ENGINE = Distributed (segmented_mirrored,currentDatabase(),'tableY_',rand ()); на первом insert into tableX_ values(1,1); insert into tableY_ values(1,1); на втором insert into tableX_ values(2,2); insert into tableY_ values(2,2); select a from tableX where id in (select id from tableY_) 2 1 select a from (select a,id from tableX all inner join (select a,id from tableY_) using id) 2 1

Так тоже должно работать. Этот пример кстати есть в документации: https://clickhouse.yandex/docs/ru/query_language/select/#queries-distributed-subrequests

А max_bytes_to_merge_at_max_space_in_pool где задается ?

Тогда distributed_product_mode вам не нужен.

А max_bytes_to_merge_at_max_space_in_pool где задается ?

merge_tree настрйки или для конкретной таблицы в SETTINGS

в users.xml ?

в users.xml ?

в config.xml <merge_tree> <!-- Maximum in total size of parts to merge, when there are maximum free threads in background pool --> <!-- 200 * 1024 * 1024 * 1024 --> <max_bytes_to_merge_at_max_space_in_pool>214748364800</max_bytes_to_merge_at_max_space_in_pool> или для каждой таблицы https://github.com/yandex/ClickHouse/issues/2607

в users.xml ?

Если для всех таблиц то тут: https://github.com/yandex/ClickHouse/blob/9975960d77e0745ebec07b69129ac816a9738439/dbms/programs/server/config.xml#L318

на обоих шардах CREATE TABLE tableX_ ( id Int64, a Int64 ) ENGINE = ReplicatedMergeTree ('/clickhouse/{cluster}/tables/{shard}/tableX_','{replica}') PARTITION BY tuple() order by tuple(); CREATE TABLE tableY_ ( id Int64, a Int64) ENGINE = ReplicatedMergeTree ('/clickhouse/{cluster}/tables/{shard}/tableY_','{replica}') PARTITION BY tuple() order by tuple(); CREATE TABLE tableX as tableX_ ENGINE = Distributed (segmented_mirrored,currentDatabase(),'tableX_',rand ()); CREATE TABLE tableY as tableY_ ENGINE = Distributed (segmented_mirrored,currentDatabase(),'tableY_',rand ()); на первом insert into tableX_ values(1,1); insert into tableY_ values(1,1); на втором insert into tableX_ values(2,2); insert into tableY_ values(2,2); select a from tableX where id in (select id from tableY_) 2 1 select a from (select a,id from tableX all inner join (select a,id from tableY_) using id) 2 1

Но мне больше нравится вариант с distributed_product_mode. Джойнить distributed с другой distributed - как-то более логично :)

Но мне больше нравится вариант с distributed_product_mode. Джойнить distributed с другой distributed - как-то более логично :)

в смысле джоинить distributed с distributed?)

в смысле джоинить distributed с distributed?)

Выполнять JOIN. Долгая история. См. выше :)

Но мне больше нравится вариант с distributed_product_mode. Джойнить distributed с другой distributed - как-то более логично :)

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

Если для всех таблиц то тут: https://github.com/yandex/ClickHouse/blob/9975960d77e0745ebec07b69129ac816a9738439/dbms/programs/server/config.xml#L318

Задал, в config-preprocessed.xml изменения вижу, в system.settings не вижу данной переменной, данные по optimize table ... partition 201807 final; не мерджатся, что ещё сделать?

объем партиции около 400Г дб, переменную задал =2ТБ

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

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

Задал, в config-preprocessed.xml изменения вижу, в system.settings не вижу данной переменной, данные по optimize table ... partition 201807 final; не мерджатся, что ещё сделать?

Посмотреть что появляется в логах при оправке запроса OPTIMIZE

в clickhouse-server.err.log - ничего

ммм... а если написать название партиции в кавычках?

кстати пятница, вечер приближается - вы точно хотите запустить мердж 400 гб данных сейчас? :)

в основном логе: 2018.09.21 15:39:34.821056 [ 320 ] <Debug> executeQuery: (from 127.0.0.1:57372, query_id: 6ce9eca5-d3eb-4b49-b 889-b9df3296ff49) optimize table graphite partition 201807 final 2018.09.21 15:39:34.822672 [ 320 ] <Information> default.graphite (StorageReplicatedMergeTree): Cannot select parts for optimization: Current mutation versions of parts 20180701_20180731_0_94304_10 and 20180701_20180731_ 94305_98563_38_94389 differ: 0 and 94389 respectively

в остальных партициях тоже были мутации и они смерджились в 1 кусок

Задал, в config-preprocessed.xml изменения вижу, в system.settings не вижу данной переменной, данные по optimize table ... partition 201807 final; не мерджатся, что ещё сделать?

в system.merge_tree_settings

кстати сейчас глянул, у 14 мутаций до сих пор is_done=0, месяц уже прошел

в system.merge_tree_settings

:) select * from system.merge_tree_settings; SELECT * FROM system.merge_tree_settings Received exception from server (version 18.6.0): Code: 60. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Table system.merge_tree_settings doesn't exist.. 0 rows in set. Elapsed: 0.207 sec.

Mikhail а оно должно работать с перекрестной репликацией? https://gist.github.com/tkroman/c36520132e56bf051975f7c92720cb37 вот таблицы селект с dpm=local: select id,day from ( select id from foo all inner join ( select day from bar ) using id ) стектрейс: 2018.09.21 12:45:50.797244 [ 167 ] {c7341b14-6c0d-4cb8-b63b-f43c52209465} <Debug> executeQuery: (from xxx:55758) select id,day from ( select id from foo all inner join ( select day from bar ) using id ) 2018.09.21 12:45:50.797608 [ 167 ] {c7341b14-6c0d-4cb8-b63b-f43c52209465} <Error> executeQuery: Code: 60, e.displayText() = DB::Exception: Table default.bar_replicated doesn't exist., e.what() = DB::Exception (from xxx:55758) (in query: select id,day from ( select id from foo all inner join ( select day from bar ) using id )), Stack trace:

:) select * from system.merge_tree_settings; SELECT * FROM system.merge_tree_settings Received exception from server (version 18.6.0): Code: 60. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Table system.merge_tree_settings doesn't exist.. 0 rows in set. Elapsed: 0.207 sec.

Таблица в более свежих версиях появилась

Надо будет настройки подаблично в system.tables добавить, сейчас просто emgine строкой хранится

то есть сейчас настройка не действует?

то есть сейчас настройка не действует?

Действует, просто настройки merge_tree как системную таблицу добавил недавно.

@den_crane у меня проблема в том, что шарды лежат в других базах и выходит, что почему-то движок не может понять, куда отправлять подзапрос. но при этом in работает, как ожидается

то есть в config.xml в секции remote_servers default-базы проставлены правильно

@den_crane у меня проблема в том, что шарды лежат в других базах и выходит, что почему-то движок не может понять, куда отправлять подзапрос. но при этом in работает, как ожидается

Не исключено что это баг.

@den_crane у меня проблема в том, что шарды лежат в других базах и выходит, что почему-то движок не может понять, куда отправлять подзапрос. но при этом in работает, как ожидается

А посмотрите на шардах - какой именно запрос присылвает distibuted.

Вроде по идее всё должно работать.

вот я уже даже саму на себя джойню: 2018.09.21 13:09:34.773358 [ 269715 ] {09125fe5-1504-4718-95f0-10c6bf93b6d8} <Debug> executeQuery: (from 10.8.0.174:55942) select foo,bar from tableA all inner join ( select foo from tableA where day = today() limit 1 ) using bar limit 1 2018.09.21 13:09:34.773751 [ 269715 ] {09125fe5-1504-4718-95f0-10c6bf93b6d8} <Error> executeQuery: Code: 60, e.displayText() = DB::Exception: Table default.tableA_replicated doesn't exist., e.what() = DB::Exception (from 10.8.0.174:55942) (in query: select foo,bar from tableA all inner join ( select foo from tableA where day = today() limit 1 ) using bar limit 1), Stack trace:

Ребят, друг ищет работу по профессии Senior C++ Developer (или TeamLead). Ни у кого случаем на работе вакансия не открыта ? ?

Ребят, друг ищет работу по профессии Senior C++ Developer (или TeamLead). Ни у кого случаем на работе вакансия не открыта ? ?

https://yandex.ru/jobs/vacancies/dev/dev_clickhouse/

https://yandex.ru/jobs/vacancies/dev/dev_clickhouse/

Иван, вы там же работаете ?)

Он по всем этим критериям подходит

Иван, вы там же работаете ?)

смотря что подразумевается под «там»

в яндекс)

да

О круто)

спасибо)

Ребятки, только не закидывайте меня тухлыми помидорами, для PBI пытаюсь настроить ClickHouse, подключался через питоновский модуль и через R studio, рефьюзит подключения, я правильно понимаю, чтобы подключаться извне, необходимо только users.xml прописать адреса с которых подключения разрешены?

нет

на сервере должен быть установлен odbc драйвер

если вы по odbc