Значит в какой-то момент их было нечетное число.

четверо не будут работать?

у zk не может быть сплитбрейна

у каждого свой ИД, и конфиг сосписком из 5 нод

у zk не может быть сплитбрейна

Ахахаха ну расскажите мне как этого не может быть когда у меня был сплит Брейн у ЗК ))

может, если будет 2 кластера из 5 нод(3 в старом и 2 в новом)

и я вижу, что кластер из 4х нод ЗК работал вполне успешно

Ахахаха ну расскажите мне как этого не может быть когда у меня был сплит Брейн у ЗК ))

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

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

четверо не будут работать?

Будут, но это только замедлит работу. Что при 3-х что при 4-х ЗК будет считать что может работать при 2-х живых нодах

Будут, но это только замедлит работу. Что при 3-х что при 4-х ЗК будет считать что может работать при 2-х живых нодах

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

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

Да, вечер уже) половина +1

В любом случае нет смысла в 4-з

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

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

Всем привет! Товарищи, а ALTER DETACH вдруг в каких-то последних релизах не стал реплицируемым?

А то мы тут апдейтнулись и у нас DETACH как-то странно начал сообщать с ошибкой доступа к реплике, хотя казалось бы откуда он про нее знал бы.

детач всегда вроде был реплицируемым

> CREATE, DROP, ATTACH, DETACH and RENAME queries are executed on a single server and are not replicated:

https://clickhouse.yandex/docs/en/operations/table_engines/replication/

нет

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

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

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

Еще вопрос по словарям: словарь на миллион строк (каждая по 1 кб) - это нормально будет работать?

Еще вопрос по словарям: словарь на миллион строк (каждая по 1 кб) - это нормально будет работать?

А почему не должен? ) ограничивается все вашей оперативкой

А почему не должен? ) ограничивается все вашей оперативкой

ну да, я примерно так и думал

словари из-за своего внутреннего устройства кушают очень много памяти, я бы проверил сначала, а то окажется что 100500 ГБ надо, и чем больше колонок тем хуже * кол-во колонок https://github.com/yandex/ClickHouse/issues/2738

словари из-за своего внутреннего устройства кушают очень много памяти, я бы проверил сначала, а то окажется что 100500 ГБ надо, и чем больше колонок тем хуже * кол-во колонок https://github.com/yandex/ClickHouse/issues/2738

это хорошее замечание, у меня собственно будет 3 колонка: UInt32 ключ, строка - name, UInt8 - enabled

не пытайтесь сделать complex hash tuple(UInt32) , делайте просто хеш (там UInt64), сэкономите по памяти.

не пытайтесь сделать complex hash tuple(UInt32) , делайте просто хеш (там UInt64), сэкономите по памяти.

не буду

@milovidov_an какой у вас размер ZK snaptshot, и средняя latency? Видете ли вы часто такие ошибки? fsync-ing the write ahead log in SyncThread:3 took 8773ms which will adversely effect operation latency. See the ZooKeeper troubleshooting guide

Да, у нас полно таких сообщений. Доходит до 56 сек. И это действительно приводит к проблемам (operation timeout, потом session expired в течение нескольких секунд, потом сессия восстанавливается).

а как боретесь с этой проблемой? насколько я понял session timeout/connection timeout приводит к тому чтобы выйти из потоков выполнения запросов, мерджей и репликаций на всех узлах? или немного не так?

select 1 where [1, 2, 3] in (1) Received exception from server (version 18.12.17): Code: 53. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Type mismatch in IN or VALUES section. Expected: Array(UInt8). Got: UInt64. мне кажется или подобное работало в прошлых версиях?

> CREATE, DROP, ATTACH, DETACH and RENAME queries are executed on a single server and are not replicated:

это не про ALTER это CREATE table, DROP table, ATTACH table, DETACH table, RENAME table, и они не реплицируются

а как боретесь с этой проблемой? насколько я понял session timeout/connection timeout приводит к тому чтобы выйти из потоков выполнения запросов, мерджей и репликаций на всех узлах? или немного не так?

Да, мержи и INSERT-ы прерываются. SELECT - нет. Никак не боремся (видимо это всё-таки не часто). Надо посмотреть внимательнее.

-rw-r--r-- 1 zookeeper zookeeper 12842886606 сент. 25 20:34 snapshot.1fc176e33dc -rw-r--r-- 1 zookeeper zookeeper 12760562728 сент. 25 20:49 snapshot.1fc1794424b -rw-r--r-- 1 zookeeper zookeeper 12793824568 сент. 25 21:05 snapshot.1fc17c08e33 -rw-r--r-- 1 zookeeper zookeeper 13027591876 сент. 25 21:17 snapshot.1fc17df65b3 -rw-r--r-- 1 zookeeper zookeeper 13025550056 сент. 25 21:29 snapshot.1fc18005e6a -rw-r--r-- 1 zookeeper zookeeper 12940927972 сент. 25 21:45 snapshot.1fc182c1969 -rw-r--r-- 1 zookeeper zookeeper 12572519779 сент. 25 21:53 snapshot.1fc184384af -rw-r--r-- 1 zookeeper zookeeper 12872448244 сент. 25 22:09 snapshot.1fc186ee6fb -rw-r--r-- 1 zookeeper zookeeper 12749795736 сент. 25 22:19 snapshot.1fc1889f829 -rw-r--r-- 1 zookeeper zookeeper 12820889937 сент. 25 22:35 snapshot.1fc18b66faa -rw-r--r-- 1 zookeeper zookeeper 12664672285 сент. 25 22:45 snapshot.1fc18d08ab1 -rw-r--r-- 1 zookeeper zookeeper 13024532335 сент. 25 22:58 snapshot.1fc18f4ca23

Посмотрели, что возрастания latency происходят, в основном, во время purge в ZK.

Добрый день, пара вопросов назрела: 1) обычно при создании каунтеров делают аггрегированные интервалы (например, по дню). В моем случае без агрегации счетчики за несколько месяцев считаются быстро в КХ, а вот за год начинают притормаживать из-за количества евентов. Стоит ли делать агрегированние, скажем, по месяцам или есть другой способ? 2) у меня предполагается словарь на 100 мб чистых данных (не знаю пока во сколько КХ развернет это), но обновление элементов в нем может происходить до раза в несколько секунд. Имеет ли смысл его порезать на 10 или 100 словарей и обновлять только то, что нужно? Это вообще нормальный подход?

Добрый день, пара вопросов назрела: 1) обычно при создании каунтеров делают аггрегированные интервалы (например, по дню). В моем случае без агрегации счетчики за несколько месяцев считаются быстро в КХ, а вот за год начинают притормаживать из-за количества евентов. Стоит ли делать агрегированние, скажем, по месяцам или есть другой способ? 2) у меня предполагается словарь на 100 мб чистых данных (не знаю пока во сколько КХ развернет это), но обновление элементов в нем может происходить до раза в несколько секунд. Имеет ли смысл его порезать на 10 или 100 словарей и обновлять только то, что нужно? Это вообще нормальный подход?

Если событий много, а нужно их анализировать за широкий диапазон дат - то да, предварительная агрегация имеет смысл. В кликхаус это очень удобно делать с помощью Materialized View в таблицу с движком AggregatingMergeTree. Тогда всякие "неудобные" в агрегации метрики (типа количества уникальных пользователей) можно корректно суммировать.

Добрый день, пара вопросов назрела: 1) обычно при создании каунтеров делают аггрегированные интервалы (например, по дню). В моем случае без агрегации счетчики за несколько месяцев считаются быстро в КХ, а вот за год начинают притормаживать из-за количества евентов. Стоит ли делать агрегированние, скажем, по месяцам или есть другой способ? 2) у меня предполагается словарь на 100 мб чистых данных (не знаю пока во сколько КХ развернет это), но обновление элементов в нем может происходить до раза в несколько секунд. Имеет ли смысл его порезать на 10 или 100 словарей и обновлять только то, что нужно? Это вообще нормальный подход?

Со словарём - обновление 100Мб словаря раз в несколько секунд - звучит так себе. Если есть возможность НЕ делать этого (например разделив словари) то лучше этого не делать.

Добрый день, пара вопросов назрела: 1) обычно при создании каунтеров делают аггрегированные интервалы (например, по дню). В моем случае без агрегации счетчики за несколько месяцев считаются быстро в КХ, а вот за год начинают притормаживать из-за количества евентов. Стоит ли делать агрегированние, скажем, по месяцам или есть другой способ? 2) у меня предполагается словарь на 100 мб чистых данных (не знаю пока во сколько КХ развернет это), но обновление элементов в нем может происходить до раза в несколько секунд. Имеет ли смысл его порезать на 10 или 100 словарей и обновлять только то, что нужно? Это вообще нормальный подход?

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

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

+1. Мы для таких "словарей" используем таблицу с движком MySQL - очень удобно

А могу я для борьбы с бесконечно мерджащимся блоком просто удалить блоки на сбойной ноде, она подтянет отсутствующие с реплик ?

что происходит, когда одна из нод КХ стартует и не находит данных в ФС ?

что происходит, когда одна из нод КХ стартует и не находит данных в ФС ?

смотря каких данных. Если вообще ничего - создаст

смотря каких данных. Если вообще ничего - создаст

А если только 3-4 блоков, которые он пытается смерджить уже сутки, каждые 3 минуты сбрасывая результаты ?

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

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

Кто знает?

всем, привет. Скажите, пожалуйста, есть ли какое-либо решение для версионирования ddl. clickhouse?

всем, привет. Скажите, пожалуйста, есть ли какое-либо решение для версионирования ddl. clickhouse?

https://github.com/golang-migrate/migrate Мы просто ручками в файлики пишем, не так часто это нужно

https://github.com/golang-migrate/migrate Мы просто ручками в файлики пишем, не так часто это нужно

спасибо

Расскажите чем отличаются активные и неактивные партиции. Мне фризить только активные надо? А бэкапить нужно тоже только активные или все?

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

Хоту забэкапить всю таблицу, в таблице есть активные и неактивные партиции. Как быть? Что вообще обзначают активные и неактивные?

Это те которые изменяться больше не будут или те которые уже совсем ненужны и их удалить можно?

бекапить надо все )

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

все не нужное кх удаляет сам

18.12.4 получаю ошибку Code: 171. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Block structure mismatch in UNION stream: different names of columns: когда в WHERE 2 условия, каждое из условий по отдельности отрабавтывают нормально, что делать?)

18.12.4 получаю ошибку Code: 171. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Block structure mismatch in UNION stream: different names of columns: когда в WHERE 2 условия, каждое из условий по отдельности отрабавтывают нормально, что делать?)

покажите запрос и таблицу

бекапить надо все )

А фризить тоже все?

А фризить тоже все?

ну там же парты актив не актив , а не партишены

18.12.4 получаю ошибку Code: 171. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Block structure mismatch in UNION stream: different names of columns: когда в WHERE 2 условия, каждое из условий по отдельности отрабавтывают нормально, что делать?)

тоже натыкался на Block structure mismatch, но issue без ответа https://github.com/yandex/ClickHouse/issues/3162

насколько помню парты вроде фризить нельзя или уже стало можно ?

ок, спс

покажите запрос и таблицу

SELECT * FROM table AS o WHERE (column = '1') AND (column2 = '2') LIMIT 300 что интересно без лимита запрос выполняется оО

если в SELECT появляются столбцы отличные от используемых в WHERE при указанном LIMIT то запрос не выполняется

Так работает: SELECT column1, column2, id FROM table WHERE (column1 = '1') AND (column2 = '1') и так работает: SELECT column1, column2 FROM table WHERE (column1 = '1') AND (column2 = '1') LIMIT 1 а так не работает: SELECT column1, column2, id FROM table WHERE (column1 = '1') AND (column2 = '1') LIMIT 1 Received exception from server (version 18.12.14): Code: 171. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Block structure mismatch in UNION stream: different names of columns: id UInt32 UInt32(size = 0), column1 String String(size = 0), column2 String String(size = 0) column1 String String(size = 0), id UInt32 UInt32(size = 0), column2 String String(size = 0).

тоже натыкался на Block structure mismatch, но issue без ответа https://github.com/yandex/ClickHouse/issues/3162

а у вас поведение зависит от LIMIT?

а у вас поведение зависит от LIMIT?

нет, но валится только запрос к Distributed таблице. точно такой же запрос на каждом инстансе кластера к нижележащей Replicated таблице проходит

у меня тоже дистриб таблица, но поведение зависит от limit или top

Добрый день, какое поведение у КХ когда идет выполение одного большого запроса и нескольких более простых, но все из одной таблицы. У меня при выполение команды show processlist висят все запросы, но выполняется только один большой

Добрый день, какое поведение у КХ когда идет выполение одного большого запроса и нескольких более простых, но все из одной таблицы. У меня при выполение команды show processlist висят все запросы, но выполняется только один большой

Это связано с наличием запроса ALTER. ALTER ждёт первый SELECT, а остальные запросы ждут ALTER.

@milovidov_an спасибо, была такая мысль

@milovidov_an есть ли какое то решение по репликации таблицы в контексте одного сервера ? или какое то решение которое поможет избежать блокировок при алтере

@milovidov_an есть ли какое то решение по репликации таблицы в контексте одного сервера ? или какое то решение которое поможет избежать блокировок при алтере

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

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

хочу заметить. что используется алтер для удаления партиции, для примера ALTER TABLE db.table DROP PARTITION '201802'; спасибо за предложенные варианты, но в контексте моей задачи таблица большая и ее копироввание довольно дорогая операция

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

а при репликации будет возникаться блокировка, для примера такой кейс, на слейве выполянется долгий запрос, в этой время на местер прилетает ALTER , слейв начнет синкать МАСТЕРА и получать изменения, после этого при на слейв прилетят еще запросы, будут ли они заблокорованны АЛТЕРОМ который прилетел с мастера ?

хочу заметить. что используется алтер для удаления партиции, для примера ALTER TABLE db.table DROP PARTITION '201802'; спасибо за предложенные варианты, но в контексте моей задачи таблица большая и ее копироввание довольно дорогая операция

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

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

не совсем, АЛТЕР выполняется быстро, но SELECT перед ним выполнятся долго, поэтому и блокировка

Подскажите, а в kafka engine можно указать номер партиции из которой забирать данные?

не совсем, АЛТЕР выполняется быстро, но SELECT перед ним выполнятся долго, поэтому и блокировка

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

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

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

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

Прям кусок кода скину ) func New() *worker { logger := log.WithField("service", "bender-worker") return &worker{ logger: logger, tasks: []Task{ task.Reports(logger), task.ClearColumns(logger), task.DropPartitions(logger), }, } }

Задачи выполняются последовательно

а при репликации будет возникаться блокировка, для примера такой кейс, на слейве выполянется долгий запрос, в этой время на местер прилетает ALTER , слейв начнет синкать МАСТЕРА и получать изменения, после этого при на слейв прилетят еще запросы, будут ли они заблокорованны АЛТЕРОМ который прилетел с мастера ?

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