Да это понятно. Вопрос в сохранении кворума. Интересно в топологии 3 обычные ноды + 2 обсервера, указывая в конфиге ZK 3 RW ноды, если две из RW нод умрут, будет ли работать репликация и Zкластер в принципе, когда имеется 1 RW нода и 2 обсервера.

Ибо если среди 3 обычных Z-ноды 2 умирают, последняя становится тыквой, и репликация CH тоже становится тыквой.

Почитал доку зукипер, в Обсервер можно писать и он передает это лидеру и ждёт ответа от лидера. Но Обсервер не часть ансамбля поэтому кворум он не саппортит и ничем не поможет если 2 ноды ансамбля умрут.

Крайне странная реализация тогда, какой смысл делать было ноды, толерантные к сетевым задержкам, если сами по себе они тыквы и не могут обеспечить работу ансамбля. В общем вряд ли ZK Observers могут быть как-то полезны для георезервирования репликации ZK.

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

Вот и я об этом думаю. Но use case Apache ZK гласит, что Observers для того и придумывались. "As a datacenter bridge: Forming a ZK ensemble between two datacenters is a problematic endeavour as the high variance in latency between the datacenters could lead to false positive failure detection and partitioning. However if the ensemble runs entirely in one datacenter, and the second datacenter runs only Observers, partitions aren't problematic as the ensemble remains connected. Clients of the Observers may still see and issue proposals." Возможно, для специфических случаев, когда клиенты подключающиеся к ZK имеют низкий таймаут и не могут выдержать подключения к ансамблю в другом ДЦ)

Странное решение, как по мне - иметь кворум в одном ДЦ. Умрёт ДЦ и репликация - тоже тыква.

Да, но разделять кворум по 2 ДЦ тоже плохо - может лагать)) Палка о 2 концах

Лаг не так страшен

Как блок записи

У меня ноды кх в США есть, а зк все в Германии и вроде никаких проблем

Вот и я об этом думаю. Но use case Apache ZK гласит, что Observers для того и придумывались. "As a datacenter bridge: Forming a ZK ensemble between two datacenters is a problematic endeavour as the high variance in latency between the datacenters could lead to false positive failure detection and partitioning. However if the ensemble runs entirely in one datacenter, and the second datacenter runs only Observers, partitions aren't problematic as the ensemble remains connected. Clients of the Observers may still see and issue proposals." Возможно, для специфических случаев, когда клиенты подключающиеся к ZK имеют низкий таймаут и не могут выдержать подключения к ансамблю в другом ДЦ)

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

Есть ли цель для сборки только "клиентских" библиотек? Вижу есть dbms, но он собирает ВСЁ. Нужные исходники не получается перечислить.

Есть ли цель для сборки только "клиентских" библиотек? Вижу есть dbms, но он собирает ВСЁ. Нужные исходники не получается перечислить.

Вроде была опция только клиента собрать. Возможно закопана в переменных cmake

Кажется, что вряд ли. Потому что CH это один монолитный бинарник.

Удивительно, зачем они его на несколько деб пакетов разбивают тогда

Ну там есть общая зависимость clickhouse-common-base что ли.

ты кажется прав

ну и там дальше set (CLICKHOUSE_ALL_TARGETS clickhouse-server clickhouse-client clickhouse-local clickhouse-benchmark clickhouse-performance-test clickhouse-extract-from-config clickhouse-format)

Есть ли цель для сборки только "клиентских" библиотек? Вижу есть dbms, но он собирает ВСЁ. Нужные исходники не получается перечислить.

Недавно появилось - -DENABLE_CLICKHOUSE_ALL=0 -DENABLE_CLICKHOUSE_CLIENT=1 - можно собрать только клиента, если именно бибилиотеку - то цель зовут clickhouse-client-lib но пока смысла мало, все всеравно зависит от dbms который слишком большой клубок и распутывать его еще долго

В принципе-то все равно не так долго билдится

Интересно, насколько трудно будет это все в модули мигрировать

Недавно появилось - -DENABLE_CLICKHOUSE_ALL=0 -DENABLE_CLICKHOUSE_CLIENT=1 - можно собрать только клиента, если именно бибилиотеку - то цель зовут clickhouse-client-lib но пока смысла мало, все всеравно зависит от dbms который слишком большой клубок и распутывать его еще долго

От MongoDB, DataODBC, zookeeper получается всё ещё зависит?

Интересно, насколько трудно будет это все в модули мигрировать

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

От MongoDB, DataODBC, zookeeper получается всё ещё зависит?

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

https://github.com/yandex/ClickHouse/tree/master/utils/travis - вот тут примеры как можно максимально сократить время сборки

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

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

почти прозрачно, если оторвал и не собралось - значит зависит 8)

https://github.com/yandex/ClickHouse/tree/master/utils/travis - вот тут примеры как можно максимально сократить время сборки

Классно. Ещё я на билдскрипт kmeow подсматривал. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=clickhouse#n59

У меня тут появился некоторый интерес по запуску ClickHouse в контейнерах и интересно было бы почитать о каких-нибудь success stories по этому поводу. Интересны, в первую очередь: rkt, porto, lxc ну и о docker тоже можно. По porto, по понятным причинам - это всё к Яндекс, кое что есть тут https://www.youtube.com/watch?v=2QJgCTF1cIE , но может где-то что-то есть ещё?

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

Я бы сказать честно лучше бы сам эти образы собирал в данном случае

В lxc ещё у меня крутиться тестовый кх, вроде никаких проблем не наблюдаю

У меня тут появился некоторый интерес по запуску ClickHouse в контейнерах и интересно было бы почитать о каких-нибудь success stories по этому поводу. Интересны, в первую очередь: rkt, porto, lxc ну и о docker тоже можно. По porto, по понятным причинам - это всё к Яндекс, кое что есть тут https://www.youtube.com/watch?v=2QJgCTF1cIE , но может где-то что-то есть ещё?

запускать для production или для разработки?

запускать для production или для разработки?

Для создания нового продукта, что-то вроде cloud-native clickhouse ;)

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

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

Да вроде не падает, каких то подводных камней вроде тоже не было

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

память в основном надо тюнить под "малый размер" меньше background операций

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

Добрый день! Может кто-нибудь знает в каком направлении копать / как решить проблему? Используется async python драйвер, запросы отправляются в 4 потока. Сначала все нормально, но потомк вылезает ошибка clickhouse_driver.errors.NetworkError: Code: 210. Device or resource busy (localhost:9000) Сервер GCP, свежий, установлены только clickhouse, pandas, + python драйвер для кх. Понимаю, что скорее всего не под адресу, но все может кто сталкивался.

А что за драйвер?

А что за драйвер?

https://github.com/mymarilyn/aioch

Судя по всему, aioch. И судя по сорцам либы, должен использоваться executor, т.е. асинхронность не нативная, а реализована на отдельных процессах/тредах/etc. Что логически наводит на мысль о том, почему ошибка возникла. Вывод: не делать к кх из питона асинхронные запросы, по крайней мере с этой либой. Попробуйте какой-нибудь асинхронный одбц клиент (если для кх реализован одбц интерфейс, не в курсе, есть ли он)

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

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

А зачем вам асинхронность вообще с кх? Так много конкурентных запросов?

Ещё и с пандасом, так что могу предположить, что нужно просто разово (+/-) загрузить результаты запроса

да, необходимо делать перебор (~миллион комбинаций для arrayExists в where), в пандасе пробовал делать - слишком медленно, через БД быстрее, но хотелось бы еще быстрее, чтобы не сутки ждать пока все варианты не переберутся, а часа 4 хотя бы

Раз тут зашло за клиенты CH, то может быть кто0то знает в чём может быть дело. Линкуюсь статически и пытаюсь создать соединение в лоб. Но, когда уничтожаются объекты Connection, ConnectionTimeouts и закрывается логгер Poco, бросается SIGSEGV на мьютексе. Нельзя использовать коннектшены как это делаю я или как-то нужно инициализировать и разрушать Poco явно? https://pastebin.com/saHpsW25

да, необходимо делать перебор (~миллион комбинаций для arrayExists в where), в пандасе пробовал делать - слишком медленно, через БД быстрее, но хотелось бы еще быстрее, чтобы не сутки ждать пока все варианты не переберутся, а часа 4 хотя бы

Я бы залил все варианты как внешний словарь и одним запросом перебрал все комбинации на стороне бд

Я бы залил все варианты как внешний словарь и одним запросом перебрал все комбинации на стороне бд

По крайней мере, попробовал бы:)

Добрый день! На VPS на примонтированном диске случился зависон, в результате <Error> (Data): Considering to remove broken part /mnt/volume-fra1-01/clickhouse//data/mybase/postback/20180401_20180401_1463046_1463046_0 because it's impossible to repair. Файла по указанному пути не существует. Нагуглить пока ничего не удалось.

пока что перегружать сервис не пробовал, но как обнаружил проблему, попробовал его стопнуть - подвис. принял решение ребутнуть машину. Очень долго поднималась, но ура - поднялась. Реплики нет. Одна нода. Буду признателен за любую наводку.

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

не поднимается сервис

а проверку диска делали после рестарта ?

что там вообще с файлухой в итоге ?

нет, пока не делал. посмотрю.

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

это digitalocean - во франкфурте.

FRA1 - у них диски полетели видимо

сегодня поднял там один сервер у до

стопаться упорно не хочет. Повис уже минут 5 как. /etc/init.d/clickhouse-server stop Stop clickhouse-server service:

стопаться упорно не хочет. Повис уже минут 5 как. /etc/init.d/clickhouse-server stop Stop clickhouse-server service:

Был ребут после последнего обновления? В какой то версии что-то меняли в инит скрипте

вообще, как не печально, это прод и апдейт давно не накатывался. В пн планировали садиться и делать реплики, но вот он - рок судьбы )

Кстати на ДО до сих пор 1 hour ago Our engineering team continues to work on a fix for the issue with Block Storage in our FRA1 region. We appreciate your patience and will post an update as soon as additional information is available.

Но желательно взглянуть что там ио

iotop -oa

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

да, необходимо делать перебор (~миллион комбинаций для arrayExists в where), в пандасе пробовал делать - слишком медленно, через БД быстрее, но хотелось бы еще быстрее, чтобы не сутки ждать пока все варианты не переберутся, а часа 4 хотя бы

Переписал все на asyncio / aiohttp и http клиент, не помогло

Администраторы чата, дабы содержать его в чистоте, рассмотрите возможность запуска сюда бота против спамеров - например вот https://tgcreator.ru/bot/cleanerchatbot

Всем добрый вечер! Уважаемые знатоки, подскажите одну вещь? Есть кластер 4х2 (4 шарда, 2 реплики). Есть таблица ReplicatedMergeTree, поверх нее есть Distributed. Мне необходимо раз в сутки чистить данные в этой таблице, которые старше недели от текущего дня. Ключ партиционирования - колонка с типом Date. Я на сервере могу выполнить запрос на получение всех кусков таблицы, но вопрос в том, что я получаю локальные куски...если мне нужн подчистить данные на всем кластере, то это мне ходить потребуется по всему кластеру?

Что бы собрать информацию о чем чистить, т.к. partition в system.parts указывается как месяц, например 201802, а не как день...

а как чистить планировал? тоже есть подобная задача архивации

а как чистить планировал? тоже есть подобная задача архивации

Через DROP PARTITION

я думал архивировать как то

Только вот не понятно одно - нужно ли по кластеру ползать и собирать партиции, которые можно шлепнуть? )

Ну можно сделать detach и архивировать

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

Похоже придется по всему кластеру ездить и собирать партиции :( Еще проблема с тем, что запрос на удаление партиции реплицируется и тут как бы не знаешь где реплика, где что :) Нужно писать определялку (

Блин, судя по названиям партиций, Clickhouse при указании колонки типа Date в качестве ключа партиционирования наваливает данные в партции по месяцам...

Верно, ну можно чистить просто реже

https://clickhouse.yandex/docs/ru/table_engines/custom_partitioning_key/

Блин, судя по названиям партиций, Clickhouse при указании колонки типа Date в качестве ключа партиционирования наваливает данные в партции по месяцам...

Я уже нашел пример с данными за неделю. Можно использовать toStartOfDay()

Я уже нашел пример с данными за неделю. Можно использовать toStartOfDay()

Ура! Оно работает! :) Теперь гораздо проще партиции разбирать на запчасти!