В метро еду, не терпится узнать ?

Ладно, проверю напишу, если никто такого не проворачивал

Привет. Давай создадим в России автоматизированный платежный сервис для возможности осуществлять платежи юридическим лицам через расчетный счет в криптоволютных единицах

Давай

Давай

На Drupal?

На Drupal?

Модник, что ли? Пыха, вп.

Прочитал, сам не понял, что спросил. В общем, суть в следующем: если у нас было 2 таблицы с именами WatchLog_moscow WatchLog_berlin и мы создали таблицу Merge с Merge(hits, '^WatchLog') а потом создали таблицу WatchLog_piter будет ли при запросе к таблице Merge производиться поиск по новой таблице WatchLog_piter в том числе, или только по первым двум?

Будет искаться и в новых таблицах тоже.

Прочитал, сам не понял, что спросил. В общем, суть в следующем: если у нас было 2 таблицы с именами WatchLog_moscow WatchLog_berlin и мы создали таблицу Merge с Merge(hits, '^WatchLog') а потом создали таблицу WatchLog_piter будет ли при запросе к таблице Merge производиться поиск по новой таблице WatchLog_piter в том числе, или только по первым двум?

У нас один из сценариев использования Merge таблиц - объединение множества таблиц, в котором постоянно появляются новые и удаляются старые.

На Drupal?

На аштиэмэль

У нас один из сценариев использования Merge таблиц - объединение множества таблиц, в котором постоянно появляются новые и удаляются старые.

Понятно, спасибо. Очень нужный движок оказался... Минус целый микросервис, теперь вместо него одна таблица в КХ ??

@stufently, всё-таки не могу осилить ZK. Помогите пожалуйста. Схема 2 хоста, 2 шарда, 4 машины. ZK должен работать на одной или на четырех?

@stufently, всё-таки не могу осилить ZK. Помогите пожалуйста. Схема 2 хоста, 2 шарда, 4 машины. ZK должен работать на одной или на четырех?

на четырёх отдельных серверах по одному. можно на трёх.

@stufently, всё-таки не могу осилить ZK. Помогите пожалуйста. Схема 2 хоста, 2 шарда, 4 машины. ZK должен работать на одной или на четырех?

Вам для начала одного ЗК за глаза

на четырёх отдельных серверах по одному. можно на трёх.

Не давайте сложных советов школьникам у них опилки в голове

@stufently, всё-таки не могу осилить ZK. Помогите пожалуйста. Схема 2 хоста, 2 шарда, 4 машины. ZK должен работать на одной или на четырех?

почитайте от корки до корки, там немного https://zookeeper.apache.org/doc/r3.4.5/index.html для работы с Clickhouse нужен один кластер ZK из не менее чем 3 членов кластера ZK. В конфиге каждого кликхауса должны быть прописаны адреса каждого узла ZK. в целом есть такая тема, что КХ вроде как лучше работает с доменными именами, а не с IP в конфигах. не нужно поднимать DNS, достаточно на каждом сервере из комплекса прописать в hosts пару хостнейм-IP, и всё, приложения уже могут работать с доменными именами этими. upd Мне вот 20, ответственно заявляю, ничего сложного в КХ нет, надо просто посидеть, почитать документацию, поскать по истори чата и в гугле... после реляционных немного необычно только.

почитайте от корки до корки, там немного https://zookeeper.apache.org/doc/r3.4.5/index.html для работы с Clickhouse нужен один кластер ZK из не менее чем 3 членов кластера ZK. В конфиге каждого кликхауса должны быть прописаны адреса каждого узла ZK. в целом есть такая тема, что КХ вроде как лучше работает с доменными именами, а не с IP в конфигах. не нужно поднимать DNS, достаточно на каждом сервере из комплекса прописать в hosts пару хостнейм-IP, и всё, приложения уже могут работать с доменными именами этими. upd Мне вот 20, ответственно заявляю, ничего сложного в КХ нет, надо просто посидеть, почитать документацию, поскать по истори чата и в гугле... после реляционных немного необычно только.

Спасибо.

почитайте от корки до корки, там немного https://zookeeper.apache.org/doc/r3.4.5/index.html для работы с Clickhouse нужен один кластер ZK из не менее чем 3 членов кластера ZK. В конфиге каждого кликхауса должны быть прописаны адреса каждого узла ZK. в целом есть такая тема, что КХ вроде как лучше работает с доменными именами, а не с IP в конфигах. не нужно поднимать DNS, достаточно на каждом сервере из комплекса прописать в hosts пару хостнейм-IP, и всё, приложения уже могут работать с доменными именами этими. upd Мне вот 20, ответственно заявляю, ничего сложного в КХ нет, надо просто посидеть, почитать документацию, поскать по истори чата и в гугле... после реляционных немного необычно только.

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

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

у человека в схеме 4 машины и 2 шарда - я решил, что реплики будут, а они только с ZK работают.

Ну я написал как минимум три варианта которые противоречат вашему отверждению причем два из них для реплик

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

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

Школьники делают лабораторную работу

А если репликация нужна, то поднимать его надо на 3 или даже 5 узлах, но ни в коем случае не на 4, потому что всегда должен быть majority

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

Репликация нужна.

А если репликация нужна, то поднимать его надо на 3 или даже 5 узлах, но ни в коем случае не на 4, потому что всегда должен быть majority

Понял.

Тогда на 3 нодах

А если репликация нужна, то поднимать его надо на 3 или даже 5 узлах, но ни в коем случае не на 4, потому что всегда должен быть majority

Можно на одном, можно на двух, одно другому не мешает

Если этот 1 инстанс выйдет из строя, то будет потом больновато

Школьники не могут с одним зукипером поднять кх а вы ещё больше запутываете

В случае с 2 инстансами зукипера надежность всё еще как с одним — выйдет из строя один и всё

Тогда на 3 нодах

Принял.

Поэтому нужно минимум 3

Если этот 1 инстанс выйдет из строя, то будет потом больновато

Кому больно? Одноклассникам? Учителю?

Кому больно? Одноклассникам? Учителю?

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

Их потом могут начать цитировать и использовать уже в реальном продакшене

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

И только потом, когда всё упадет, он узнает, зачем нужно было 3 ноды

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

Всецело поддерживаю.

Ну в итоге они слушают ваши советы и реплики соответственно у них работать не будут как всегда

Пусть учатся сразу делать нормально :). Очень пригодится потом при эксплуатации в реальности

Ну и к тому же зачастую КХ имеет смысл использовать вообще без репликации и зукипера

да они пока не справляются :) пусть начнут с одного, все-таки

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

во многих кейсах использования КХ это тоже приемлемо

И эту схему настроить намного проще :)

насколько я понимаю 4 зукипера могут быть, но просто это малосмысленно. имхо 6 зукиперов (кворум половина+ = 4) -- переживет выход из строя 2 5 зукиперов (кворум половина+ = 3) -- переживет выход из строя 2 4 зукипера (кворум половина+ = 3) -- переживет выход из строя 1 3 зукипера (кворум половина+ = 2) -- переживет выход из строя 1 2 зукипера (кворум половина+ = 2) -- переживет выход из строя 0

насколько я понимаю 4 зукипера могут быть, но просто это малосмысленно. имхо 6 зукиперов (кворум половина+ = 4) -- переживет выход из строя 2 5 зукиперов (кворум половина+ = 3) -- переживет выход из строя 2 4 зукипера (кворум половина+ = 3) -- переживет выход из строя 1 3 зукипера (кворум половина+ = 2) -- переживет выход из строя 1 2 зукипера (кворум половина+ = 2) -- переживет выход из строя 0

почитайте что такое split brain

почитайте что такое split brain

вы мое сообщение прочитали? Откуда там сплит, 2+2 не будут работать, ОБА, у них кворума не будет.

каждая!!! транзакция подтверждает кворумом (большей половиной).

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

вы мое сообщение прочитали? Откуда там сплит, 2+2 не будут работать, ОБА, у них кворума не будет.

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

Cкажем так, конфигурации с четным числом нод довольно мало смысла имеют

Потому что в случае с четным числом машин ещё одна машина по сравнению с нечетным количеством не дает улучшения отказоустойчивости

И вводит в заблуждение, более того

Т.е. да, в случае с 4 нодами всё равно кворум будет достигаться только если есть 3 машины из 4, то есть потерять можно только одну ноду

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

4 ноды zk ВСЕГДА медленее чем 3. Больше 3 нод в ансамбле, это дополнительные тормоза.

4 ноды zk ВСЕГДА медленее чем 3. Больше 3 нод в ансамбле, это дополнительные тормоза.

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

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

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

Ну скорее всего они правда будут медленней при этом

Всем привет. У нас в структуре таблицы есть слорь(дефолт значение). После обновление КХ, идут ошибки типа Unsupported type Nullable(Date) Может ли из-за этого не подниматься clickhouse?

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

Ну скорее всего они правда будут медленней при этом

ну разница в 50 мс не очень заметна видимо

Всем привет. У нас в структуре таблицы есть слорь(дефолт значение). После обновление КХ, идут ошибки типа Unsupported type Nullable(Date) Может ли из-за этого не подниматься clickhouse?

скорее всего https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md ClickHouse release 18.1.0, 2018-07-23 Обратно несовместимые изменения: Не работает преобразование строки, содержащей число ноль, в DateTime. Пример: SELECT toDateTime('0'). По той же причине не работает DateTime DEFAULT '0' в таблицах, а также <null_value>0</null_value> в словарях. Решение: заменить 0 на 0000-00-00 00:00:00.

А может из-за этого не подниматься кликхаус?

да

У нас всегда ошибки по словарям, но они никогда к падению не приводили

вы везучий просто, я еще ни на одну версию КХ без исправления своего кода не перешел.

Мы как-то раз наступили на багу, когда таблицы создавались из веб-интерфейса и он всегда дописывал FORMAT JSON в конец запроса. Несмотря на то, что при создании таблицы ответ всё равно не выдавался в формате JSON, таблицы умудрялись создаться и в sql-файлики записывался запрос с FORMAT JSON. После рестарта, кликхаус не хотел подниматься, потому что это невалидный запрос на создание таблицы :). Пришлось руками удалять эту строчку из таблиц, чтобы КХ поднялся.

Так что наверное стоит, как минимум, иметь какие-нибудь тестовые инстансы КХ, на которых вы будете тестировать новую версию со своим кодом перед тем, как катить обновления в прод.

2018.10.12 01:16:11.684795 [ 54 ] <Error> ExternalDictionaries: Failed reloading '' external dictionary: Code: 50, e.displayText() = DB::Exception: Unsupported type Nullable(Date), e.what() = DB::Exception, Stack trace: Вот в таком словаре <structure> <id> <name>sourceId</name> </id> <range_min> <name>dateStart</name> </range_min> <range_max> <name>dateEnd</name> </range_max> <attribute> <name>money</name> <type>Float32</type> <null_value>0.0</null_value> </attribute> </structure>

null в mysql нет

2018.10.12 01:16:11.684795 [ 54 ] <Error> ExternalDictionaries: Failed reloading '' external dictionary: Code: 50, e.displayText() = DB::Exception: Unsupported type Nullable(Date), e.what() = DB::Exception, Stack trace: Вот в таком словаре <structure> <id> <name>sourceId</name> </id> <range_min> <name>dateStart</name> </range_min> <range_max> <name>dateEnd</name> </range_max> <attribute> <name>money</name> <type>Float32</type> <null_value>0.0</null_value> </attribute> </structure>

https://github.com/yandex/ClickHouse/issues/3284

баг последней версии?

баг последней версии?

похоже

Кстати, как оказалось, не поднимался КХ не. из-за того что словари битые. А похоже данные мигрировались

примерно час запускался

баг последней версии?

похоже КХ и внешние словари это вечный баг ? 18.4.0 ++ 18.5.1 [unixODBC]could not create SSL context: library has no ciphers 18.6.0 [unixODBC][Driver Manager]Data source name not found, and no default driver specified 18.10.3 ExternalDictionaries: Failed reloading 'campaigns' external dictionary: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = No address found, e.what() = No address found 18.12.13 ExternalDictionaries: Failed reloading 'campaigns' external dictionary: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = No message received, e.what() = No message received 18.12.14 ExternalDictionaries: Failed reloading 'campaigns' external dictionary: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = No message received, e.what() = No message received 18.12.17 ExternalDictionaries: Failed reloading 'campaigns' external dictionary: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = No message received, e.what() = No message received

похоже КХ и внешние словари это вечный баг ? 18.4.0 ++ 18.5.1 [unixODBC]could not create SSL context: library has no ciphers 18.6.0 [unixODBC][Driver Manager]Data source name not found, and no default driver specified 18.10.3 ExternalDictionaries: Failed reloading 'campaigns' external dictionary: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = No address found, e.what() = No address found 18.12.13 ExternalDictionaries: Failed reloading 'campaigns' external dictionary: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = No message received, e.what() = No message received 18.12.14 ExternalDictionaries: Failed reloading 'campaigns' external dictionary: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = No message received, e.what() = No message received 18.12.17 ExternalDictionaries: Failed reloading 'campaigns' external dictionary: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = No message received, e.what() = No message received

С подключением ODBC источников может быть много особенностей. Чтобы не ломалось, можно добавить больше конфигураций в интеграционные тесты. У нас уже есть интеграционный тест с подключением Postgres-а, но получается, что он не покрывает ваш случай. Сможете описать конфигурацию (хоть текстом), чтобы мы воспроизвели неработающее подключение у себя?

https://github.com/yandex/ClickHouse/issues/3284

Прошу прощения. Нет аккаунта на гитхабе. Завтра постараюсь сделать. А пока что подробности сюда: Наша история, после обновления с 1.1.54327 до 18.12.17 появилась ошибка: 2018.10.12 01:16:11.684795 [ 54 ] <Error> ExternalDictionaries: Failed reloading ‘DictName’ external dictionary: Code: 50, e.displayText() = DB::Exception: Unsupported type Nullable(Date), e.what() = DB::Exception, Stack trace: <layout> <range_hashed /> </layout> <structure> <id> <name>sourceId</name> </id> <range_min> <name>dateStart</name> </range_min> <range_max> <name>dateEnd</name> </range_max> <attribute> <name>money</name> <type>Float32</type> <null_value>0.0</null_value> </attribute> </structure> null в mysql нет, структура таблицы CREATE TABLE RefProfit ( sourceId int(11) NOT NULL, money decimal(5,5) unsigned NOT NULL, dateStart date NOT NULL DEFAULT '0000-00-00', dateEnd date NOT NULL DEFAULT '0000-00-00', KEY dateStart (`dateStart`,`dateEnd`), KEY sourceId (`sourceId`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 Похоже баг последней версии связанный с range словарями. Буду очень благодарен, если подскажите, до какой версии можно откатиться

Прошу прощения. Нет аккаунта на гитхабе. Завтра постараюсь сделать. А пока что подробности сюда: Наша история, после обновления с 1.1.54327 до 18.12.17 появилась ошибка: 2018.10.12 01:16:11.684795 [ 54 ] <Error> ExternalDictionaries: Failed reloading ‘DictName’ external dictionary: Code: 50, e.displayText() = DB::Exception: Unsupported type Nullable(Date), e.what() = DB::Exception, Stack trace: <layout> <range_hashed /> </layout> <structure> <id> <name>sourceId</name> </id> <range_min> <name>dateStart</name> </range_min> <range_max> <name>dateEnd</name> </range_max> <attribute> <name>money</name> <type>Float32</type> <null_value>0.0</null_value> </attribute> </structure> null в mysql нет, структура таблицы CREATE TABLE RefProfit ( sourceId int(11) NOT NULL, money decimal(5,5) unsigned NOT NULL, dateStart date NOT NULL DEFAULT '0000-00-00', dateEnd date NOT NULL DEFAULT '0000-00-00', KEY dateStart (`dateStart`,`dateEnd`), KEY sourceId (`sourceId`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 Похоже баг последней версии связанный с range словарями. Буду очень благодарен, если подскажите, до какой версии можно откатиться

С range словарями были такие последние изменения: https://github.com/yandex/ClickHouse/pull/3123/commits/99560e06f85e3b0388291d655e6a03559f4d5b46 Там можно посмотреть список тегов, в которых изменение присутствует. Видно, что впервые появилось в 18.12.

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

Может что-то в структуре словаря\таблицы можно поменять?

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

Range словари работают. (И конечно, есть тесты.) Про эти изменения - всего лишь гипотеза, надо смотреть внимательнее, в чём причина.

Как можем помочь с изучением проблемы? Попросить тест стенды поднять с разными версиями? Или могу в личку дать полный файл словаря + его данные.

Сначала попробую с пустым, посмотрим.

Спасибо. Если что, пишите, поможем чем сможем)

Спасибо. Если что, пишите, поможем чем сможем)

Всё прекрасно воспроизводится: https://gist.github.com/alexey-milovidov/c31b37f56114b822c7fdcf21d8557c9d Будем разбираться дальше.

Про то, что изменения в https://github.com/yandex/ClickHouse/pull/3123 повлияли - гипотеза верная.

range словари тестирвались только для источника file.

В общем, мы одни из немногих счастливчиков с range в проде:)

Насколько безопасен откат с 18.12.17 до 18.10.3?

Зависит от того, какие новые возможности 18.12.17 вы уже начали использовать.

Если никакие, то безопасно (проверено).

Alter update не делали. Да в целом ничего специально не делали.

Прошу прощения. Нет аккаунта на гитхабе. Завтра постараюсь сделать. А пока что подробности сюда: Наша история, после обновления с 1.1.54327 до 18.12.17 появилась ошибка: 2018.10.12 01:16:11.684795 [ 54 ] <Error> ExternalDictionaries: Failed reloading ‘DictName’ external dictionary: Code: 50, e.displayText() = DB::Exception: Unsupported type Nullable(Date), e.what() = DB::Exception, Stack trace: <layout> <range_hashed /> </layout> <structure> <id> <name>sourceId</name> </id> <range_min> <name>dateStart</name> </range_min> <range_max> <name>dateEnd</name> </range_max> <attribute> <name>money</name> <type>Float32</type> <null_value>0.0</null_value> </attribute> </structure> null в mysql нет, структура таблицы CREATE TABLE RefProfit ( sourceId int(11) NOT NULL, money decimal(5,5) unsigned NOT NULL, dateStart date NOT NULL DEFAULT '0000-00-00', dateEnd date NOT NULL DEFAULT '0000-00-00', KEY dateStart (`dateStart`,`dateEnd`), KEY sourceId (`sourceId`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 Похоже баг последней версии связанный с range словарями. Буду очень благодарен, если подскажите, до какой версии можно откатиться

Но апдейт был с 1.1.54327 и серверы запускались больше часа(похоже что-то мигрировало)

Но апдейт был с 1.1.54327 и серверы запускались больше часа(похоже что-то мигрировало)

У нас никогда не было миграций (всяких структур данных) при обновлениях.