привет. внезапно прекратились мержи, в логах КХ ошибки типа: 2018.08.01 05:04:46.025443 [ 53 ] <Warning> local.clickstream_new (StorageReplicatedMergeTree, PartCheckThread): Found parts with the same min block and with the same max block as the missing part 201807-0_783_809_5. Hoping that it will eventually appear as a result of a merge. в папке таблицы набралось много папок 201807-0_XXX_XXX_0. вставляем в distributed таблицу, проблемы только у двух таблиц: оригинальной и ее копии с кастомным партиционированием, остальные мержатся нормально. процесс заливки данных не изменяли. куда смотреть?

у прометея есть экспортёр для ch, -scrape_uri=http://clickhouse.service.consul:8123/, в результате жалуется на dial tcp: lookup clickhouse.service.consul on 2.1.9.9:53: no such host" file=clickhouse_exporter.go line=310 time="2018-07-31T09:28:27Z" level=info msg="Error scraping clickhouse: Error scraping clickhouse url http://ch.service.consul:8123/?query=select+%2A+from+system.metrics: Error scraping clickhouse:`

scrape_uri - это адрес КХ (обычно 127.0.0.1), в прометеусе вы можете руками прописать адреса экспортеров, либо использовать консул и регать экспортеры там, если у вас окружение динамическое то лучше использовать консул и там регистрироваться, если нет то просто пропишите в него адреса экспортеров.

Добрый день! Есть столбцы (string, hash): data1, data2, data3, и другие столбцы Нужно делать поиск по data1 ИЛИ data2 ИЛИ data3 Как лучше организовать таблицу или таблицы, чтобы CH максимально хорошо и быстро искал нужные строки?

Добрый день, коллеги! Делаю выборку: select request_id from my_table where request_id = '59f911f179bea204f6890ea5' Результат - одна строка. Затем подставляю в селекте вместо request_id некоторую константу, но с тем же условием: select 'new_request_id' as request_id from my_table where request_id = '59f911f179bea204f6890ea5' Результат - пусто. Что бы это могло быть?

Так работает? select 'new_request_id' as request_id2 from my_table where request_id = '59f911f179bea204f6890ea5'

Добрый день, коллеги! Делаю выборку: select request_id from my_table where request_id = '59f911f179bea204f6890ea5' Результат - одна строка. Затем подставляю в селекте вместо request_id некоторую константу, но с тем же условием: select 'new_request_id' as request_id from my_table where request_id = '59f911f179bea204f6890ea5' Результат - пусто. Что бы это могло быть?

Проще говоря он реплейсит request_id на new_request_id

Не делайте алиасы с названием колонок

Так работает? select 'new_request_id' as request_id2 from my_table where request_id = '59f911f179bea204f6890ea5'

Да, если присваивать другой алиас, то всё работает нормально.

Кто-нибудь использует кластер в который интенсивно пишут? Раз 50-100 в минуту я имею в виду. Попробуйте стопануть одну реплику, у меня на второй прекражаються мержи и через 2-3-5 минут привет исключение о медленных мержах (притом такое поведение даже если все вьюхи убрать) Может есть какая-то настройка чтобы оставшаяся в живых реплика не прекращала мержить? Таблица причины почему мержи не идут полна такого │ MetricsFree │ Not merging into part c1d05dd4c541bdc14737a222ad2b09b1_1147_1561_155 because part c1d05dd4c541bdc14737a222ad2b09b1_1147_1560_154 is not ready yet (log entry for that part is being processed). │ Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused и такого │ Metrics │ Not merging into part babccf0c7ab1c3af920fb405ca79c901_36891_36895_1 because part babccf0c7ab1c3af920fb405ca79c901_36892_36892_0 is not ready yet (log entry for that part is being processed). │ Code: 234, e.displayText() = DB::Exception: No active replica has part babccf0c7ab1c3af920fb405ca79c901_36891_36895_1 or covering part, e.what() = DB::Exception │ Потеря реплики это обычный сценарии, верно? А он поломан. Не критично?

Кто-нибудь использует кластер в который интенсивно пишут? Раз 50-100 в минуту я имею в виду. Попробуйте стопануть одну реплику, у меня на второй прекражаються мержи и через 2-3-5 минут привет исключение о медленных мержах (притом такое поведение даже если все вьюхи убрать) Может есть какая-то настройка чтобы оставшаяся в живых реплика не прекращала мержить? Таблица причины почему мержи не идут полна такого │ MetricsFree │ Not merging into part c1d05dd4c541bdc14737a222ad2b09b1_1147_1561_155 because part c1d05dd4c541bdc14737a222ad2b09b1_1147_1560_154 is not ready yet (log entry for that part is being processed). │ Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused и такого │ Metrics │ Not merging into part babccf0c7ab1c3af920fb405ca79c901_36891_36895_1 because part babccf0c7ab1c3af920fb405ca79c901_36892_36892_0 is not ready yet (log entry for that part is being processed). │ Code: 234, e.displayText() = DB::Exception: No active replica has part babccf0c7ab1c3af920fb405ca79c901_36891_36895_1 or covering part, e.what() = DB::Exception │ Потеря реплики это обычный сценарии, верно? А он поломан. Не критично?

Пишите синхронно, чтоб данные были на обеих машинах, сейчас записи о данных в ZK есть, а на оставшейся машине их нет и взять ей неоткуда (смотрите insert_quorum).

Если insert_quorum поставлю в 2 (2 реплики) то перестанет писать сразу же как я остановлю 1 реплику, верно?

Подскажите, а имеет смысл вытаскивать в primary key поле eventDate если в WHERE оно фильтруется везде от начала месяца до конца? Будут ли использоваться оптимизации засечек при джоинах?

Если insert_quorum поставлю в 2 (2 реплики) то перестанет писать сразу же как я остановлю 1 реплику, верно?

Да

Господа, а где бы посмотреть принципы/пример заполнения дыр в time-series на уровне запросов? А то от всех моих вариантов начинают кровоточить глаза

Пишите синхронно, чтоб данные были на обеих машинах, сейчас записи о данных в ZK есть, а на оставшейся машине их нет и взять ей неоткуда (смотрите insert_quorum).

А не будут проблемы при неудавшихся вставках? Да и много ресурсов на кросс-репликацию.

Господа, а где бы посмотреть принципы/пример заполнения дыр в time-series на уровне запросов? А то от всех моих вариантов начинают кровоточить глаза

я обычно делаю что-то типа такого SELECT date, ... FROM ( SELECT toDate('2018-07-02') + number AS date FROM system.numbers LIMIT 7 ) ANY LEFT JOIN ( ...тут запрос, в результате которого могут быть "дыры" в датах... ) USING date

я обычно делаю что-то типа такого SELECT date, ... FROM ( SELECT toDate('2018-07-02') + number AS date FROM system.numbers LIMIT 7 ) ANY LEFT JOIN ( ...тут запрос, в результате которого могут быть "дыры" в датах... ) USING date

О! Спасибо! Не знал про system.numbers, извращался с range()

О! Спасибо! Не знал про system.numbers, извращался с range()

Я тоже :) SELECT arrayJoin(aligned).1 AS ts, arrayJoin(aligned).2 FROM ( WITH groupArray((ts, value)) AS series, toDateTime('2018-01-01 00:00:00') AS zero_time, range(4) AS range, 3600 AS step, arraySort(arrayMap(pos -> (zero_time + (step * pos), arrayFirst(t -> (t.1 = (zero_time + (step * pos))), series).2), range)) AS aligned SELECT aligned FROM timeserie GROUP BY metric )

Я тоже :) SELECT arrayJoin(aligned).1 AS ts, arrayJoin(aligned).2 FROM ( WITH groupArray((ts, value)) AS series, toDateTime('2018-01-01 00:00:00') AS zero_time, range(4) AS range, 3600 AS step, arraySort(arrayMap(pos -> (zero_time + (step * pos), arrayFirst(t -> (t.1 = (zero_time + (step * pos))), series).2), range)) AS aligned SELECT aligned FROM timeserie GROUP BY metric )

Во-во, а если еще добавить скользящее среднее, то при зачитывании вслух будет открываться портал в варп

А не будут проблемы при неудавшихся вставках? Да и много ресурсов на кросс-репликацию.

А с чего там сильно больше ресурсов? Там при вставке живые реплики из ZK проверяются + проверка что куски доехали, просто вставка медленнее.

Во-во, а если еще добавить скользящее среднее, то при зачитывании вслух будет открываться портал в варп

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

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

Чтобы отдельные большие значения не так сильно влияли на график

А с чего там сильно больше ресурсов? Там при вставке живые реплики из ZK проверяются + проверка что куски доехали, просто вставка медленнее.

А где-нибудь есть статьи о механике всего процесса? А то не везде понятно, на что можно рассчитывать и как правильно делать.

добрый день, скажите, возможно ли в будущем использовать удаление для distributed таблиц или иметь возможность на локальных таблицах делать ALTER TABLE DELETE ON CLUSTER test WHERE ...?

добрый день, скажите, возможно ли в будущем использовать удаление для distributed таблиц или иметь возможность на локальных таблицах делать ALTER TABLE DELETE ON CLUSTER test WHERE ...?

а что за where ?

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

так вы таблицу собираетесь удалять или что ?

например, у нас есть distributed таблица, которая размазанная на x серверов

не удалять

вообще не очень понимаю какие там условия могут быть

а удалять часть данных по критерию

в дистрибьютед таблице нет данных же

смотрите, например, мы неправильно залили первый месяц

да это вьюха на локальные таблицы

смысл в том, чтобы не ходить на каждый сервер а сделать операцию через on cluster

в дистрибьютед таблице нет данных же

Автор подразумевает, что мутационный запрос транслируется на нижележащие таблицы

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

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

сейчас не поддерживается on cluster для удаления

ON CLUSTER для ALTER DELETE должен поддерживаться

сейчас не поддерживается on cluster для удаления

Для альтер вроде поддерживается, по крайней мере все Альтеры я делаю он кластер

Для альтер вроде поддерживается, по крайней мере все Альтеры я делаю он кластер

delete?

Ну и делете наверно мне кажется тоже

наверное синтаксис у меня неверный, спасибо

Привет всем. За неделю запутался, читая чат. У нас есть кластер из 2-х машин КХ и 3-х машин ZK. Есть ReplicatedMergeTree, на которую навесили MaterializedView с движком MergeTree. Если данные попали в ReplicatedMergeTree, есть ли гарантия, что они окажутся и в MaterializedView, если все машины живы? Я понимаю, что в случае вылета КХ или ZK последствия могут быть рандомными, но если без вылетов?

Привет всем. За неделю запутался, читая чат. У нас есть кластер из 2-х машин КХ и 3-х машин ZK. Есть ReplicatedMergeTree, на которую навесили MaterializedView с движком MergeTree. Если данные попали в ReplicatedMergeTree, есть ли гарантия, что они окажутся и в MaterializedView, если все машины живы? Я понимаю, что в случае вылета КХ или ZK последствия могут быть рандомными, но если без вылетов?

В MV данные попадут только на той машине где запись, делайте MV реплицируемыми

О. Кажется, именно это мы и продолбали. Спасибо. :)

А где-нибудь есть статьи о механике всего процесса? А то не везде понятно, на что можно рассчитывать и как правильно делать.

Вот тут можно посмотреть про механику https://events.yandex.ru/lib/talks/5800/

Спасибо

Привет всем. За неделю запутался, читая чат. У нас есть кластер из 2-х машин КХ и 3-х машин ZK. Есть ReplicatedMergeTree, на которую навесили MaterializedView с движком MergeTree. Если данные попали в ReplicatedMergeTree, есть ли гарантия, что они окажутся и в MaterializedView, если все машины живы? Я понимаю, что в случае вылета КХ или ZK последствия могут быть рандомными, но если без вылетов?

как-то странно, когда сделали 5 машин вместо 2, но при выходе из строя одной последствия рандомные. получается менее устойчиво, нет?

как-то странно, когда сделали 5 машин вместо 2, но при выходе из строя одной последствия рандомные. получается менее устойчиво, нет?

Это не 5 вместо 2. Это 2 + 3. Даже при самой крутой и стабильной архитектуре вылет любого сервера может привести порою к рандому, если случится в "удачное" схождение звёзд.

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

Насколько я понимаю, поскольку у ClickHouse асинхронная репликация, то при выпадании одной ноды КХ данных потеряется не слишком много (только то, что не успело доехать). А при выпадании ZK ноды вообще ничего страшного не должно происходить, потому что он использует Paxos (или какой-то другой протокол для распределенного консенсуса). На практике, конечно, это всё стоит проверить :))

Спасибо, за ответ, ноя ничего не понял)) делать то что? Как понять на какой из реплик верные данные? Как их восстановить?

На той, где их больше, насколько я понимаю

А репликация через replicated.... таблицы или детская?

Replicated

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

Зукипер есть?

Да

А как проверяли что не совпадает? Т.е. для всяких replacing и agregating резултат select count() может зависеть от того завершился merge или нет.

sum по основным столбцам

и заливка остановлена? реплика видит данные с задержкой, если запрос sum идет 10 сек., будут разные результаты

Ну там значительно отличается

Ничего не стопил пока

а что показывает select from system.parts про партции этой таблицы? на обоих репликах

а что показывает select from system.parts про партции этой таблицы? на обоих репликах

Ну количество строк в таблице system.part разное

а replication_queue есть запросы на репликацию? странно это все

а replication_queue есть запросы на репликацию? странно это все

Вот тут куча строк и в поле last_exception connection timeout ошибки

Трабла со вчерашнего вопроса про dns, спасибо! Надо обновиться

а replication_queue есть запросы на репликацию? странно это все

Друг, спасибо тебе огромное!))))

ну значит реплика не может подключится к брату по http (9000) ?

ну значит реплика не может подключится к брату по http (9000) ?

Уже все)

можно мониторить типа : 'rep_future_parts') sql="select sum(value) from (select sum(future_parts) as value from system.replicas union all select toUInt64(0) as value)" ;; 'rep_parts_to_check') sql="select sum(value) from (select sum(parts_to_check) as value from system.replicas union all select toUInt64(0) as value)" ;; 'rep_stalled') sql="select sum(value) from (select count(*) as value from system.replication_queue where num_tries > 100 union all select toUInt64(0) as value)" ;;

Ок, спасибо)

Здравствуйте. Подскажите пожалуйста, Если гаснет нода zk follower - то clickhouse (если он подключен именно к этой ноде) теряет один пакет и переподключается. Если гаснет нода zk leader то таблицы переходят в readonly до сообщения в логе ZooKeeper session has expired. Switching to a new session. (60 секунд до этого момента проходит). Что яч делаю не правильно. Подскажите пожалуйста.

Здравствуйте. Подскажите пожалуйста, Если гаснет нода zk follower - то clickhouse (если он подключен именно к этой ноде) теряет один пакет и переподключается. Если гаснет нода zk leader то таблицы переходят в readonly до сообщения в логе ZooKeeper session has expired. Switching to a new session. (60 секунд до этого момента проходит). Что яч делаю не правильно. Подскажите пожалуйста.

А что не так?

Не хочется 60 секундного ридонли

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

А имеет смысл уменьшать zookeeper_session_expiration_check_period ? И чем это грозит?

А имеет смысл уменьшать zookeeper_session_expiration_check_period ? И чем это грозит?

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

Попробовал "insert_quorum" как тут советовали. В логах каждого сервера некоторое кол-во таких сообщении валится 2018.08.01 15:46:30.776377 [ 420 ] <Error> MetricsDistributed.Distributed.DirectoryMonitor: Code: 286, e.displayText() = DB::Exception: Received from 10.1.2.57:9000. DB::Exception: Quorum for previous write has not been satisfied yet. Status: version: 1 2018.08.01 15:47:21.476415 [ 421 ] <Error> MetricsDistributed.Distributed.DirectoryMonitor: Code: 286, e.displayText() = DB::Exception: Received from 10.1.1.183:9000. DB::Exception: Quorum for previous write has not been satisfied yet. Status: version: 1 2018.08.01 15:47:41.518425 [ 5462 ] <Error> executeQuery: Code: 286, e.displayText() = DB::Exception: Another quorum insert has been already started, e.what() = DB::Exception (from 10.1.1.249:52124) (in query: INSERT INTO MetricsDistributed FORMAT TabSeparated), Stack trace: 2018.08.01 15:47:41.578393 [ 5462 ] <Error> HTTPHandler: Code: 286, e.displayText() = DB::Exception: Another quorum insert has been already started, e.what() = DB::Exception, Stack trace: И самое непоиятно что появились опять дуюликаты хотя вьюх нету В коде нашел что транзакция откатывается но откуда тогда дубликаты? else if (multi_code == ZooKeeperImpl::ZooKeeper::ZNODEEXISTS && failed_op_path == quorum_info.status_path) { transaction.rollback(); throw Exception("Another quorum insert has been already started", ErrorCodes::UNSATISFIED_QUORUM_FOR_PREVIOUS_WRITE); }

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

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

Да, а как иначе если батч не прошел? Replaced движок это борьба с последствиями

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