Т.е. партиции большие :)

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

2018.08.24 14:33:31.626870 [ 2 ] <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.

тут даже имя столбца есть

да, майские-илюские по 100-200Г, август около 1ТБ

@mfilimonov что ещё можно сделать?

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

Я немного запутался. На том сервере куда льёте - все в порядке?

Только на реплике проблемы? Только для одного куска или разных?

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

Спасибо! А то я уж испугался, что появилось какая-то новая сущность, а не в курсе)

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

"сейчас было да" - это многое объясняет :P (простите, пятница :) )

@mfilimonov если подождать, на обоих(доноре и приемнике) такие ошибки, потом добавляется , что слишком много инзеертов и они не поспевают за мерджами и останавливается вставка, а не успевает, так как на обоих по 10-30 мерджей, котрые вливают данные и удаляют и так постоянно

"сейчас было да" - это многое объясняет :P (простите, пятница :) )

В последний раз, после перезагрузки всех серверов и проверки, что у всех чексума новых частей с версией4

Уточню - льёте данные в одну машину ("донор") вторая - просто "пассивная" реплика ("приёмник")?

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

так вот, все ломалось, когда лил: server1 -> server2 server1 -> VM1 server2 -> server1 сейчас льется server2 -> VM1 и ошибок пока нет. Похоже, проблема в сервере1

да

Вадим, Вы несколько сумбурно объясняте (или я несколько сумбурно понимаю) :)

Перечитаю с начала.

есть 3 сервера: сервер2(вставляет данные из carbon-clickhouse) - донор виртуалка - приемник, на нее льется релика и ошибок нет

сервер1 - приемник, как только включаю реплику на него, вижу ошибки чексум

кусок - это не то же самое, что partition

Alexey Sheglov: Detach partition, убрать это кусок, и attach partition Я в курсе, после детач идти в папку detached, и убрать с диска корявый кусок, а потом партицию обратно приаттачить

Например sudo memtester 2048 5

Пока что: # memtester 100000 5 memtester version 4.2.0 (64-bit) Copyright (C) 2010 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xfffffffffffff000 want 100000MB (104857600000 bytes) got 100000MB (104857600000 bytes), trying mlock ...locked. Loop 1/5: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : testing 21

Alexey Sheglov: Detach partition, убрать это кусок, и attach partition Я в курсе, после детач идти в папку detached, и убрать с диска корявый кусок, а потом партицию обратно приаттачить

Так это партиция, заполняемая в текущий момент. Что будет при попытке такую "от-атачить"или "при-атачить"?

Так это партиция, заполняемая в текущий момент. Что будет при попытке такую "от-атачить"или "при-атачить"?

Будет поставлен лок и запрос будет ждать

Так это партиция, заполняемая в текущий момент. Что будет при попытке такую "от-атачить"или "при-атачить"?

А остановить запись на минутку?

есть 3 сервера: сервер2(вставляет данные из carbon-clickhouse) - донор виртуалка - приемник, на нее льется релика и ошибок нет

Т.е. на 2-х из 3-х все ОК?

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

Пока что: # memtester 100000 5 memtester version 4.2.0 (64-bit) Copyright (C) 2010 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xfffffffffffff000 want 100000MB (104857600000 bytes) got 100000MB (104857600000 bytes), trying mlock ...locked. Loop 1/5: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : testing 21

Ещё глупый вопрос: КХ Вы не сами собирали?

нет, из пакета

$ rpm -qa |grep clickhouse clickhouse-client-18.6.0-1.el7.x86_64 clickhouse-common-static-18.6.0-1.el7.x86_64 graphite-clickhouse-0.4.2-1.x86_64 clickhouse-server-common-18.6.0-1.el7.x86_64 carbon-clickhouse-0.6.3-1.x86_64 clickhouse-server-18.6.0-1.el7.x86_64

И SELECT version(); тоже ту же самую версию показывает?

Если rpm - то это сборка altinity?

И ещё раз - у вас сейчас есть данные в нерплицируемой таблице (MergeTree) и вы пробуете из этой нереплицируемой таблицы перенести данные в реплицируемую? Как? INSERT ... SELECT или DETACH / ATTACH?

Кто-нибудь знает, можно ли с помощью nginx настроить балансировку ClickHouse перенаправляя на 9000 порт, а не на 8123 ?

у нас API общается с clickhouse через 9000 порт

через tcp

Кто-нибудь знает, можно ли с помощью nginx настроить балансировку ClickHouse перенаправляя на 9000 порт, а не на 8123 ?

nginx -это веб сервер, который умеет только "http" протокол. На 9000 - протокол бинарный, не http.

Для этого вам не nginx нужен.

А что ?

что то я не смог найти в гугле решения

может тут кто подскажет

И SELECT version(); тоже ту же самую версию показывает?

$ clickhouse-client ClickHouse client version 18.6.0. Connecting to localhost:9000 as user default. Connected to ClickHouse server version 18.6.0 revision 54401. :) SELECT version(); SELECT version() ┌─version()─┐ │ 18.6.0 │ └───────────┘ 1 rows in set. Elapsed: 0.007 sec. :)

из локальной копировал insert ... select

nginx -это веб сервер, который умеет только "http" протокол. На 9000 - протокол бинарный, не http.

Nginx уже умеет tcp раскидывать

Nginx уже умеет tcp раскидывать

что то не получается

попробовал

уже два часа и так и сяк

не хочет

ищу альтернативные решения

Nginx уже умеет tcp раскидывать

угу. Сейчас прочитал и удивился.

HAProxy удобнее и проще

Для tcp

ищу альтернативные решения

haproxy например

ищу альтернативные решения

chproxy, haproxy

@mfilimonov @kshvakov спасибо за совет ребят ! Попробую, результат отпишу =)

из локальной копировал insert ... select

А пробовали так: https://clickhouse.yandex/docs/ru/operations/table_engines/replication/#mergetree-replicatedmergetree ?

Это обычно быстрее чем INSERT ... SELECT.

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

да, но так перекидываются бинарные данные, а они пока 100% приводят к ошибкам, я думал данные битые, перевставил через INSERT ... SELECT

Если проблем нет - то пробовать добавить следующий сервер.

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

вот лью сегодня реплику на виртуалку несколько часов, все ок, ошибок нет, добавляю на сервере1 реплицируемую таблицу - везде ошибки

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

нет, структура не менялась

нет, структура не менялась

И стобцы не чистили например через ALTER TABLE ... CLEAR COLUMN ?

словарей не использую, схема стандартная , отсюда:https://github.com/lomik/carbon-clickhouse, позже добавилась репликация

А если сделать примитивную таблицу типа CREATE TABLE replication_test Engine=ReplicatedMergeTree( ... ) ... AS SELECT * FROM numbers(100000).

?

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

А если сделать примитивную таблицу типа CREATE TABLE replication_test Engine=ReplicatedMergeTree( ... ) ... AS SELECT * FROM numbers(100000).

на всех?

Сначала на одном. Потом на остальных.

Посмотреть - будет ли что-то сыпаться.

Кстати carbon-clickhouse похоже использует GraphiteMergeTree.

есть таблица созданная так: CREATE TABLE graphite_tree( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32)ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/{shard}/graphite_tree', '{replica}', Date, (Level, Path), 8192, Version); и сней все ок, на ней и смотрел версию чексум, но в ней записей всего 18-20М

Конфигурация везде одинаковая?

В смысле конфигурация графита.

В config.xml

да, я так создаю таблицу: CREATE TABLE graphite ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32)ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/{shard}/graphite', '{replica}', Date, (Path, Time), 32768, 'graphite_rollup');

да, все одинаково в конфиге, кроме имени сервера

Секция <graphite_rollup>

в config.xml

одинаковая?

И пока сервер в кластере один - проблем не возникает?

да

одинаковая?

Diff ругнулсф на некоторые строки, хотя свиду различий нет, сейчас засинкаю

@mfilimonov @kshvakov спасибо за совет ребят ! Попробую, результат отпишу =)

Понял почему через nginx не работает по умолчанию. Чтобы nginx умел tcp нужно собрать nginx из исходников с ключом --with-stream либо приобрести платную версию nginx plus в которой уже включен данный модуль.

Diff ругнулсф на некоторые строки, хотя свиду различий нет, сейчас засинкаю

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

засинкал конфиги, стартовал реплику

пока все ок

пока все ок

Ок. Может в этом дело. С разными конфигами - может по-разному схлопывать строки во время мерджа кусков. Тогда будут разные куски на разных серверах получаться, и их чексуммы не будут совпадать.

Все работает! Спасибо, парни.

Добрый день. Я ведь могу в качестве движка materialized view использовать merge tree (не aggregation) ? Мне не нужно группировать, просто иметь вьюху по фильтру по сути

да, можете (можно даже написать ... to some_distributed_table)

Благодарю вас

Ребят. Ситуация: есть много файлов с данными, которые превышают max_insert_block_size и соответственно CH бьет это дело на разные блоки в соответствии с этой настройкой. И вот у меня данных на 3 блока, один блок вставился на в середине второго блока нашлась ошибка в данных и запрос упал. В CH осталась первый блок данных, но мне нужно: либо записалось все, либо ничего. Как такого можно достичь? Кто-то сталкивался с подобной потребностью?

переразбить файлы?

А как я узнаю сколько блоков у меня успешно записалось, а сколько нет?