а новая колонка - нет

если не добавить вот этот странный AND TS > '2018-08-08 00:00:00'

в * новая колонка (IPNet) есть? ну и используйте это как воркэраунд

у себя-то я и грохнуть могу нафиг эти таблицы, а не заморачиваться альтером

но вот пользователи не поймут-с

я думаю проще можно 1. optimize final все пофиксит или 2. выбирайте IPNet,date

Робяты, вопрос. Как может так оказаться, что при создании таблицы с таким движком, в ней хранится две записи.

replacing не гарантирует отсуствие дубликатов, они МОГУТ схлопываться в будущем при мерже. optimize final инициирует мерж и МОЖЕТ схлопнуть select from table final выбирает без дубликатов (но работает до 1000 раз медленнее) version -- не обязателен, КХ сам сэмулирует это поле. схлопывание работает только в рамках партиции create table y(a Int64, b Int64, z Date) engine = ReplacingMergeTree partition by (a,z) order by b; insert into y select 1,1, toDate('2018-01-01') from numbers(1); insert into y select 2,1, toDate('2018-02-01') from numbers(1); optimize table y final; select count() cnt from y cnt 2 select count() cnt from y final cnt 1

я думаю проще можно 1. optimize final все пофиксит или 2. выбирайте IPNet,date

optimize не пофиксил

второй способ тоже не помог

какая версия КХ? как делали optimize ?

select * возвращает новое поле ?

select * возвращает

optimize делал без final, сейчас пробую с final

да, после этого заработало

select * возвращает

да забавно, надо другую колонку добавлять (которая не в prewhere), чтобы не было экспепшина select c,d,z from y prewhere a <1000 -- работает select c,d,a from y prewhere a <1000 -- не работает

да, после этого заработало

final просто создал эту колонку для старых строк, естественно перезапишутся все 100 тыщ миллиардов строк, поэтому не всегда возможно это.

final просто создал эту колонку для старых строк, естественно перезапишутся все 100 тыщ миллиардов строк, поэтому не всегда возможно это.

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

а что у кого-то были сомнения?

SELECT dictGetUInt64('urls', 'project_id', toUInt64(pid)) FROM тра-та-та.... ↘️ Progress: 3.54 million rows, 159.72 MB (3.40 million rows/s., 153.57 MB/s.) 66%Received exception from server (version 1.1.54385): Code: 69. DB::Exception: Received from ...... DB::Exception: urls: identifier should be less than 500000. Подскажите, как бороться?

поменяйте тип источника на flat

в конфиге словаря

hashed нельзя использовать, если есть записи с идентификатором > 500000

Только наоборот :)

ну да, попутал :)

Да, уже нашел, спасибо!

Всем привет! Вырос на кластере резко compressed read buffer - https://yadi.sk/i/PVYBui073a3LWz - стали дольше работать основные запросы, хотя обрабатываемая память сиильно не увеличилась - это же не похоже на сложные запросы? Может кто сталкивался?

В логах ошибки вида ServerErrorHandler: Code: 210, e.displayText() = DB::NetException: Connection reset by peer: while reading from socket

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

Ошибка не уходит и повторяется 5-10 раз в секунду. На 2м сервере в логе при этом: [ 16 ] <Error> default.graphite (StorageReplicatedMergeTree): Code: 40, e.displayText() = DB::Exception: Checksums of parts don't match: hash of uncompressed files doesn't match, uncompressed hash of compressed files doesn't match, e.what() = DB::Exception. Data after merge is not byte-identical to data on another replicas. There could be several reasons: 1. Using newer version of compression library after server update. 2. Using another compression method. 3. Non-deterministic compression algorithm (highly unlikely). 4. Non-deterministic merge algorithm due to logical error in code. 5. Data corruption in memory due to bug in code. 6. Data corruption in memory due to hardware issue. 7. Manual modification of source data after server startup. 8. Manual modification of checksums stored in ZooKeeper. We will download merged part from replica to force byte-identical result. Как валидно дропнуть эту реплику и перезалить с 1го, без смены ID реплики?

поискать по слову force в документации, там было про файловый флаг, после выставления которого идёт перезалитие

я дропнул таблицу на 2м, пересоздал и пошла реплика.

Ещё вопрос, если меняется схема прореживания (graphite_rollup) в конфиге, нужно менять и перезагружать сервер на всех репликах и максимально синхронно, так?

Остановил 2й сервер, так как реплика с 1го отняла все ресурсы(LoadAverage подскочил вдвое больше числа), и на 1м в логах пошли: <Error> executeQuery: Code: 252, e.displayText() = DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts., e.what() = DB::Exception (from 127.0.0.1:57754) Прошло полчаса без нагрузки, а первый ни строчки не вставил, и все пишет <Error> executeQuery: Code: 252, e.displayText() = DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts., e.what() = DB::Exception (from 127.0.0.1:57754)

Остановил 2й сервер, так как реплика с 1го отняла все ресурсы(LoadAverage подскочил вдвое больше числа), и на 1м в логах пошли: <Error> executeQuery: Code: 252, e.displayText() = DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts., e.what() = DB::Exception (from 127.0.0.1:57754) Прошло полчаса без нагрузки, а первый ни строчки не вставил, и все пишет <Error> executeQuery: Code: 252, e.displayText() = DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts., e.what() = DB::Exception (from 127.0.0.1:57754)

А откуда у вас столько партов? Надо наверно сперва решить с этим вопрос

Обычно в него пишется несколько Миллионов метрик в минуту, сейчас около 200 метрик

ни один файл из carbon-clickhouse не удалился

а сколько должно быть, я искад по данной ошибке, и у других не 300

carbon-clickhouse вставляет каждые 10 секунд

то есть примерно по 600к записей за раз

@stufently Я так понимаю, таких ошибок не должно быть, когда с сервера льется реплика на новый(объем данных около 2 ТБ)

Если у вас это на пустой реплике то ощущение что настройки или версии кх у вас разные

Если на обоих одно и тоже то такие ошибки должны быть везде

2я реплика остановлена сейчас, 1я тормозит и сыплет ошибками, процессоры загружены на 50-80%, вставка не идет

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

а что по конфигу сервера для реплики ?

конфиг одинаковый, как узнать ,ч тосейчас делает сервер? в мерджах ничего

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

конфиг одинаковый, как узнать ,ч тосейчас делает сервер? в мерджах ничего

посмотреть в логе кх

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

в каталоге данных нет ни мерджей ни инзертов

ну тогда смотрите логи

странно что нет данных так как оно начинается сразу

2й сервер поднялся кроном, остановил и все пошло, 1й отстал со вставкой на 1 час, сейчас наверстывает. @stufently Спасибо за помощь

@stufently не подскажешь, от чего зависит быстродействие КХ? сейчас он вставляет в 1,5 раза(25М строк вместо 16М) больше данных чем обычно(данных накопилось на 1 час), хотя ранее при испытаниях(когда останавливал сервер и потом вставлялось из carbon-clickhouse) была скорость 3-5 раз(до 80М строк вместо 15М), процессоры заняты слабо(220% из 40 ядер), диски(ССД) отдыхают, памяти 100Г из 120Г свободно

может подять <background_pool_size>50 <background_schedule_pool_size>24 ?

А есть ошибкт в еррор логе?

Вообще особого смысла ложить кх на такие супер толстые сервера не вижу

2018.08.09 08:43:25.003270 [ 57 ] <Warning> default.graphite (ReplicatedMergeTreePartCheckThread): Checking if anyone has a part covering 20180708_20180731_711637_711662_11. 2018.08.09 08:43:25.004147 [ 57 ] <Warning> default.graphite (ReplicatedMergeTreePartCheckThread): Found parts with the same min block and with the same max block as the missing part 20180708_20180731_711637_711662_11. Hoping that it will eventually appear as a result of a merge. 2018.08.09 08:44:01.864955 [ 49 ] <Error> default.graphite (StorageReplicatedMergeTree): Code: 228, e.displayText() = DB::Exception: Unexpected uncompressed size of file Date.bin in data part, e.what() = DB::Exception. Data after merge is not byte-identical to data on another replicas. There could be several reasons: 1. Using newer version of compression library after server update. 2. Using another compression method. 3. Non-deterministic compression algorithm (highly unlikely). 4. Non-deterministic merge algorithm due to logical error in code. 5. Data corruption in memory due to bug in code. 6. Data corruption in memory due to hardware issue. 7. Manual modification of source data after server startup. 8. Manual modification of checksums stored in ZooKeeper. We will download merged part from replica to force byte-identical result. 2018.08.09 08:44:01.865692 [ 111 ] <Warning> default.graphite (ReplicatedMergeTreePartCheckThread): Checking part 20180708_20180731_711637_711662_11 2018.08.09 08:44:01.865950 [ 111 ] <Warning> default.graphite (ReplicatedMergeTreePartCheckThread): Checking if anyone has a part covering 20180708_20180731_711637_711662_11. 2018.08.09 08:44:01.866669 [ 111 ] <Warning> default.graphite (ReplicatedMergeTreePartCheckThread): Found parts with the same min block and with the same max block as the missing part 20180708_20180731_711637_711662_11. Hoping that it will eventually appear as a result of a merge. 2018.08.09 08:44:39.522705 [ 43 ] <Error> default.graphite (StorageReplicatedMergeTree): Code: 228, e.displayText() = DB::Exception: Unexpected uncompressed size of file Date.bin in data part, e.what() = DB::Exception. Data after merge is not byte-identical to data on another replicas. There could be several reasons: 1. Using newer version of compression library after server update. 2. Using another compression method. 3. Non-deterministic compression algorithm (highly unlikely). 4. Non-deterministic merge algorithm due to logical error in code. 5. Data corruption in memory due to bug in code. 6. Data corruption in memory due to hardware issue. 7. Manual modification of source data after server startup. 8. Manual modification of checksums stored in ZooKeeper. We will download merged part from replica to force byte-identical result. 2018.08.09 08:44:39.531295 [ 112 ] <Warning> default.graphite (ReplicatedMergeTreePartCheckThread): Checking part 20180708_20180731_711637_711662_11 2018.08.09 08:44:39.531490 [ 112 ] <Warning> default.graphite (ReplicatedMergeTreePartCheckThread): Checking if anyone has a part covering 20180708_20180731_711637_711662_11. 2018.08.09 08:44:39.532384 [ 112 ] <Warning> default.graphite (ReplicatedMergeTreePartCheckThread): Found parts with the same min block and with the same max block as the missing part 20180708_20180731_711637_711662_11. Hoping that it will eventually appear as a result of a merge.

сервер достался от графита(go-carbon)

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

мусор, думаю, от 3й реплики, которая сейчас также остановлена

как-то можно ускорить КХ?

ресурсов не ест, ощущение, что он однопоточный, ядро занято мерджами и ядро инзертами, итого 2 ядра из 40

Вообще надо было раскидать шарды по серверам попроще наверно

У нас вообще под кх изначально было 2 ядра 8 гигов оперативны

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

сервер и нагрузка с текущего графита, что ограничивает скорость мерджей, настройки выше не помогут?

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

Ну и вставки можно переносить между шардами если есть какие то проблемы

когда читаешь с КХ то он утилизирует до 30 ядер и все ок, сейчас без чтения только вставка и оч медленно

когда читаешь с КХ то он утилизирует до 30 ядер и все ок, сейчас без чтения только вставка и оч медленно

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

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

?

@milovidov_an Привет. Есть догадки, почему вставка замдлилась?

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

как это сделать? сейчас один диск из 10 на 35% занят вот и вся нагрузка

Читал это : https://github.com/yandex/ClickHouse/issues/1510 у нас 1.1.54390

как это сделать? сейчас один диск из 10 на 35% занят вот и вся нагрузка

ну ошибку поискать в логе в текстовом просмотрщике или грепом

сейчас нет ошибок, кроме мусора в зукипере

МБ есть какая-то версия, которая точно стабильная? @stufently у вас какая ?

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

у меня 1.1.54370

Читал это : https://github.com/yandex/ClickHouse/issues/1510 у нас 1.1.54390

эта проблема давно пофикшена , 300 партов и нельзя писать это не баг это как бы фича настраиваемая

как настроить, что бы не останавливались инзерты при нагрузке?

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

но опять таки в миллион их не стоит поднимать это скажется на перфомансе

удвоил background_pool_size до 100 , перезагрузил, смотрю

судя по метрике insertedRows, не помогло @stufently не так увеличивать партишены?

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

удвоил background_pool_size до 100 , перезагрузил, смотрю

Вы так только память всю съедите.

Памяти 100Г из 120 своюодно, КХ ест 4-5Г

как распараллелить вставки/мерджи, сейчас ровно 2 ядра заняты

в исходниках нашел: /** If more than this number active parts, throw 'Too many parts ...' exception */ \ M(SettingUInt64, parts_to_throw_insert, 300)

Что там в select * system.merges ? Он еще может немержить из-за проблем с репликацией select * from system.replication_queue

Не надо их выше поднимать

вот, сейчас вижу мердж: :) select progress from system.merges; SELECT progress FROM system.merges ┌────────────progress─┐ │ 0.10913025462625675 │