Ладно, главное понятно наверное куда копать. В принципе можно бы наверное сделать чтобы те хосты которые думают что это задание "не для них" тоже как-то отмечались в в зукипере, чтоб было понятно что произошло.

вам большущее спасибо сейчас все переконфигурирую и если все ок то отпишу

Там сейчас есть подключ finished, мог бы быть какой-нибудь ignored.

да все работает отлично

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

ну а у меня то нормальные хостнеймы, а не IP

все хостнеймы резолвятся нормально

так рассказываю проблему, заходишь на сервер где не выполняется и смотришь файл /etc/hosts

там прописано типо 127.0.0.1 имяхостатут

и так быть не должно

разобрался почему так, у меня разные провайдеры и они хостс по разному конфигурят

Я удалалил из /etc/hosts строчку 127.0.1.1 имя_хоста А после этого нужно кликхаус перезагружать?

да

хотя по идее нет , но я перезагрузил

ну в system.clusters у меня по прежнему 127.0.1.1. Щас перезагружу.

Ура! Всё работает! Спасибо!

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

помолимся на Михаила и воздадим ему почести

Ура! Всё работает! Спасибо!

у меня вылез сайд эффект сломалась репилка из за изменени я хостов в целом понятно из за чего, завтра проанализирую и решу что делать

хм.. А напомните на какую метрику нужно смотреть что-бы понять сломалась она или нет

Ну я вижу в графане и своей админке

Ну и в еррор логе срач знатный июнь

Идёт

хм.. А напомните на какую метрику нужно смотреть что-бы понять сломалась она или нет

Например, так можно проверить, что всё хорошо: SELECT database, table, is_leader, is_readonly, is_session_expired, future_parts, parts_to_check, columns_version, queue_size, inserts_in_queue, merges_in_queue, log_max_index, log_pointer, total_replicas, active_replicas FROM system.replicas WHERE is_readonly OR is_session_expired OR future_parts > 20 OR parts_to_check > 10 OR queue_size > 20 OR inserts_in_queue > 10 OR log_max_index - log_pointer > 10 OR total_replicas < 2 OR active_replicas < total_replicas Если этот запрос ничего не возвращает - значит всё хорошо.

ок спс

Всем, привет. Интегрили ли вы с кликхаус с графаной? через графит или просто через подключение source в графане?

второй вариант почему-то не воспринимает временные ряды на графиках

Всем, привет. Интегрили ли вы с кликхаус с графаной? через графит или просто через подключение source в графане?

с графаной работает

Всем, привет. Интегрили ли вы с кликхаус с графаной? через графит или просто через подключение source в графане?

подключение через source нормально работает

с графаной работает

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

Всем, привет. Интегрили ли вы с кликхаус с графаной? через графит или просто через подключение source в графане?

В графане установить модуль (плагин) vertamedia-clickhouse-datasource

В графане установить модуль (плагин) vertamedia-clickhouse-datasource

установлен

данные видит, но графики с датой не строит, в респонсе вижу все данные получены корректно

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

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

Как я понял, с произвольный партиционированием grafana не заточена, она требует data колонку

Как я понял, с произвольный партиционированием grafana не заточена, она требует data колонку

пытался с датой как раз таки, и он показывает только первую дату

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

В дате точно корректные значение. Сама по себе data будет выводиться. Дефолтный запрос графаны к КХ отображается?

Где счётчик инзёртов

Странная ситуёвина. query графаны в струдию

момент

SELECT toDate(uploaded) as t, sum(size) AS Reqs FROM meta.upload_log GROUP BY toDate(uploaded) ORDER BY t desc

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

во вьюхе mutations есть записи. Во всех записях parts_to_do=0 is_done=1. Что-то еще не доделано?

выполнял пачку апдейтов. Большая часть "ушла" из mutations, а часть осталась

в merges ничего нет

Всем, привет. Интегрили ли вы с кликхаус с графаной? через графит или просто через подключение source в графане?

Просто соурс в графане

я так понимаю, что графики у всех сразу рисовались?

во вьюхе mutations есть записи. Во всех записях parts_to_do=0 is_done=1. Что-то еще не доделано?

Все ок , скоро и этим уйдут все доделалось

я так понимаю, что графики у всех сразу рисовались?

Да

на выходне такая ситуация, данные приехали, но по дате не раскладывается.

не понимаю в чем дело может быть

респонс тоже говорит, что все корректно

Привет, как рассчитывать железа о бод базу? Есть формула?

Естт только такая: заливаете 1/100 данных, смотрите сколько тянет, потом просто умножаете на 100

Привет, как рассчитывать железа о бод базу? Есть формула?

железо под базу это только чисто диски расчитать

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

респонс тоже говорит, что все корректно

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

Все ок , скоро и этим уйдут все доделалось

Спасибо

Привет всем! Только обнаружил что ReplicatedMergeTree таблица НЕ ВСЕГДА ТРИГЕРИТ записи в materialized приделанную локально. Случайно примерно половина записей не записываются в MV хотя она вроде как локально приделана к таблице. Это фича такая или бага? Это полностью выбило у меня понимание как вообще работает MV

Доброй ночи всем! У нас наблюдается проблема в логах и не на одной машине. 2018.10.01 22:09:12.787787 [ 7 ] <Error> void DB::BackgroundProcessingPool::threadFunction(): Code: 84, e.displayText() = DB::Exception: Directory /var/lib/clickhouse/data/cursometr/tests_question_answers_choices_local/tmp_merge_6-20181001_1293_1536_9/ already exists, e.what() = DB::Exception, Stack trace: 0. /usr/bin/clickhouse-server(StackTrace::StackTrace()+0x16) [0x9491e46] 1. /usr/bin/clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x22) [0x3019952] 2. /usr/bin/clickhouse-server(DB::MergeTreeDataMergerMutator::mergePartsToTemporaryPart(DB::MergeTreeDataMergerMutator::FuturePart const&, DB::MergeListEntry&, long, DB::DiskSpaceMonitor::Reservation*, bool)+0x53b0) [0x734fcc0] 3. /usr/bin/clickhouse-server(DB::StorageMergeTree::merge(bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)+0x45a) [0x7289dca] 4. /usr/bin/clickhouse-server(DB::StorageMergeTree::backgroundTask()+0x135) [0x728c985] 5. /usr/bin/clickhouse-server(DB::BackgroundProcessingPool::threadFunction()+0x43e) [0x72fd4be] 6. /usr/bin/clickhouse-server() [0x9e659ef] 7. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f51f392e6ba] 8. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f51f2f4f41d] 2018.10.01 22:09:12.823321 [ 3487792 ] <Error> ServerErrorHandler: Poco::Exception. Code: 1000, e.code() = 24, e.displayText() = I/O error: Too many open files, e.what() = I/O error Это вот кусок лога. И просто нонстопом валит и Too many open files и то, что какой-то путь уже существует в ЗК. Я так понял, что можно путь в ЗК шлепнуть?

Но откуда Too many open files?

Перед этим запускали мутации

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

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

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

Нет, у нас вставка пачками по несколько миллионов строк

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

У нас порядка 20 таблиц, запускали мутации по каждой из них, по одной мутации на таблицу. Все ок, но вот с одной какая-то беда случилась.

ну посмотрите систем мутейшенс

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

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

Вот костыль...

Ок, будем пробовать )

Спасибо!

Привет всем! Только обнаружил что ReplicatedMergeTree таблица НЕ ВСЕГДА ТРИГЕРИТ записи в materialized приделанную локально. Случайно примерно половина записей не записываются в MV хотя она вроде как локально приделана к таблице. Это фича такая или бага? Это полностью выбило у меня понимание как вообще работает MV

Это у вас где-то бага. Например, MV работает на таблице примерно 200 млн строк в сутки, за год данные по сумме совпадают в ррдительской и MV.

Вот костыль...

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

естественного способа пока нет но скоро будет

Это у вас где-то бага. Например, MV работает на таблице примерно 200 млн строк в сутки, за год данные по сумме совпадают в ррдительской и MV.

видимо когда CH пишет в реплику, то триггер на MV не срабатывает

видимо когда CH пишет в реплику, то триггер на MV не срабатывает

Вам надо создать реплицированные MV, и сверху них Distributed

Вам надо создать реплицированные MV, и сверху них Distributed

я сделал локальные MV от шардрв и видимо в этом ошибка?

Ну или дистр не обязательно, если шардов нет

Не, так нвло, просто надо с реплицированным движком

Не, так нвло, просто надо с реплицированным движком

есть пример конфига такого чтобы replicated sharded tables -> MV’s ?

Вот у вас есть MV - сделайте ее Replicated, а на другой реплике точно такую же

Куда бы данные не прилетали, они стригеррятся и по репликации приедут в MV

И так на каждом шарде, и потом Distributed для них

Что-то КХ с 18.12.17 оооооооооооочень долго дропает таблицы

Нет такой проблемы

А у нас есть :( После одной поломанной мутации у нас КХ пару дней жрал проц как не в себя, в итоге сегодня шлепнулся с Too many open files. Решили, что проще переналить данные, т.к. после чистки некоторых нод в ZK у нас посыпались ошибки с мисматчем хешей в таблицах, решили пересоздать и вот уже 30 минут мучаюсь и дропаю их. КХ просто зависает на дропе таблиц.

Куда бы данные не прилетали, они стригеррятся и по репликации приедут в MV

для MV надо <internal_replication>false</internal_replication> ?

А у нас есть :( После одной поломанной мутации у нас КХ пару дней жрал проц как не в себя, в итоге сегодня шлепнулся с Too many open files. Решили, что проще переналить данные, т.к. после чистки некоторых нод в ZK у нас посыпались ошибки с мисматчем хешей в таблицах, решили пересоздать и вот уже 30 минут мучаюсь и дропаю их. КХ просто зависает на дропе таблиц.

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

Если все части в зк зачем что то удалять в кх ?

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

Ну сценарий был такой, то в запросе на мутацию использовался подзапрос, который был без указания БД и шел в БД default в которой таблицы-то такой и не было. Мутация "упала".

Если все части в зк зачем что то удалять в кх ?

У нас все данные лежат во внешнем источнике.

В КХ льем только для агрегации сложных штук всяких

У нас все данные лежат во внешнем источнике.

Зачем тем более что то удалять?

Зачем тем более что то удалять?

Нам нужно остановит бесконечные ошибки типа missing part, checksu mismatch и пр. Кроме как шленуть таблицы, я другого способа не знаю. Может быть есть другой? )

для MV надо <internal_replication>false</internal_replication> ?

Надо true, если у вас репликация