Я не про бизнес-метрики

Предлагаю продолжить в Церкви

Предлагаю продолжить в Церкви

Предлагаю просто свернуть флуд. В церковь не пойду)

атеист? // простите, не удержался)

атеист? // простите, не удержался)

Очень давно там устроили холливар про заббиксы с Алексеем)

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

Выложена презентация с BackendConf 2018: https://yandex.github.io/clickhouse-presentations/rit2018/#

@nengchak не решил свою проблему с EOF reached for partition?

@nengchak не решил свою проблему с EOF reached for partition?

Не у меня была такая, а другая,, с кафки на таблицу данные долго падали

Не у меня была такая, а другая,, с кафки на таблицу данные долго падали

все верно, у нас прилетает по 100/200 сообщений и ждать надо очень долго пока в таблицу упадет. решили проблему?

все верно, у нас прилетает по 100/200 сообщений и ждать надо очень долго пока в таблицу упадет. решили проблему?

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

А где чейнжлог на 1.1.54382 ? Что там поменяли?

Всем привет, ребят, есть ли какие ты right way гайды, как делать отчеты из кликхауса + любая другая DB, т.е. несколько источников данных, и по ним надо делать всякие order, group, where…

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

Тогда кх не для вас

А как вы сейчас меняете сотни гигабайт данных?

Привет! У нас используется кворумная запись (на 3 реплики) и select_sequential_consistency. И при дропе партиции на одной из реплик, последующий запрос говорит: DB::Exception: Replica doesn't have part .... which was successfully written to quorum of other replicas. Send query to another replica or disable 'select_sequential_consistency' setting.. Как правильно дропать партиции с такими настройками? Я что-то опасаюсь дальше дропать на остальных репликах...

И заодно: как вылечить теперь эту ситуацию? На крайний случай, я могу дропнуть всю таблицу на всех репликах, скорее всего это поможет. Но это пока она новенькая и её легко перезаполнить.

Похоже, поменялось поведение argMax

Ранее запроc вида: SELECT datetime, argMax(runningDifference(cpu), 0) AS cpu FROM telegraf.hosting2_users WHERE login = 'login' AND datetime > '$date1' AND datetime < '$date2' GROUP BY datetime ORDER BY datetime ASC выдавал только неотрицательные значения.

Сейчас: SELECT * FROM ( SELECT datetime, argMax(runningDifference(cpu), 0) AS cpu FROM telegraf.hosting2_users WHERE (login = 'c1133') AND (datetime >= 1525750000) GROUP BY datetime ORDER BY datetime ASC ) WHERE cpu < 0 ┌────────────datetime─┬───────────────cpu─┐ │ 2018-05-27 01:31:30 │ -383.349985351786 │ └─────────────────────┴───────────────────┘

Привет! У нас используется кворумная запись (на 3 реплики) и select_sequential_consistency. И при дропе партиции на одной из реплик, последующий запрос говорит: DB::Exception: Replica doesn't have part .... which was successfully written to quorum of other replicas. Send query to another replica or disable 'select_sequential_consistency' setting.. Как правильно дропать партиции с такими настройками? Я что-то опасаюсь дальше дропать на остальных репликах...

Это была последняя по времени добавления партиция, соответственно, на всех репликах она дропнулась (replication_alter_partotion_sync=2. если что), а в зоокипере по пути /clickhouse/tables/кластер/имя таблицы/quorum в параметре last_part имя этой дропнутой партиции осталось. Я так понимаю, при консистентном селекте на это и ругаются. Это баг (сделать issue?) или я просто неправильно что-то делаю?

Уже вроде спрашивали, но давно и ответа не видно. В кафку падают сообщения по 100/200 в секунду. Далее импортируется в КХ движком Kafka в MergeTree. Но из-за малого объема данных импорт происходит крайне редко, вроде бы когда сообщений 65536 (но это не точно, бывает и больше и меньше). Пробовал крутить параметры librdkafka - ничего не поменялось. Да, история не совсем про КХ (с большим количеством данных), но хочу понять - данное поведение нельзя изменить для импорта малого количества данных, чтоб не ждать по пол дня?

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

Какого рода изменениям ? Есть такой движок aggregatedmergetree, посмотрите, может подойдёт

А где чейнжлог на 1.1.54382 ? Что там поменяли?

https://github.com/yandex/ClickHouse/blob/master/CHANGELOG.md

Это была последняя по времени добавления партиция, соответственно, на всех репликах она дропнулась (replication_alter_partotion_sync=2. если что), а в зоокипере по пути /clickhouse/tables/кластер/имя таблицы/quorum в параметре last_part имя этой дропнутой партиции осталось. Я так понимаю, при консистентном селекте на это и ругаются. Это баг (сделать issue?) или я просто неправильно что-то делаю?

Да, это баг. Вы можете изменить значение quorum аккуратно вручную.

https://github.com/yandex/ClickHouse/blob/master/CHANGELOG.md

ТАм не вижу

ТАм не вижу

Версия 54382 не релизилась. Можно считать, что её нет.

а в каком номере релиза ожидается delete, в таком случае?

В следующем.

Не номере, а релизе. Номер может быть любой больший.

Мы тут тестируем разного рода аварийные ситуации, заметили, что некоторые старые таблицы (возрастом больше недели), в которые давно никто не пишет и используются только для селектов, покараптились. Вычитал про Freeze partition. Есть два вопроса: 1) Почему покараптились данные? Из-за постоянных попыток слияний? Таблица MergeTree 2) Freeze partition поможет остановить write операции на старых данных, где оптимизировать-сжимать больше нечего?

Мы тут тестируем разного рода аварийные ситуации, заметили, что некоторые старые таблицы (возрастом больше недели), в которые давно никто не пишет и используются только для селектов, покараптились. Вычитал про Freeze partition. Есть два вопроса: 1) Почему покараптились данные? Из-за постоянных попыток слияний? Таблица MergeTree 2) Freeze partition поможет остановить write операции на старых данных, где оптимизировать-сжимать больше нечего?

Что значит покорраптились, каким именно образом? Это не может или не должно происходить по причине слияний. Отключить слияния для таблицы невозможно, FREEZE PARTITION это не сделает (а лишь создаст снапшот таблицы на данный момент времени).

В логах появились такие записи: 2018.05.28 12:06:07.721545 [ 1 ] <Error> testdb.log_2017_07 (Data): Detaching broken part /opt/clickhouse-data/data/testdb/log_2017_07/20170707_20170712_3491_6873_5 because it covers less than 2 parts. You need to resolve this manually

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

попробовал команду freeze на неизменяющейся таблице для одной из партиций. но почему-то вместо хардлинков в shadow был создан один файлик # ls -l total 4 -rw-r----- 1 clickhouse clickhouse 2 May 30 15:09 increment.txt чяднт?

но у нас датадир не /var/lib/clickhouse/ а свой, в /opt, права все выставлены

О, разобрался. Мануал говорит, что в FREEZE надо использовать name, я и использовал имя из колонки name из system.parts. А надо было имя из колонки partition вида 201710

Помогите разобраться, может кто сталкивался. поднято 2 ch, как один шард с двумя репликами и 2 zookeeper, все в докере. На запрос на первом сервере CREATE TABLE zootest ON CLUSTER ch ( day Date DEFAULT toDate(created), query String, type String ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/zootest', '{replica}', day, (day, type), 8192) получаю ошибку DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000000000 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 2 unfinished hosts (0 of them are currently active), they are going to execute the query in background. По логам на втором сервере вижу только 2018.05.30 12:45:15.313603 [ 2 ] <Debug> DDLWorker: Cleaning queue 2018.05.30 12:45:15.318869 [ 2 ] <Debug> DDLWorker: Processing tasks 2018.05.30 12:45:15.339531 [ 2 ] <Debug> DDLWorker: Will not execute task query-0000000000: There is no a local address in host list 2018.05.30 12:45:15.339584 [ 2 ] <Debug> DDLWorker: Waiting a watch Понимаю, что чего-то не хватает, но чего?

Помогите разобраться, может кто сталкивался. поднято 2 ch, как один шард с двумя репликами и 2 zookeeper, все в докере. На запрос на первом сервере CREATE TABLE zootest ON CLUSTER ch ( day Date DEFAULT toDate(created), query String, type String ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/zootest', '{replica}', day, (day, type), 8192) получаю ошибку DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000000000 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 2 unfinished hosts (0 of them are currently active), they are going to execute the query in background. По логам на втором сервере вижу только 2018.05.30 12:45:15.313603 [ 2 ] <Debug> DDLWorker: Cleaning queue 2018.05.30 12:45:15.318869 [ 2 ] <Debug> DDLWorker: Processing tasks 2018.05.30 12:45:15.339531 [ 2 ] <Debug> DDLWorker: Will not execute task query-0000000000: There is no a local address in host list 2018.05.30 12:45:15.339584 [ 2 ] <Debug> DDLWorker: Waiting a watch Понимаю, что чего-то не хватает, но чего?

1. Зукиперов должно быть не четное число 1,3 и т.д. Так как если один отвалиться , не сможет пройти кворум 2. Реплицируемую таблицу нужно отдельно создавать на каждой ноде CH. (Без ON CLUSTER ch). И на каждой ноде макрос {replica} должен быть разный

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

если все правильно настроено

1. Зукиперов должно быть не четное число 1,3 и т.д. Так как если один отвалиться , не сможет пройти кворум 2. Реплицируемую таблицу нужно отдельно создавать на каждой ноде CH. (Без ON CLUSTER ch). И на каждой ноде макрос {replica} должен быть разный

А если 2 отвалится?

На сколько я знаю должно быть больше 2х нод

Для выбора арбитра надо минимум3

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

если два отвалится то просто встанут реплицируемые таблицы

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

Кто то читал как происходит голосование?

зукиперов живых должно быть больше чем мертвых не более того

если у вас 3 зк, то 2 живых минимум, если 5 зк, то три живых

зукиперов живых должно быть больше чем мертвых не более того

Вот это правда

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

Соглашаюсь) Если макрос на нодах разный

То можно

1. Зукиперов должно быть не четное число 1,3 и т.д. Так как если один отвалиться , не сможет пройти кворум 2. Реплицируемую таблицу нужно отдельно создавать на каждой ноде CH. (Без ON CLUSTER ch). И на каждой ноде макрос {replica} должен быть разный

Убрать ON CLUSTER частично помогло, но похоже, что проблема была не в нем. В докер контейнер я пробрасываю фейковый hostname, чтоб было понятно, на какой машине я нахожусь, так кликхаус его использует для поднятия соединения, судя по логу: 2018.05.30 13:45:32.521258 [ 11 ] <Error> default.zootest (StorageReplicatedMergeTree): DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Host not found: clickhouse-1-2, e.what() = Host not found

2018.05.30 16:59:19.110988 [ 96209 ] <Error> ServerErrorHandler: Poco::Exception. Code: 1000, e.code() = 104, e.displayText() = Connection reset by peer, e.what() = Connection reset by peer а что это и почему у меня весь лог этим завален ?)

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

Да, это возможно, если данные из ФС не сбросились на диск за время жизни старых кусков, оставшихся после мержа (по-умолчанию, 8 минут). Если таблица реплицированная, то всё восстановится автоматически. Если нет - надо либо увеличить old_parts_lifetime в config.xml, секция merge_tree. См. описание в файле MergeTreeSettings.h. Либо изменить параметры в /proc/sys/vm/...

Да, это возможно, если данные из ФС не сбросились на диск за время жизни старых кусков, оставшихся после мержа (по-умолчанию, 8 минут). Если таблица реплицированная, то всё восстановится автоматически. Если нет - надо либо увеличить old_parts_lifetime в config.xml, секция merge_tree. См. описание в файле MergeTreeSettings.h. Либо изменить параметры в /proc/sys/vm/...

Спасибо за пояснения! Я так понимаю, в линуксе нужные параметры будут vm.dirty_ratio, vm.dirty_background_ratio, vm.dirty_expire_centisecs и vm.dirty_writeback_centisecs ?

Алексей, расскажите, если можно, поподробнее, как данные сбрасываются на диск? Есть ли механизмы, подобные write-ahead-log + checkpoint, которые защищают от потери данных при выключении питания?

Спасибо за пояснения! Я так понимаю, в линуксе нужные параметры будут vm.dirty_ratio, vm.dirty_background_ratio, vm.dirty_expire_centisecs и vm.dirty_writeback_centisecs ?

Да. Но, насколько я понимаю, параметры типа centisecs определяют, когда начнётся сброс данных, но не гарантируют, что данные будут сброшены. Их можно уменьшить, но закладываться не стоит.

Алексей, расскажите, если можно, поподробнее, как данные сбрасываются на диск? Есть ли механизмы, подобные write-ahead-log + checkpoint, которые защищают от потери данных при выключении питания?

Нет.

Да. Но, насколько я понимаю, параметры типа centisecs определяют, когда начнётся сброс данных, но не гарантируют, что данные будут сброшены. Их можно уменьшить, но закладываться не стоит.

Понятно. А есть ли какие-то тёмные стороны у уменьшения old_parts_lifetime, кроме повышения IO диска?

Понятно. А есть ли какие-то тёмные стороны у уменьшения old_parts_lifetime, кроме повышения IO диска?

Наоборот, для надёжности надо увеличить old_parts_lifetime, а не уменьшить. Будет расходоваться больше места для недавно померженных данных.

Наоборот, для надёжности надо увеличить old_parts_lifetime, а не уменьшить. Будет расходоваться больше места для недавно померженных данных.

О, я кажется понял, что у нас случилось. Диск был очень загружен, на него шла запись из памяти померженых кусков, она ввиду тормозов диска заняла больше 8 минут, старые куски на диске удалились, а новые ещё не записались и сервер в этот момент был выключен. ?️?

Да.

Да.

old_parts_lifetime в xml указывается же в секундах? или надо в формате 15*60, как в коде? там M(SettingSeconds, old_parts_lifetime, 8 * 60)

Нет.

Спасибо, тогда другой вопрос: выключение питания сервера при активной записи на диск может привести к потере всех данных в таблице/партиции и можно ли застраховаться от этого?

Спасибо, тогда другой вопрос: выключение питания сервера при активной записи на диск может привести к потере всех данных в таблице/партиции и можно ли застраховаться от этого?

Ноды-реплики + freeze partition + вот увеличение old_parts_lifetime, как сегодня выяснилось)

Спасибо, тогда другой вопрос: выключение питания сервера при активной записи на диск может привести к потере всех данных в таблице/партиции и можно ли застраховаться от этого?

И чисто архитектурный вариант, не хранить всё в одной таблице, а разбиват данные на дневные, часовые, минутные - и их партиции фризить. Фризы из папки shadow в датадире clickhouse можно рсинкать куда-нибудь даже

old_parts_lifetime в xml указывается же в секундах? или надо в формате 15*60, как в коде? там M(SettingSeconds, old_parts_lifetime, 8 * 60)

В виде одного числа - в секундах.

Спасибо, тогда другой вопрос: выключение питания сервера при активной записи на диск может привести к потере всех данных в таблице/партиции и можно ли застраховаться от этого?

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

И чисто архитектурный вариант, не хранить всё в одной таблице, а разбиват данные на дневные, часовые, минутные - и их партиции фризить. Фризы из папки shadow в датадире clickhouse можно рсинкать куда-нибудь даже

Это совершенно излишне.

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

А каким образом Реплики спасут от данных ещё не записанных на одной из нод?

INSERT возвращает клиенту успех после того, как данные записаны на файловую систему. При этом fsync не делается, и данные, записанные на файловую систему, могут быть ещё не записаны на диск. Данные реплицируются сразу после INSERT, то есть, могут быть реплицированы, когда ещё не записаны на диск ни на одной реплике.

В виде одного числа - в секундах.

Прописал, перезапустил сервис. Параметр появился в config-preprocessed.xml , но если сделать select * from system.settings where changed; изменение параметра не отображается. Или и не должно в случае с old_parts_lifetime ? ClickHouse server version 1.1.54362

Это не настройка запроса/пользователя/сессии. Поэтому в system.settings нет.

INSERT возвращает клиенту успех после того, как данные записаны на файловую систему. При этом fsync не делается, и данные, записанные на файловую систему, могут быть ещё не записаны на диск. Данные реплицируются сразу после INSERT, то есть, могут быть реплицированы, когда ещё не записаны на диск ни на одной реплике.

Формат хранения допустит, что что вся таблица/партиция станет логически неверной после аварии и восстановления питания?

Выложена презентация с BackendConf 2018: https://yandex.github.io/clickhouse-presentations/rit2018/#

а видео пока нет?

Формат хранения допустит, что что вся таблица/партиция станет логически неверной после аварии и восстановления питания?

Допустит, внутри всё хранится куда мельче чем таблица/партиция. Если на реплику кусок уехал то проблемный сервер после включения увидит что с данными не все впорядке и скачает кусок/куски с реплики и всё будет ОК

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

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

Я это делаю https://github.com/outbrain/zookeepercli

то есть костыликами?)

Мм, не вижу тут ничего костыльного

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

И да и нет

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

Но они находятся в структуре кх

ладно это религиозный спор, встроенных средств как я понимаю нет

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

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

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

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

у меня динамический кластер, смерть это часть жизни ))

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

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

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

лучше как часть кх с настройкой типа replica_cleanup_interval

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

у меня динамический кластер, смерть это часть жизни ))

Ну так перед смертью просто делайте дроп тейбл