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

Привет Подскажите, пожалуйста Периодически разваливается реплика Кликхауса с таким вот сообщением в логе 2017.03.28 12:31:14.818651 [ 3297 ] <Error> HTTPHandler: Code: 999, e.displayText() = zkutil::KeeperException: connection loss, path: /clickhouse/tables/nz/1/zos2/temp/abandonable_lock-, e.what() = zkutil::KeeperException, Stack trace: 0. /usr/bin/clickhouse-server(StackTrace::StackTrace()+0x16) [0x1224296] 1. /usr/bin/clickhouse-server(DB::Exception::Exception(std::string const&, int)+0x1f) [0xf88dbf] 2. /usr/bin/clickhouse-server(zkutil::KeeperException::KeeperException(int, std::string const&)+0x6b) [0x12ea4bb] 3. /usr/bin/clickhouse-server(zkutil::ZooKeeper::tryCreate(std::string const&, std::string const&, int, std::string&)+0x52) [0x2ad5ac2] 4. /usr/bin/clickhouse-server(zkutil::ZooKeeper::create(std::string const&, std::string const&, int)+0x47) [0x2ad5b37] При этом в логе Zookepeer вот такое 2017-03-28 12:21:29,689 [myid:3] - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@362] - Exception causing close of session 0x35b0f9728470000 due to java.io.IOException: Len err or 1097666 2017-03-28 12:21:29,689 [myid:3] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1008] - Closed socket connection for client /10.244.2.162:33026 which had sessionid 0x35b0f9728 470000 Помогает только рестарт Зукипера и последующий рестарт Кликхауса Может кто сталкивался с такой проблемой?

Вряд ли могу сказать что-то конкретное. Число, о котором идёт речь в сообщении об ошибке - чуть больше 1 МБ, что является ограничением по-умолчанию на размер узла, размер пакета, отправляемого по сети в ZK. Попробуйте посмотреть, нет ли слишком больших нод в ZK, и не передаются ли слишком большие пакеты: strace -f -e trace=network -p $(pidof clickhouse-server) tcpdump Недавно исправляли похожую проблему: на сервере с очень большим количеством таблиц типа ReplicatedMergeTree, после переполнения zxid в ZK (глобальный счётчик транзакций, максимум 2^31 - 1) и потери сессии, сервер не мог установить новую сессию, так как отправлял в ZK слишком большое количество watch-ей и размер пакета выходил за рамки ограничения. Может быть здесь что-то похожее.

Привет! А нет ли где-нибудь рекомендаций по настройке ZooKeeper-кластера для ClickHouse? Что именно интересует: 1. Сколько инстансов ZooKeeper имеет смысл использовать в зависимости от количества шардов и реплик ClickHouse. 2. На что прежде всего обратить внимание при выборе железа под ZooKeeper, к чему он наиболее требователен в связке с ClickHouse? 3. Есть ли преимущества у схемы, когда ZooKeeper живёт на одном железе с ClickHouse? Или лучше под него использовать отдельные сервера? 4. Допустим, сервера ClickHouse у нас живут в двух дата-центрах, между ними настроена перекрёстная репликация. Мы заводим в каждом из дата-центров по 2 сервера ZooKeeper. Что будет с работоспособностью системы, если один дата-центр прилёг? Смогут ли 2 сервера ZooKeeper из живого дата-центра договориться между собой, и, соответственно, смогут ли ClickHouse-ы в этом дата-центре продолжать нормальную работу?

Привет! А нет ли где-нибудь рекомендаций по настройке ZooKeeper-кластера для ClickHouse? Что именно интересует: 1. Сколько инстансов ZooKeeper имеет смысл использовать в зависимости от количества шардов и реплик ClickHouse. 2. На что прежде всего обратить внимание при выборе железа под ZooKeeper, к чему он наиболее требователен в связке с ClickHouse? 3. Есть ли преимущества у схемы, когда ZooKeeper живёт на одном железе с ClickHouse? Или лучше под него использовать отдельные сервера? 4. Допустим, сервера ClickHouse у нас живут в двух дата-центрах, между ними настроена перекрёстная репликация. Мы заводим в каждом из дата-центров по 2 сервера ZooKeeper. Что будет с работоспособностью системы, если один дата-центр прилёг? Смогут ли 2 сервера ZooKeeper из живого дата-центра договориться между собой, и, соответственно, смогут ли ClickHouse-ы в этом дата-центре продолжать нормальную работу?

> 4. 2 сервера из 4 не смогут договориться. Лучше держать три сервера - два в одном ДЦ и один в другом. При недоступности более крупного ДЦ, система будет целиком недоступна на запись. При недоступности ДЦ с одной нодой ZK, система будет доступна на запись только в доступном ДЦ (изнутри изолированного ДЦ писать в ClickHouse не получится). При этом, на чтение система доступна всегда, но может отдавать отстающие данные. А если ДЦ равнозначны, и хочется сохранять плавучесть при недоступности любого, то минимум, получается, по 3 сервера ZK в каждом ДЦ?

6 ZK ведь смогут договориться? Тогда просто кворум будет = 4, правильно?

или, если КХ у вас не является первичным хранилищем, вам вообще не нужна связь между ДЦ, нужно просто переливать данные из SSOT

Вот ещё кстати вопрос. В чем коренная особенность того что CH не любит мелкие вставки? Ведь по сути слияние не будет долгим. Цена коннекта в CH вроде тоже не высока.

На каждый INSERT создаётся "кусок" в файловой системе. Он представляет собой набор из некоторого количества файлов - по два файла на каждый столбец + индекс и два файла с метаданными. Поэтому создание куска - весьма тяжёлая операция, особенно для широких таблиц. Кроме того, для ReplicatedMergeTree, на каждый кусок делается несколько транзакций в ZK, что представлет собой несколько сетевых roundtrip-ов.

На каждый INSERT создаётся "кусок" в файловой системе. Он представляет собой набор из некоторого количества файлов - по два файла на каждый столбец + индекс и два файла с метаданными. Поэтому создание куска - весьма тяжёлая операция, особенно для широких таблиц. Кроме того, для ReplicatedMergeTree, на каждый кусок делается несколько транзакций в ZK, что представлет собой несколько сетевых roundtrip-ов.

Ясно, т.е. для CH особой разницы не будет, если сделать 2 инсерта по 1кк или 1 инсерт с 2кк?

да, все верно, в примерах нет обработки ошибок, например https://github.com/kshvakov/clickhouse/blob/master/examples/simple.go#L42 , если Prepare вернет ошибку, то и statement будет nil и Exec/Query будут падать при обращении к нему. Чуть позже добавлю обработку ошибок в примеры чтоб небыло подобных проблем

привет! я правильно понимаю, что для изменения параметра output_format_json_quote_64bit_integers надо прописать в config.xml <output_format_json_quote_64bit_integers>true</output_format_json_quote_64bit_integers> ?

именно пользователей, а не профиля?

подскажи пожалуйста, а ATTACHE DETACH можно применять к distributed таблице? я хочу посредтом атач детач переместить данные с одной таблици в другую, но ходить по репликам как-то не хочется, хотя наверное прийдется потому как данные складываются в deattach папку той балици где они(данные) находились

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

Коллеги, а как лучше получить результаты запроса, когда они не влезают в память клиента? Стрим/батч какой-то бывает?

Клиент на каком яп?

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

Именно клиента, да

Вечер добрый. А кто как решает задачу кеширования ответов сервера? А нас идея - есть основная таблица, куда поступают данные, есть MaterializedView с SummingMergeTree движком. Перед основным запросом, делаем запрос на MaterializedView, чтобы убедиться, что есть новые данные (запоминаем у себя значение суммы счетчиков). И если есть новые данные, то выполняем уже основной запрос, если нет, отдаем юзеру данные из кеша. Минус в том, что приходится делать вместо одного - два запроса. Но если на основной запрос сервер отвечает за десятки миллисекунд, а на запрос к MaterializedView за единицы миллисекунд, то вроде как такой подход нормальный. Что думаете?