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

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

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

неделю не могу локализовать, думал покоррачены данные , перелил все с помощью insert ... select

только начинаю лить, ошибки на свежие данные

Ну на других серверах надо пробовать чтобы исключить железо

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

Ну смахивает на железо что чексуммы не правильно считаются

При сборке build-normal error: cannot find -lLLVM - кто нибудь сталкивался?

А разве не гцц он собирается?

подскажите, как можно выбрать таблицу в случайном порядке?

Ну смахивает на железо что чексуммы не правильно считаются

Начинается репликация нормально, потом в логе принимающего: 2018.08.24 09:19:10.005141 [ 22 ] <Debug> default.graphite (ReplicatedMergeTreeQueue): Not executing log entry for part 20180823_20180824_312050_312069_2 because another log entry for the same part is being processed. This should n't happen often. 2018.08.24 09:19:10.060520 [ 118 ] <Debug> default.graphite_tree (ReplicatedMergeTreeQueue): Pulled 1 entries to queue. 2018.08.24 09:19:10.061299 [ 94 ] <Debug> default.graphite_tree (StorageReplicatedMergeTree): Fetching part 20171201_20171201_428163_428163_0 from /clickhouse/tables/02/graphite_tree/replicas/r6 2018.08.24 09:19:10.184892 [ 94 ] <Debug> default.graphite_tree (StorageReplicatedMergeTree): Fetched part 20171201_20171201_428163_428163_0 from /clickhouse/tables/02/graphite_tree/replicas/r6 2018.08.24 09:19:10.874665 [ 66 ] <Debug> MergingSortedBlockInputStream: Merge sorted 436 blocks, 3564587 rows in 14.23 sec., 250444.87 rows/sec., 35.08 MB/sec. 2018.08.24 09:19:10.874920 [ 66 ] <Debug> default.graphite (MergerMutator): Merge sorted 3820242 rows, containing 5 columns (5 merged, 0 gathered) in 14.24 sec., 268348.84 rows/sec., 36.75 MB/sec. 2018.08.24 09:19:10.883715 [ 66 ] <Debug> default.graphite (Data): Undoing transaction. Removing parts: 20180823_20180824_312070_312073_1. 2018.08.24 09:19:10.883893 [ 66 ] <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 co mpressed 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. Usi ng 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 i n 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.24 09:19:10.884024 [ 66 ] <Debug> MemoryTracker: Peak memory usage: 103.21 MiB. 2018.08.24 09:19:10.885331 [ 66 ] <Debug> default.graphite (StorageReplicatedMergeTree): Part 20180823_20180824_312070_312073_1 (state Outdated) should be deleted after previous attempt before fetch 2018.08.24 09:19:10.885457 [ 128 ] <Debug> default.graphite (StorageReplicatedMergeTree): Removing 1 old parts from ZooKeeper 2018.08.24 09:19:10.885514 [ 66 ] <Debug> default.graphite (ReplicatedMergeTreeQueue): Not executing log entry for part 20180823_20180824_307295_307594_6 because it is covered by part 20180801_20180824_300770_309471_10 that is cu rrently executing

Undoing transaction. Removing parts: - всегда говорят о том, что сервер занят бесконечнымим мерджами

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

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

А разве не гцц он собирается?

Вроде gcc но при сборке такое выдаёт

когда удяляю таблицу, в зукипере пропадают ее пути, пробовал на поблемном сервере уже сменить ID реплики с r1 ->r7 , пути создались верные, новые, вроде все ок, мб известно, что конкретно смотреть?

Вроде gcc но при сборке такое выдаёт

ну видимо это был не нескафе

когда удяляю таблицу, в зукипере пропадают ее пути, пробовал на поблемном сервере уже сменить ID реплики с r1 ->r7 , пути создались верные, новые, вроде все ок, мб известно, что конкретно смотреть?

ну совпадающих путей нет у ваших таблиц ?

сейчас на r7 удалена реплицируемая таблица, так в ЗК: [zk: localhost:2181(CONNECTED) 6] ls /clickhouse/tables/02/graphite/replicas [r5, r6]

это виртуалка и сервер2

вынесем, как репликация заработает, все работало на версии 1.54390, обновились до 18.6.0 и начались проблемы

Там use_minimalistic_checksums_in_zookeeper по дефолту включен

выключить?

нет такой переменной в конфигах

нет такой переменной в конфигах

https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md#clickhouse-release-1840-2018-07-28

ясно, перед включением в реплику серрвера1 выключу, спасибо

отключил везде, в config-preprocessed появилось, в system.settings не появляется

Там use_minimalistic_checksums_in_zookeeper по дефолту включен

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

Вопрос ещё актуальный...

просо в КХ есть функци generateUUIDv4() но она генерит тип UUID который хоть возвращается, как String при format JSON, но с периодически там проскакивают UUID с символом переноса строки, что является невалидным JSON при парсинге

Как проверить,что use_minimalistic_checksums_in_zookeeper отключено ?

Добрый день. А есть ли у КХ возможность сконфигурировать движок, или добавить что-то в запрос, таким образом, чтобы не происходила вставка данных при "конфликте" по одному или нескольким полям? По ПК или по другому кортежу

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

есть, конечно, ReplacingMergeTree, но я вот хочу использовать SummingMergeTree ?

о... А я же могу загруужать данные в таблиицу ReplacingMergeTree, а потом с него в таблиицу SummingMerge. Хм. По крайней мере это можно реализовать только для импорта метрик. Но вот строка из документации меня немного смущает и удивляет: "Таким образом, ReplacingMergeTree подходит для фоновой чистки дублирующихся данных в целях экономии места, но не даёт гарантий отсутствия дубликатов."

т.е. он это делает, но не дает гарантий. Однако.

Так никакой MergeTree движок не даёт гарантий — там могут быть записи, которые не смерджились

ODBC драйвер на сервере работает(isql подключается и запросы выполняет), на виндовом десктопе ворбук тоже работает нормально. DSN имеют одинаковые имена, что на сервере, что на декстопе В веб интерфейсе после того как подключаюсь к воркбуку выдается такая ошибка Смущает что показывает «unable to connect to localhost», хотя в DSN(System wide) указаны другие порты, может как-то надо настраивать по особенному для табло?

ODBC драйвер на сервере работает(isql подключается и запросы выполняет), на виндовом десктопе ворбук тоже работает нормально. DSN имеют одинаковые имена, что на сервере, что на декстопе В веб интерфейсе после того как подключаюсь к воркбуку выдается такая ошибка Смущает что показывает «unable to connect to localhost», хотя в DSN(System wide) указаны другие порты, может как-то надо настраивать по особенному для табло?

буквально пару дней назад было нечто подобное, проверьте, нет ли в названии DSN символа дефис (-). Вдруг )

Ребят, а репликация не тянется по какой причине? В логе куча ошибок типа connection refused. https://gist.github.com/the-tinderbox/e1d6692217d165e38987682aa3d6a73c

При том, что сервера доступны между собой

И зукипер работает

Логинов и паролей кастомных нет, listen в :: стоит. Все по дефолту после установки.

Макросы прописаны, в ЗК есть ноды для каждой реплики

Он обычно в логе пишет в какие url'ы пытается сходить за данными, можно попробовать curl'ом дёрнуть.

Прикольно. Он какой-то непонятный хостнейм пытается использовать...

Блин, ну явно же в конфиге прописан хостнейм по которому ходить...

interserver_http_host?

Понятно, туда нужно еще прописать. Там закомменченно все, по умолчанию берет hostname -f

Да, так и есть

Да, так и есть

Завелось! Спасибо большое! Буду знать теперь :)

ну видимо это был не нескафе

ENABLE_EMBEDDED_COMPILER=0 помогло

Как проверить,что use_minimalistic_checksums_in_zookeeper отключено ?

Вопрос остается в силе, как проверить. что настройка изменилась?

кажись я тебя знаю

Как проверить,что use_minimalistic_checksums_in_zookeeper отключено ?

Это настройки MergeTree вы их либо в соответствующий конфиг вписываете либо при создании таблицы, в новый версиях можно SELECT * FROM system.merge_tree_settings WHERE name = 'use_minimalistic_checksums_in_zookeeper' ┌─name────────────────────────────────────┬─value─┬─changed─┐ │ use_minimalistic_checksums_in_zookeeper │ 1 │ 0 │ └─────────────────────────────────────────┴───────┴─────────┘ 1 rows in set. Elapsed: 0.006 sec.

Вопрос остается в силе, как проверить. что настройка изменилась?

Судя по тестам ( https://github.com/yandex/ClickHouse/blob/0eed697623afd251c1908073c4a2850a9bfc9cdc/dbms/tests/queries/0_stateless/00611_zookeeper_different_checksums_formats.sql ) примерно так: SELECT value FROM system.zookeeper WHERE path='{путь к таблице}/replicas/{название реплики}/parts/{название свежей части}' AND name = 'checksums';

Если значение начиниается с 'checksums format version: 4' и - значит старый формат. Если 'checksums format version: 5' - значит новый / минималистичный.

Это влияет только на нововставленные / свежесмердженные куски.

ясно

на сервере2, который перезагружал =4, на сервере1, без перезагрузки, тот же путь, но другой ИД реплики, =5

на сервере2, который перезагружал =4, на сервере1, без перезагрузки, тот же путь, но другой ИД реплики, =5

Скорее всего у вас работают разные версии КХ сервера

Если, конечно, руками настройки не меняли

нет ,версия одинаковая, я поменял всем конфиг, но перезагрузил только серв2

менял, так как валится репликация

ОК

Начинается репликация нормально, потом в логе принимающего: 2018.08.24 09:19:10.005141 [ 22 ] <Debug> default.graphite (ReplicatedMergeTreeQueue): Not executing log entry for part 20180823_20180824_312050_312069_2 because another log entry for the same part is being processed. This should n't happen often. 2018.08.24 09:19:10.060520 [ 118 ] <Debug> default.graphite_tree (ReplicatedMergeTreeQueue): Pulled 1 entries to queue. 2018.08.24 09:19:10.061299 [ 94 ] <Debug> default.graphite_tree (StorageReplicatedMergeTree): Fetching part 20171201_20171201_428163_428163_0 from /clickhouse/tables/02/graphite_tree/replicas/r6 2018.08.24 09:19:10.184892 [ 94 ] <Debug> default.graphite_tree (StorageReplicatedMergeTree): Fetched part 20171201_20171201_428163_428163_0 from /clickhouse/tables/02/graphite_tree/replicas/r6 2018.08.24 09:19:10.874665 [ 66 ] <Debug> MergingSortedBlockInputStream: Merge sorted 436 blocks, 3564587 rows in 14.23 sec., 250444.87 rows/sec., 35.08 MB/sec. 2018.08.24 09:19:10.874920 [ 66 ] <Debug> default.graphite (MergerMutator): Merge sorted 3820242 rows, containing 5 columns (5 merged, 0 gathered) in 14.24 sec., 268348.84 rows/sec., 36.75 MB/sec. 2018.08.24 09:19:10.883715 [ 66 ] <Debug> default.graphite (Data): Undoing transaction. Removing parts: 20180823_20180824_312070_312073_1. 2018.08.24 09:19:10.883893 [ 66 ] <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 co mpressed 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. Usi ng 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 i n 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.24 09:19:10.884024 [ 66 ] <Debug> MemoryTracker: Peak memory usage: 103.21 MiB. 2018.08.24 09:19:10.885331 [ 66 ] <Debug> default.graphite (StorageReplicatedMergeTree): Part 20180823_20180824_312070_312073_1 (state Outdated) should be deleted after previous attempt before fetch 2018.08.24 09:19:10.885457 [ 128 ] <Debug> default.graphite (StorageReplicatedMergeTree): Removing 1 old parts from ZooKeeper 2018.08.24 09:19:10.885514 [ 66 ] <Debug> default.graphite (ReplicatedMergeTreeQueue): Not executing log entry for part 20180823_20180824_307295_307594_6 because it is covered by part 20180801_20180824_300770_309471_10 that is cu rrently executing

@kshvakov выставление настройки =0 может помочь с этой проблемой ?

нет ,версия одинаковая, я поменял всем конфиг, но перезагрузил только серв2

А ради интереса, попробуйте сделать тест памяти на проблемном сервере

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

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

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

При сборке build-normal error: cannot find -lLLVM - кто нибудь сталкивался?

какая ос, как запускали и что сказал cmake (на пасту пожалуйста)

ODBC драйвер на сервере работает(isql подключается и запросы выполняет), на виндовом десктопе ворбук тоже работает нормально. DSN имеют одинаковые имена, что на сервере, что на декстопе В веб интерфейсе после того как подключаюсь к воркбуку выдается такая ошибка Смущает что показывает «unable to connect to localhost», хотя в DSN(System wide) указаны другие порты, может как-то надо настраивать по особенному для табло?

у таблы нет своей конфигурации подключения с сервертом итд? на десктопе она при выборе DSN дает отдельно понастраивать все остальные параметры

у таблы нет своей конфигурации подключения с сервертом итд? на десктопе она при выборе DSN дает отдельно понастраивать все остальные параметры

Нет, в документации они говоритят, что бы параметры DSN были одинаковые что на десктопе, что на сервере. если что-то хочешь править - то надо закидывать конфигурацию в папку. Но я сравнил, у меня параметры на десктопе одинаковые. https://onlinehelp.tableau.com/current/pro/desktop/en-us/odbc_customize.html

добрый день пытаюсь вставить в КХ csv файл (экспорт из постгреса), в котором в начале значения строкового поля может стоять одинарная кавычка, например 11968,'cths,2619485523 в этом случае КХ считывает одинарную кавычку как обрамление строкового значения и парсинг рушится. подскажите пожалуйста, есть ли какая-то возможность заставить КХ игнорировать знак одинарной кавычки в принципе?

Здравствуйте, а есть какие-то подводные камни апгрейда кликхауса? Имеется 2 ноды версии 1.1.54327 с реплицирующимися через зукипер таблицами (ReplicatedReplacingMergeTree). Не отвалятся ли таблицы при апгрейде? Есть какие-то рекомендации по самому процессу апгрейда? В доке не нашел, если плохо искал - ткните, пожалуйста

добрый день пытаюсь вставить в КХ csv файл (экспорт из постгреса), в котором в начале значения строкового поля может стоять одинарная кавычка, например 11968,'cths,2619485523 в этом случае КХ считывает одинарную кавычку как обрамление строкового значения и парсинг рушится. подскажите пожалуйста, есть ли какая-то возможность заставить КХ игнорировать знак одинарной кавычки в принципе?

format_csv_allow_single_quotes=0 (поддерживается с версии 1.1.54390, 2018-07-06)

Здравствуйте, а есть какие-то подводные камни апгрейда кликхауса? Имеется 2 ноды версии 1.1.54327 с реплицирующимися через зукипер таблицами (ReplicatedReplacingMergeTree). Не отвалятся ли таблицы при апгрейде? Есть какие-то рекомендации по самому процессу апгрейда? В доке не нашел, если плохо искал - ткните, пожалуйста

https://github.com/yandex/ClickHouse/issues/2778 можно почитать тут

Если обновляться сразу на новую версию, то должно быть ок

Если обновляться сразу на новую версию, то должно быть ок

А если не сразу, например с ноябрьской?

кажись я тебя знаю

+

А если не сразу, например с ноябрьской?

А зачем, если не секрет?)

Здравствуйте, а есть какие-то подводные камни апгрейда кликхауса? Имеется 2 ноды версии 1.1.54327 с реплицирующимися через зукипер таблицами (ReplicatedReplacingMergeTree). Не отвалятся ли таблицы при апгрейде? Есть какие-то рекомендации по самому процессу апгрейда? В доке не нашел, если плохо искал - ткните, пожалуйста

как я знаю нигде нет никакой информации или рекомендации по обновлению ClickHouse

А зачем, если не секрет?)

Обновлять - чтобы alter delete появился) А уж отставание по многим причинам появилось

Здравствуйте, а есть какие-то подводные камни апгрейда кликхауса? Имеется 2 ноды версии 1.1.54327 с реплицирующимися через зукипер таблицами (ReplicatedReplacingMergeTree). Не отвалятся ли таблицы при апгрейде? Есть какие-то рекомендации по самому процессу апгрейда? В доке не нашел, если плохо искал - ткните, пожалуйста

Обновление на отдельном сервере происходит так - обновляете пачки, после чего запускаете рестарт clickhouse-server (сам при обновлении пачек не перезапустится, продолжит работать старый). Идеальный сцераний обновления: 1) обновляете стейджинг, запускаете тесты, радуетесь что ничего не высыпалось. 2) (по возможности) останавливаете запись в КХ 3) обновляете одну реплику (все шарды), перезапускаете их. Ждете немного, радуетесь что ничего не высыпалось. 4) Потом так же обновляете остальные реплики. В некоторых (редких) случаях реплики разных версий не могут сосуществовать в одном кластере (проверяйте changelog), тогда нужно сразу все апдейтовать. Если что-то пошло не так - то нужно 1) начать паниковать 2) сделать роллбака 3) ещё попаниковать 4) разобраться что пошло не так

Обновление на отдельном сервере происходит так - обновляете пачки, после чего запускаете рестарт clickhouse-server (сам при обновлении пачек не перезапустится, продолжит работать старый). Идеальный сцераний обновления: 1) обновляете стейджинг, запускаете тесты, радуетесь что ничего не высыпалось. 2) (по возможности) останавливаете запись в КХ 3) обновляете одну реплику (все шарды), перезапускаете их. Ждете немного, радуетесь что ничего не высыпалось. 4) Потом так же обновляете остальные реплики. В некоторых (редких) случаях реплики разных версий не могут сосуществовать в одном кластере (проверяйте changelog), тогда нужно сразу все апдейтовать. Если что-то пошло не так - то нужно 1) начать паниковать 2) сделать роллбака 3) ещё попаниковать 4) разобраться что пошло не так

Пачки?

Пачки?

Пакеты

@kshvakov выставление настройки =0 может помочь с этой проблемой ?

Отключил везде, ЗК говорит, в новых блоках везде 4я версия, запустил реплику на сервер1, на доноре появились ошибки чексумы

format_csv_allow_single_quotes=0 (поддерживается с версии 1.1.54390, 2018-07-06)

спасибо!

Пачки?

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

Но догадаться вроде можно :)

Отключил везде, ЗК говорит, в новых блоках везде 4я версия, запустил реплику на сервер1, на доноре появились ошибки чексумы

Мда, беда прям какая-то. Это только для конкретной таблицы проявляется или все побито? Можно рядом создать простую ReplicatedMergeTree и поиграться, можно вообще настроить репликацию в тотже сервер и посмотреть что будет.

Отключил везде, ЗК говорит, в новых блоках везде 4я версия, запустил реплику на сервер1, на доноре появились ошибки чексумы

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

Если размер партиций не очень большой, можно всю партицию скопировать куда-то потом удалить и залить заново.