так тут как раз в перфе будет хорошо видно HLL* функции

Короче если кто то еще нактнется на проблему что репликация не работает, и видит ошибки типа: DB::Exception: No interserver IO endpoint named DataPartsExchange DB::StorageReplicatedMergeTree::queueTask() DB::Exception: Cannot read all data. Решение простое: Выключайте сервера ClickHouse. в /etc/clickhouse-server/config.xml на серверах пропишете следующую строку: <interserver_http_host>this_server_hostname</interserver_http_host> где вместо this_server_hostname напишите реальное имя хоста. Например если у вас есть два сервера которые называются server_1 и server_2 То соостветственно на первом сервере в конфиге пишите: <interserver_http_host>server_1</interserver_http_host> На втором сервере в конфиге пропишите: <interserver_http_host>server_2</interserver_http_host> на обоих серверах в /etc/hosts добавьте строки типа: 192.168.1.10 server_1 192.168.1.11 server_2 чтобы реальные hostname соотвествовали реальным ip адресам. Включите сервера ClickHouse. Теперь проверим что все работает. Создаем на обоих серверах ReplicatedMergeTree таблицу и на одном из серверов производим наполнение в нашу таблицу. После чего проверяем что на втором сервере в таблице появилась информация тоже. На всякий случай напишу, что если у вас все равно останутся такие же ошибки, попробуйте заменить все ip адреса упоминающиеся в файле /etc/clickhouse/config.xml на доменные имена. После чего не забудьте прописать все что нужно в /etc/hosts. #инструкция #manual #решение проблемы #настройка репликации #репликация

я к тому, что у меня вообще нет такой настройки и, тфу тфу, всё работает как часы

Короче как только заменил все ip адреса в config.xml на имена, прописал соответствие имен ip адресам в /etc/hosts на обоих нодах, перезапустил сервера, и создал новые реплицируемые таблицы - все завелось. правда пока не понял, в каком месте замена ip адреса на имя помогла... буду методом тыка сейчас проверять, чтобы отловить момент.

репликация по http?

вот только как скачать билд для 1.8 пока не понял, на крайняк буду осваивать mvn, но если кто занет, то поделитесь инфой плз

слишком много листен хостов )))

Привет. После обновления кластера до актуальной версии на одной из реплик появилась проблема с мерджем очень старых данных. Мердж идет, в итоге возникает ошибка - и он повторяется заново, в цикле. Почему-то с другой реплики этот part не скачивается. На второй реплике этого шарда никаких проблем нет. 2018.08.03 16:56:02.583570 [ 12 ] <Error> SrcData.TTStatBase (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. Вот выдержка из лога по этому треду. 2018.08.03 16:56:02.352540 [ 12 ] <Debug> SrcData.TTStatBase (MergerMutator): Merge sorted 118552713 rows, containing 166 columns (6 merged, 160 gathered) in 234.24 sec., 506113.87 rows/sec., 649.20 MB/sec. 2018.08.03 16:56:02.356438 [ 12 ] <Trace> SrcData.TTStatBase (Data): Renaming temporary part tmp_merge_201709_63076_64611_5 to 201709_63076_64611_5. 2018.08.03 16:56:02.356510 [ 12 ] <Trace> SrcData.TTStatBase (MergerMutator): Merged 3 parts: from 201709_63076_63675_4 to 201709_64197_64611_4 2018.08.03 16:56:02.583501 [ 12 ] <Debug> SrcData.TTStatBase (Data): Undoing transaction. Removing parts: 201709_63076_64611_5. 2018.08.03 16:56:02.583570 [ 12 ] <Error> SrcData.TTStatBase (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. 2018.08.03 16:56:02.583670 [ 12 ] <Debug> MemoryTracker: Peak memory usage: 39.87 MiB. 2018.08.03 16:56:02.753503 [ 12 ] <Debug> SrcData.TTStatBase (StorageReplicatedMergeTree): Part 201709_63076_64611_5 (state Outdated) should be deleted after previous attempt before fetch 2018.08.03 16:56:02.753556 [ 12 ] <Trace> SrcData.TTStatBase (StorageReplicatedMergeTree): Executing log entry to merge parts 201709_63076_63675_4, 201709_63676_64196_4, 201709_64197_64611_4 to 201709_63076_64611_5 2018.08.03 16:56:02.753587 [ 22 ] <Trace> SrcData.TTStatBase (Data): Found 1 old parts to remove. 2018.08.03 16:56:02.753614 [ 12 ] <Debug> SrcData.TTStatBase (MergerMutator): Merging 3 parts: from 201709_63076_63675_4 to 201709_64197_64611_4 into tmp_merge_201709_63076_64611_5 2018.08.03 16:56:02.753622 [ 22 ] <Debug> SrcData.TTStatBase (StorageReplicatedMergeTree): Removing 1 old parts from ZooKeeper 2018.08.03 16:56:02.755014 [ 12 ] <Debug> SrcData.TTStatBase (MergerMutator): Selected MergeAlgorithm: Vertical 2018.08.03 16:56:02.755235 [ 12 ] <Trace> MergeTreeBlockInputStream: Reading 1 ranges from part 201709_63076_63675_4, approx. 46530560 rows starting from 0

Приветствую, Михаил. Как решили проблему?

Аналогичная ошибка, встречалась уже не первый раз, и ругается всегда на поле с установленным значением DEAFULT (но может так совпало). Но, насколько я понимаю по тексту ошибки, КХ сам должен привести данные в соответствие (We will download merged part from replica to force byte-identical result)?

Как запускать длительные запросы из cli ? пробую OPTIMIZE TABLE graphite Received exception from server (version 18.6.0): Code: 209. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::NetException. DB::NetException: Timeout exceeded while reading from socket (192.168.148.16:9000): while receiving packet from graphite01:9000, 192.168.148.16. 0 rows in set. Elapsed: 300.284 sec.

привет ! Подскажите как сделать выборку полей где ChannelID не является уникальным ? count(ChannelID)>1 SELECT Time, TimeMillisecond, OpenTime, CloseTime, State, ChannelID, OpenHeight, CloseHeight, ChannelPoint, Capacity, Node1, Node1FeeBaseMSat, Node1FeeRateMilliMSat, Node1TimeLockDelta, Node1MinHTLC, Node2, Node2FeeBaseMSat, Node2FeeRateMilliMSat, Node2TimeLockDelta, Node2MinHTLC FROM lns.Channel WHERE CloseTime>=toDateTime('2018-08-10 23:59:59') AND CloseTime<=toDateTime('2018-08-11 23:59:59') AND count(ChannelID)>1 ORDER BY (ChannelID, Time, TimeMillisecond)

Я делал optimize на втором, насколько я помню. Это заставит первый скачать новые данные или сделать аналогичный альтер после фейла очередного мерджа.

Альтер? ALTER TABLE Optimize ...?

И прямо помогло? какая версия КХ? У меня в моменты выполнения optimize ошибки редели и вставка шла , до 50% от нормы, но через минуту перкращалась.

без reply или тегов не вижу вопроса. Логично, что optimize может блокировать вставки. Поэтому речь про отдельные проблемные partition. Очевидно, что если я пишу «решил проблему вот так-то» - значит, помогло. Возможно, придется оптимизировать куски по очереди на обеих репликах, если оптимизация одной не поможет.

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

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

Боюсь там уже совсем битком @Alexander_Anisimov

Доброго времени суток, я же правильно понимаю что файл users.xml обновляеться в рантайме, и если я добавлю дефолтную настройку для сохранения логов запросов она автоматически подсосется?

есть ручка для обновления конфига: SYSTEM RELOAD CONFIG

вторую дропнул, без этого ни строчки не вставлялось, на 12 часов данные отстали, только удалил реплицируемую таблицу на 2м, первый начал писать и по 100М строк вставлял, за 2 часа все нагнал, сейчас на единственном все прооптимизирую и буду снова реплицировать. Ещё хотелось бы знать версю на которй все решилось, сейчас последняя, до перехода на неё не было ошибок.

Всем привет. выполняю запрос вида: SELECT COUNT(eventDate) AS clicks FROM ( SELECT FROM ALL INNER JOIN USING PREWHERE qtype='pv' WHERE ) ANY INNER JOIN ( SELECT FROM PREWHERE WHERE ) USING WHERE GROUP BY и раз в ~10 запросов count для одной из строки результата получается на 1 меньше(8 вместо 9), чем нужно. Есть альтернативный запрос, он всегда возвращает верный ответ. Если выполнить запрос без агрегации с фильтром по нужным данным, то количество строк верное(9 всегда) Мне не даёт это покоя, что count не постоянен версия 18.1.0

eventDate не может быть NULL?

Всем привет. выполняю запрос вида: SELECT COUNT(eventDate) AS clicks FROM ( SELECT FROM ALL INNER JOIN USING PREWHERE qtype='pv' WHERE ) ANY INNER JOIN ( SELECT FROM PREWHERE WHERE ) USING WHERE GROUP BY и раз в ~10 запросов count для одной из строки результата получается на 1 меньше(8 вместо 9), чем нужно. Есть альтернативный запрос, он всегда возвращает верный ответ. Если выполнить запрос без агрегации с фильтром по нужным данным, то количество строк верное(9 всегда) Мне не даёт это покоя, что count не постоянен версия 18.1.0