Я уже удалил парт, завтра перезалью и посмотрим что будет

Можно ли применить bitOr в качестве агрегатной функции к столбцу? Или к массиву?

“это фича, не баг” - есть реплицируемая таблица, есть партиции, две реплики, если на одной из реплик сделать alter table … detach partition … запрос реплицируется без проблем, далее alter table … attach partition … - локально отработаеть норм, а на соседней реплике данных так и не будет. Оказывается подобные запросы надо делать на лидере. Вопрос в том, почему detach/attach работают так не предсказуемо (хоть бы ошибку показал)? ?

ой, если потом на лидере выполнить alter table … attach partition … данные будут реплицировать по новой и на соседней будет задваиваение данных ? это ж так круто!

version 1.1.54390

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

я потому и написал “это фича, не баг”. это такие тонкости КХ о которых надо знать, ибо будет очень весело это потом это исправлять..

Ну в этом плане они пока что логичные

с другой стороны так можно данные легко попортить. в доке об это сказано не очевидно. ИМХО запретить делать диттач не на лидере

А какая разница где сделать детач?

чтоб понимать где потом делать аттач ? ну или в документации описать внятно

А какая разница где сделать аттач?

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

я выше описал к чему это может привести

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

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

Кх просто увидит что парты такие уже есть и не будет реплицировать

в тестовой среде у меня выходит на одной реплике 2k зписей, на другой 1k, ранее везде было 1000

я думаю разработчики могут прояснить проблему и почему это работает так как работает.

я конечно могу замарочится написанием скрипта эмуляции поведения, но только если разработчики скажу “что то тут не то и это баг” ?

В доке есть такое ALTER TABLE [db.]table DETACH PARTITION 'name' … The query is replicated – data will be moved to the 'detached' directory and forgotten on all replicas. The query can only be sent to a leader replica. To find out if a replica is a leader, perform SELECT to the 'system.replicas' system table. Alternatively, it is easier to make a query on all replicas, and all except one will throw an exception. Но исключения нет ни в каком случае ? похоже таки на баг

Ну с детачем понятно

Проблема же не в нем

А в аттаче

Таких записей в логе много, и судя по всему из-за этого у меня мутация зависает примерно посередине. Вот и хочу разобраться как делать INSERT INTO чтобы таких больших блоков не появлялось

А они в любом случае появлятся будут, тут можно смотреть либо в сторону увеличения max_bytes_to_merge_at_min_space_in_pool либо уменьшения количества тредов для мержа. По сути это нормально что он откладывает мержи и ждет появления ресурсов. Насчет мутации не совсем понял, почему она должна зависить от insert'a?

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

так себе идея, можно на время отсановить запись и запустить insert into select и включить запись )

А они в любом случае появлятся будут, тут можно смотреть либо в сторону увеличения max_bytes_to_merge_at_min_space_in_pool либо уменьшения количества тредов для мержа. По сути это нормально что он откладывает мержи и ждет появления ресурсов. Насчет мутации не совсем понял, почему она должна зависить от insert'a?

А вот и я не знаю почему мутация не проходит, если делать её по таблице, заполненой через INSERT INTO

А вот и я не знаю почему мутация не проходит, если делать её по таблице, заполненой через INSERT INTO

Если есть пример для воспроизведения то, я думаю, @ztlpn с удовольствием посмотрит )

Если есть пример для воспроизведения то, я думаю, @ztlpn с удовольствием посмотрит )

Попробую сделать

Коллеги, привет. Есть около 1,5ТБ данных, запись и чтение каждую секунду, но небольшими партиями. Какие будут требования по железу? Понятно, что никаких HDD, только SSD. Два CPU, вопрос по объему RAM, читал что CH очень любит память.

И второй вопрос, по поводу репликации мастер-мастер, насколько повышенные требования к каналу между ДЦ?

а кто нибудь расширял зукипер с 3 нод до 5 ? нет ли каких то проблем?

Никаких

Коллеги, привет. Есть около 1,5ТБ данных, запись и чтение каждую секунду, но небольшими партиями. Какие будут требования по железу? Понятно, что никаких HDD, только SSD. Два CPU, вопрос по объему RAM, читал что CH очень любит память.

Это полностью зависит от вас. Для самого КХ памяти нужно немного. Остальное - память для запросов. Или должно целиком влазить или применять до определенной степени хитрости. С телефона неудобно подсказать, но поищите здесь по сообщениям что-то вроде query limit, будет ссылка на презентацию.

Коллеги, привет. Есть около 1,5ТБ данных, запись и чтение каждую секунду, но небольшими партиями. Какие будут требования по железу? Понятно, что никаких HDD, только SSD. Два CPU, вопрос по объему RAM, читал что CH очень любит память.

У нас такой объем на хдд нормально лежит, память наверно больше зависит не от данных а от запросов

И второй вопрос, по поводу репликации мастер-мастер, насколько повышенные требования к каналу между ДЦ?

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

По памяти у нас кстати ноды кх по шесть гигов памяти или по семь

А я поддерживаю официальные рекомендации clickhouse.yandex/docs/ru/operations/tips/ Памяти - чем больше, тем лучше. Идеально - если объем данных который необходим для большинства запросов будет помещаться в памяти. Т.е. если у вас 1.5 Тб данных, к примеру за год, а большая часть запросов запрашивают последний месяц и только половину колонок, то хорошо бы было если б у вас было получено крайней мере 1.5тб/12/2 примерно 64 Гб, больше - лучше. Если памяти достаточное количество, то количество обращений к диску минимально, и быстрый диск становится менее важен.

Доброе утро, в документации CH есть описание конфиг-файла ZK zoo.cfg, но там не прописаны ноды: #server.1=xxx.xxx.xxx.xxx:2888:3888 #server.2=xxx.xxx.xxx.xxx:2888:3888 Если их не указывать, ZK запускается в режиме standalone. Соответственно где прописывать ноды? Только в конфиге CH?

можно положить отдельным файликом в config.d

А, пардон, вы про сам zookeeper

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

Что-то типа такого: server.1=192.168.110.101:2888:3888 server.2=192.168.110.102:2888:3888 server.3=192.168.110.103:2888:3888

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

Спасибо, проблема в том, что при указании серверов кластера ZK, zk-сервер не стартует...

А они друг для друга доступны вообще?

Только 2 из трех, без кворума не стартанет вообще?

Ну а накой кластер без кворума?

спасибо, сейчас проделаю все тоже самое с кворумом

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

И 3 для зукипера мало, лучше 5 хотя бы

А с чем связано количество?

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

А... Я почему-то про быстродействие подумал.

А... Я почему-то про быстродействие подумал.

Быстродействие, наоборот, уменьшается Но что вам это абстрактное быстродействие? Главное, на сервера с КХ не кладите зукипер

Хотя да, соблазн положить рядом велик :)

Быстродействие, наоборот, уменьшается Но что вам это абстрактное быстродействие? Главное, на сервера с КХ не кладите зукипер

А можно поподробнее? Собственно так и хотели сделать, на серваках с CH развернули ZK. А как у вас реализовано?

ZK отдельно

Суть в том, что CH ест все доступные ресурсы. Если ZK не будет хватать ресурсов, он будет тупить, за ним сразу будет тупить CH. Это на графиках у нас выражалось в пиках снижения произвдительности/недоступности

Суть в том, что CH ест все доступные ресурсы. Если ZK не будет хватать ресурсов, он будет тупить, за ним сразу будет тупить CH. Это на графиках у нас выражалось в пиках снижения произвдительности/недоступности

ну или зажмет по памяти и его убьет оомкиллер что полностью парализует кластер

ну или зажмет по памяти и его убьет оомкиллер что полностью парализует кластер

Ну это вариант, скорее, из невероятных. Из опыта, быстрее упадет CH, если не тюнить OOM score

ZK отдельно

Т.е. если у меня 6 нод с CH разворачию столько же под ZK?

нет

кх отдельно зк отдельно

Под ZK есть смысл разворачивать нечетное кол-во нод

5 или 7

зк должно быть не четное количество

или 3

или 9

Можно и чётное, но смысла нет

Т.к. кворум = N/2+1

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

нет, не будет, он себя будет вести так, так будто у него N-1 нод

Ок, тогда еще вопрос, сколько нужно ресурсов под ноды ZK? Хотя бы примерно.

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

но и данных в кх у меня немного

сам зк потребляет чуть меньше 200 мб

данных всего поллтора тб

ну и ложу я их правильно пачками и редко

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

В самом зукипере сейчас порядка 130к записей

Спасибо, т.е. я сейчас делаю 5 нод под ZK, прописываю их в config.xml в CH и zoo.cfg на всех нодах ZK,а после этого просто создаю Replicated* таблицы в КХ? Ничего не упустил из виду? На нодах с CH ведь все равно нужны клиенты ZK?

не нужны клиенты зк

кх умеет сам в них ходить

кх умеет сам в них ходить

ммм, понятно

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

восстановить одну ноду из последнего работающего бекапа, у остальных прибить базу.

Потом долго и нудно делать attach на сброшенные партиции...

Можно подробнее? Я всегда думал что zk нужен Только для репликации, те упал зукипер, нет репликации... И все. Зачем прибивать данные и делать аттач?

прибивать данные надо в зк

А

чтобы не было конфиликта данных

Ноду

А можно прибить ноду рутовую

Оно пересоздать?

Пересоздаст?

что такое рутовая нода ?

речь про фс или про содержимое зк?