но это изврат наверное какой-то

и распределенную не натянуть

Точно не уверен, что возможно. Попытаюсь уточнить. В любом случае, создавать надо 1 таблицу, а параметры реплики\шарда указывать в подствновке {shard} и {replica}, иначе что-то странное будет.

Спсб

Добавлю 4 сервер тогда и пока сделаю 2*2 Но очень хочется читать сразу с 4 а не с 2 как тут получится

дайте рецепт как на 3 серверах получить 3 шарды с 2 репликами для каждой

https://github.com/yandex/ClickHouse/tree/master/dbms/tests/integration/test_cross_replication

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

а бд указали в распределенной как '' и оно заработало? Спсб

а бд указали в распределенной как '' и оно заработало? Спсб

Да, у меня так срабатывало

Уря-уря

ушел все дропать

да, действительно, судя по тесту, я был неправ :)

!!! Спсб

Alex a вы случаем не знаете что с too many parts делать?

батчи до 1M увеличивать?

Все таки немног втранно что КХ ничего не делает при этом (при том что parts мержить надо)

Помнится была какая-то настроечка которую советовали увеличить в таких случаях.

background threads pool?

Поставил аж 64 - нифига

может магическое число 8192 увеличить

Только что ответил внутри, из-за чего может быть ошибка Too much parts. Скопирую сюда: Может быть несколько причин, почему такое происходит: 1. Данные не успевают мержатся, но всё-таки мержатся. Это будет видно по наличию большого количества одновременных мержей. Запрос SELECT * FROM system.merges, метрика ClickHouse.Metrics.Merge в Графите. В этом случае может помочь увеличение размера пачки. 2. Данные не мержатся из-за того, что превышено некоторое ограничение. В последней версии ограничение на суммарный размер кусков, которые можно мержить - 100 GB. На практике мы убедились, что это плохо - если за месяц больше 10 ТБ данных, то это приводит к тому, что есть несколько сотен кусков, которые не мержатся. Скоро увеличим по-умолчанию, а пока можно увеличить вручную - я скажу, как. Чтобы проверить - нужно посмотреть на размеры кусков: SELECT * FROM system.parts WHERE active 3. Данные не мержатся из-за бага. Суть в том, что среди реплик выбирается одна реплика-лидер, и именно она решает, какие мержи нужно делать. Раньше было много проблем - например, реплика-лидер могла отставать и не видеть куски для мержей. Или одна реплика могла уступить лидерство, а другая долго не брать его, из-за того, что это требует захвата некоторых блокировок. Все эти проблемы мы исправили и больше не наблюдали :) Но похожие вещи всё-равно могут быть. Чтобы проверить - надо посмотреть на число одновременных мержей, так же, как написано выше. Если мержей нет - значит подозрение на такую проблему.

Сейчас есть проблема, что при объёме данных больше 10 ТБ в месяц, куски плохо мержатся, из-за выставленных настроек по-умолчанию. Если это ваш случай, то можно прописать в config.xml в секции merge_tree, max_bytes_to_merge_at_max_space_in_pool побольше (по-умолчанию - 100 ГБ, можно увеличить до 500 ГБ, например).

background threads pool?

max_bytes_to_merge_at_max_space_in_pool

У меня похлже случай что merges пустая

и сервер простаивает

по крайней мере я много раз делал селект и в 50% случаях ничего не возвращалось

увеличу до 500000000000

ubuntu@pprod-spm-ch-3:~$ cat /etc/clickhouse-server/conf.d/remote_servers.xml <remote_servers> <metrics> <shard> <!— Optional. Wheight for writing. Default is 1. —> <weight>1</weight> <!— Optional. Write to only 1 replic?. By default, false - write to all replics. —> <internal_replication>true</internal_replication> <replica> <default_database>shard_1</default_database> <host>10.1.1.251</host> <port>9000</port> </replica> <replica> <default_database>shard_1</default_database> <host>10.1.1.86</host> <port>9000</port> </replica> </shard>

2017.08.02 11:48:11.231828 [ 35 ] <Error> HTTPHandler: Code: 170, e.displayText() = DB::Exception: Requested cluster 'metrics' not found, e.what() = DB::Exception, Stack trace:

Это после рестарта

я болван, пофиксил

Пересоздал как в рецепте на питоне с одтельными бд дла каждой шарды

все равно count пляшет ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 30670267 40000954 30670267 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 30670267 35331001 36669049 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 30670267 45999736 26000314 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 30670267 40000954 41339002 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 30670267 30670267 36669049 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 31003969 46332908 41672704

Что касается мержей то вот SELECT count(*) FROM system.parts ┌─count()─┐ │ 4117 │ └─────────┘ 1 rows in set. Elapsed: 0.014 sec. Processed 4.12 thousand rows, 805.87 KB (293.92 thousand rows/s., 57.53 MB/s.) :) select count(*) from system.merges; SELECT count(*) FROM system.merges ┌─count()─┐ │ 0 │ └─────────┘ 1 rows in set. Elapsed: 0.001 sec.

И кол-во частей растет

SELECT count(*) FROM system.parts WHERE active ┌─count()─┐ │ 2638 │ └─────────┘ 1 rows in set. Elapsed: 0.011 sec. Processed 2.64 thousand rows, 517.82 KB (245.53 thousand rows/s., 48.19 MB/s.)

Размеры кусков (часть небольшая) │ 238744 │ │ 150295 │ │ 45537 │ │ 1877 │ │ 3497620 │ │ 45097735 │ │ 100445291 │ │ 25183453 │ │ 24205009 │ │ 8025090 │ │ 2813436 │ │ 2776275 │ │ 640824 │ │ 2951712 │ │ 45963162 │ │ 103841374 │ │ 29787212 │ │ 35136577 │ │ 670064 │ │ 661817 │ │ 694306 │ │ 675514 │ │ 675479 │ │ 1969 │ │ 1659 │ │ 1482 │ │ 1385 │ │ 1635 │ │ 1326 │ │ 1641 │

SELECT bytes FROM system.parts WHERE active ORDER BY bytes DESC LIMIT 20 ┌─────bytes─┐ │ 103841374 │ │ 100445291 │ │ 45963162 │ │ 45097735 │ │ 35136577 │ │ 29787212 │ │ 27960524 │ │ 25183453 │ │ 24205009 │ │ 21057918 │ │ 18070983 │ │ 10042797 │ │ 6931969 │ │ 3497620 │ │ 3056593 │ │ 2951712 │ │ 2716754 │ │ 757982 │ │ 757828 │ │ 748188 │ └───────────┘

SELECT count(*) FROM system.parts WHERE active ┌─count()─┐ │ 2638 │ └─────────┘ 1 rows in set. Elapsed: 0.011 sec. Processed 2.64 thousand rows, 517.82 KB (245.53 thousand rows/s., 48.19 MB/s.)

Кол-во parts уменьшается, значит мерджы идут

cначала они и вчера шли

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

а потом через 3-4 часа

когда колво достигло около 20000 все заглохло

Давайте останавлю вставку и проверим через минуту

когда колво достигло около 20000 все заглохло

Значит фоновые мерджи, при ваших настройках, закончились. Это штатное поведение

Коллеги, всем привет. Получается, что нельзя использовать условные операторы https://clickhouse.yandex/docs/ru/functions/conditional_functions.html?highlight=%D1%83%D1%81%D0%BB%D0%BE%D0%B2%D0%BD%D1%8B%D0%B9 с NamedParameterJdbcTemplate я когда написал в запросе (model_id != 0 ? model_id : cluster_id) AS model_id, у меня возникла бага org.springframework.dao.InvalidDataAccessApiUsageException: Not allowed to mix named and traditional ? placeholders. You have 2 named parameter(s) and 2 traditional placeholder(s) in statement

штатное поведение когда ничего не вставляет потому как пишет что много частей и при этом процессор ничего не делает (см картинку выше)?

Коллеги, всем привет. Получается, что нельзя использовать условные операторы https://clickhouse.yandex/docs/ru/functions/conditional_functions.html?highlight=%D1%83%D1%81%D0%BB%D0%BE%D0%B2%D0%BD%D1%8B%D0%B9 с NamedParameterJdbcTemplate я когда написал в запросе (model_id != 0 ? model_id : cluster_id) AS model_id, у меня возникла бага org.springframework.dao.InvalidDataAccessApiUsageException: Not allowed to mix named and traditional ? placeholders. You have 2 named parameter(s) and 2 traditional placeholder(s) in statement

Можно писать if(cond, then, else) и тогда такого не будет

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

ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 197847333 265166333 197847333 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 257339801 142501192 209820192 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 197847333 209820192 257339801 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 257339801 257339801 205673865

а норм

сча напишу

штатное поведение когда ничего не вставляет потому как пишет что много частей и при этом процессор ничего не делает (см картинку выше)?

По моему опыту, если писать большими пачками, в один поток - всё нормально мерджиться. Ждать минуту - мало, поскольку примерный интервал старта меджей - 8-10 минут. При этом все не мерджиться. Т.е. процесс мерджей - дело не 1-2 минут

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

тоесть пока идут мержи возвращать неправильные данные это штатное поведение?

Я обычно по iotop смотрю что мерджи идут

Так мержи это второй вопрос

самое главное что count разное возвращает

ubuntu@pprod-spm-ch-3:~$ for i in seq 1 5; do curl 'pprod-spm-ch-3:8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 202826595 209820192 143334127 150327724 259506058

SELECT count(*) FROM default.Measures_Distributed ┌───count()─┐ │ 207007187 │ └───────────┘ 1 rows in set. Elapsed: 0.073 sec. Processed 207.01 million rows, 414.01 MB (2.84 billion rows/s., 5.67 GB/s.) :) select count(*) from default.Measures_Distributed; SELECT count(*) FROM default.Measures_Distributed ┌───count()─┐ │ 259839933 │ └───────────┘ 1 rows in set. Elapsed: 0.333 sec. Processed 259.84 million rows, 519.68 MB (781.28 million rows/s., 1.56 GB/s.) :) select count(*) from default.Measures_Distributed; SELECT count(*) FROM default.Measures_Distributed ┌───count()─┐ │ 200347465 │ └───────────┘ 1 rows in set. Elapsed: 0.374 sec. Processed 200.35 million rows, 400.69 MB (536.11 million rows/s., 1.07 GB/s.)

это как понимать?

самое главное что count разное возвращает

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

Vladimir а из локальных таблиц значения стабильные?

сек

В локальных таблицах все стабильно

но по репликам данные не совпадают

ERROR: S client not available

и вот такое есть

SELECT * FROM system.replicas FORMAT Vertical Row 1: ────── database: shard_1 table: Measures engine: ReplicatedMergeTree is_leader: 0 is_readonly: 0 is_session_expired: 0 future_parts: 2 parts_to_check: 0 zookeeper_path: /clickhouse/tables/measures/01 replica_name: 1 replica_path: /clickhouse/tables/measures/01/replicas/1 columns_version: 0 queue_size: 6471 inserts_in_queue: 5087 merges_in_queue: 1384 queue_oldest_time: 2017-08-02 12:04:23 inserts_oldest_time: 2017-08-02 12:04:23 merges_oldest_time: 2017-08-02 12:06:45 oldest_part_to_get: 20161013_20161013_3_3_0 oldest_part_to_merge_to: 20160727_20160727_4_103_1 log_max_index: 9997 log_pointer: 9998 last_queue_update: 2017-08-02 12:26:00 absolute_delay: 1343 total_replicas: 2 active_replicas: 2

absolute_delay: 1343 » это в каких единицах?

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

Неужели за 10 мин вставки так расколбасило.

absolute_delay: 1554 Увеличивается, хотя я с кластером вообще ничего не делаю сейчас

SELECT count(*) FROM system.parts AS active ┌─count()─┐ │ 7816 │ └─────────┘ 1 rows in set. Elapsed: 0.033 sec. Processed 7.82 thousand rows, 1.54 MB (237.76 thousand rows/s., 46.76 MB/s.) :) select * from system.merges; SELECT * FROM system.merges Ok. 0 rows in set. Elapsed: 0.001 sec. :)

Мержей нет

Parts дофига

Приехали...

Vladimir а 7816 кусков за какое время набралось?

то есть в какой момент их было 0?

10 мин

10 мин

то есть за 10 минут было 7816 инсертов (минимум)?

13 в секунду в среднем

absolute_delay: 1343 » это в каких единицах?

тут нет описание https://clickhouse.yandex/docs/ru/system_tables/system.replicas.html По коду либо милисекунды, либо секунды

не считая то что таки смержилось

то есть за 10 минут было 7816 инсертов (минимум)?

Это плохо, CH становиться плохо при таком кол-ве инсертов

2017-08-02 12:14:04,683 INFO [CHRawDataPullerThread_0] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_0: Inserted 500005 docs into store 2017-08-02 12:14:04,706 INFO [CHRawDataPullerThread_5] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_5: Inserted 500003 docs into store 2017-08-02 12:14:04,867 INFO [CHRawDataPullerThread_6] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_6: Inserted 500000 docs into store 2017-08-02 12:14:06,182 INFO [CHRawDataPullerThread_2] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_2: Inserted 500007 docs into store 2017-08-02 12:14:07,362 INFO [CHRawDataPullerThread_4] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_4: Inserted 500003 docs into store 2017-08-02 12:14:07,400 INFO [CHRawDataPullerThread_8] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_8: Inserted 500006 docs into store 2017-08-02 12:14:08,967 INFO [CHRawDataPullerThread_7] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_7: Inserted 500000 docs into store 2017-08-02 12:14:10,025 INFO [CHRawDataPullerThread_3] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_3: Inserted 500012 docs into store 2017-08-02 12:14:12,184 INFO [CHRawDataPullerThread_1] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_1: Inserted 500002 docs into store 2017-08-02 12:14:12,699 INFO [CHRawDataPullerThread_5] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_5: Inserted 500000 docs into store 2017-08-02 12:14:12,709 INFO [CHRawDataPullerThread_0] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_0: Inserted 500004 docs into store 2017-08-02 12:14:13,012 INFO [CHRawDataPullerThread_6] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_6: Inserted 500000 docs into store 2017-08-02 12:14:14,096 INFO [CHRawDataPullerThread_2] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_2: Inserted 500003 docs into store 2017-08-02 12:14:14,915 INFO [CHRawDataPullerThread_4] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_4: Inserted 500013 docs into store 2017-08-02 12:14:15,618 INFO [CHRawDataPullerThread_8] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_8: Inserted 500002 docs into store 2017-08-02 12:14:16,807 INFO [CHRawDataPullerThread_7] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_7: Inserted 500004 docs into store 2017-08-02 12:14:18,303 INFO [CHRawDataPullerThread_3] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_3: Inserted 500011 docs into store

Вот лог встявлятеля

вставляет пачки по 500к

тут нет описание https://clickhouse.yandex/docs/ru/system_tables/system.replicas.html По коду либо милисекунды, либо секунды

посмотрел по коду, там секунды

вот встявляло

не 10 мин, больше

2017-08-02 12:14:04,683 INFO [CHRawDataPullerThread_0] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_0: Inserted 500005 docs into store 2017-08-02 12:14:04,706 INFO [CHRawDataPullerThread_5] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_5: Inserted 500003 docs into store 2017-08-02 12:14:04,867 INFO [CHRawDataPullerThread_6] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_6: Inserted 500000 docs into store 2017-08-02 12:14:06,182 INFO [CHRawDataPullerThread_2] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_2: Inserted 500007 docs into store 2017-08-02 12:14:07,362 INFO [CHRawDataPullerThread_4] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_4: Inserted 500003 docs into store 2017-08-02 12:14:07,400 INFO [CHRawDataPullerThread_8] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_8: Inserted 500006 docs into store 2017-08-02 12:14:08,967 INFO [CHRawDataPullerThread_7] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_7: Inserted 500000 docs into store 2017-08-02 12:14:10,025 INFO [CHRawDataPullerThread_3] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_3: Inserted 500012 docs into store 2017-08-02 12:14:12,184 INFO [CHRawDataPullerThread_1] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_1: Inserted 500002 docs into store 2017-08-02 12:14:12,699 INFO [CHRawDataPullerThread_5] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_5: Inserted 500000 docs into store 2017-08-02 12:14:12,709 INFO [CHRawDataPullerThread_0] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_0: Inserted 500004 docs into store 2017-08-02 12:14:13,012 INFO [CHRawDataPullerThread_6] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_6: Inserted 500000 docs into store 2017-08-02 12:14:14,096 INFO [CHRawDataPullerThread_2] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_2: Inserted 500003 docs into store 2017-08-02 12:14:14,915 INFO [CHRawDataPullerThread_4] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_4: Inserted 500013 docs into store 2017-08-02 12:14:15,618 INFO [CHRawDataPullerThread_8] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_8: Inserted 500002 docs into store 2017-08-02 12:14:16,807 INFO [CHRawDataPullerThread_7] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_7: Inserted 500004 docs into store 2017-08-02 12:14:18,303 INFO [CHRawDataPullerThread_3] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_3: Inserted 500011 docs into store

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

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

тут вопрос что не видно куда упирается КХ

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

Всё равно нужно через некий батчер группировать данные и делать одни запрос

тут вопрос что не видно куда упирается КХ

Упирает в то, что слишком много одновременных вставок. Так делать не советуют, лучше одну большую, чем несколько маленьких

5-6 в секунду не выглядит критическим

ок