Отталкивайтесь от начального мануала

У меня дофига таблиц там, есть какие-то скрипты?

Лучшие скрипты - скрипты, написанные самостоятельно :)

А дистрибьютед зачем пересоздавать? и как это делать?

Учтите, что имеющиеся данные не "разольются" в новые шарды ровным слоем

Учтите, что имеющиеся данные не "разольются" в новые шарды ровным слоем

да, это я понимаю

drop table create table Всё как в мануале по distributed

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

Я не совмем понимаю зачем это делать. Когда я создавал Distributed таблицу я же ей не хосты указывал, а имя кластера. Оно без пересоздания не заработает?

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

т.е. не надо Distributed пересоздавать?

в вашем случае - только на новых узлах (или там, где она нужна)

ок. спс

А схемы таблиц они в каких-то файликах храняться или как? Я могу их просто со старых серверов на новые скопирвать?

А схемы таблиц они в каких-то файликах храняться или как? Я могу их просто со старых серверов на новые скопирвать?

show create table

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

show create table

это я умею. Я хочу просто файлики взять и переложить.

так возможно или нет?

Vs nfr yt ghj,jdfkb

Мы так не пробовали

это я умею. Я хочу просто файлики взять и переложить.

что это за новый метод работы с бд изнутри?

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

да конечно возможно бери да перемещай любые файлы куда хочешь

но работая с базой изнутри надо понимать как она работает внутри

Добрый день. Подскажите, пожалуйста, что делаю не так? CREATE TABLE IF NOT EXISTS `eventShard` ( date Date, ts UInt64, id UInt64, data UInt32, ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/01/eventShard', 'node-1', date, (ts, id)) PARTITION BY date ORDER BY (ts, id); Ошибка: Received exception from server (version 18.10.3): Code: 42. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: With extended storage definition syntax storage ReplicatedReplacingMergeTree requires 2 to 3 parameters: path in ZooKeeper, replica name, [version] В расширенном описании ошибки есть примеры с PARTITION BY и ORDER BY

мешаете 2 синтаксиса - старый и новый. Он вам подсказывает что если используете PARTITION BY то в скобках должно быть меньше параметров.

Спасибо

2018-08-30 14:58:09 INFO PrepRequestProcessor:598 - Got user-level KeeperException when processing sessionid:0x161b0af346b0005 type:multi cxid:0x77eb81a zxid:0x41304671b txntype:-1 reqpath:n/a aborting remaining multi ops. Error Path:/clickhouse/tables/1/logs/replicas/2/parts/20180830_20180830_928706_928710_1 Error:KeeperErrorCode = NodeExists for /clickhouse/tables/1/logs/replicas/2/parts/20180830_20180830_928706_928710_1 это приемлемый лог INFO, или надо предпринять какие то действия? не вижу никаких проблем в логах кликхауса и репликации PS. версия 1.1.54383

Что может быть причиной появления replicated_part_failed_fetches в метриках?

create table test.tab1 (a1 Int32, b1 Int32) engine = MergeTree order by a1; create table test.tab1_copy (a1 Int32, b1 Int32) engine = MergeTree order by a1; insert into test.tab1 values (1, 2); insert into test.tab1_copy values (2, 3); select tab1.a1, tab1_copy.a1, tab1.b1 from test.tab1 any left join test.tab1_copy on tab1.b1 + 3 = b1 + 2

Спасибо, воспроизводится, будем починить.

Exception on client: Code: 53. DB::Exception: Type mismatch in IN or VALUES section. Expected: String. Got: UInt64 Connecting to localhost:9000 as user default. Connected to ClickHouse server version 18.10.3 revision 54405.

и как такое отлаживать?

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

Спасибо, воспроизводится, будем починить.

спасибо! в идеали хочестя иметь возможность при джойне выбрать все столбцы из обеих таблиц =) и вопрос - планируся ли использование OR в ON?

Это ещё ладно... У меня тут telegraf периодически подсовывает не то. При этом в логах изредка видно, на чём (каком запросе) споткнулись, но не видно, на каком поле. Что хреново - видно именно изредка, несмотря на включенный debug. А trace на рабочем кластере включать почему-то не хочется...

В целом, да, и пересоздать distributed

Добрый день. А надо пересоздавать distributed при добавлении реплик, а не шард?

Добрый день. А надо пересоздавать distributed при добавлении реплик, а не шард?

Distributed оперирует топологией кластера из xml. Там ноды разбиты по шардам, и обозначены как реплики друг друга. Если вы создаёте реплики согласно этому конфигу, то Distributed всё подхватывает и роутит запросы в реплики шардов.

и как такое отлаживать?

Постараться внимательно прочитать и понять сообщение об ошибке. Вкратце - КХ использует строгие типы данных. Нельзя сравнивать данные разных типов без приведения. Например WHERE sting_field in (123123,12345345) ; выдаст примерно такую ошибку. Но если превратить числа в строки - то всё будет ок: WHERE sting_field in ('123123','12345345')

Коллеги, а подскажите плиз в каком контексте в конфиг вставлять max_size_to_drop - а то что-то игнорирует сервер эту настройку

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

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

Ошибка в названии параметра. Правильно он называется max_table_size_to_drop.

https://clickhouse.yandex/docs/en/operations/server_settings/settings/#max_table_size_to_drop

Ошибка в названии параметра. Правильно он называется max_table_size_to_drop.

аа, просто эксепшн говорит иначе :)

https://pastebin.com/QAWeVbXc

Distributed оперирует топологией кластера из xml. Там ноды разбиты по шардам, и обозначены как реплики друг друга. Если вы создаёте реплики согласно этому конфигу, то Distributed всё подхватывает и роутит запросы в реплики шардов.

Можно ли как-нибудь не пересоздавать Distributed при добавлении шарда, а зафорсить перечитывание конфига? Потому как у нас на Distributed будет повешен бесконечный поток запросов, не хотелось бы, чтобы это было каким-то остановочным фактором для работы пользователей с distributed таблицами

аа, просто эксепшн говорит иначе :)

Как раз сегодня был PR с поправкой этого сообщения об ошибке :) https://github.com/yandex/ClickHouse/pull/2997/files

Как раз сегодня был PR с поправкой этого сообщения об ошибке :) https://github.com/yandex/ClickHouse/pull/2997/files

Спасибо!

Можно ли как-нибудь не пересоздавать Distributed при добавлении шарда, а зафорсить перечитывание конфига? Потому как у нас на Distributed будет повешен бесконечный поток запросов, не хотелось бы, чтобы это было каким-то остановочным фактором для работы пользователей с distributed таблицами

В общем это бред, я тут достал свои результаты эксплуатационных тестов, написанных довольно давно, Distributed таблицы пересоздавать при добавлении шард не нужно. ? @AlexAkulov

Постараться внимательно прочитать и понять сообщение об ошибке. Вкратце - КХ использует строгие типы данных. Нельзя сравнивать данные разных типов без приведения. Например WHERE sting_field in (123123,12345345) ; выдаст примерно такую ошибку. Но если превратить числа в строки - то всё будет ок: WHERE sting_field in ('123123','12345345')

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

Спасибо!

Похоже, что и <max_table_size_to_drop>0</max_table_size_to_drop> тоже игнорируется кх

даже после перезагрузки не дает дропнуть

Можно ли как-нибудь не пересоздавать Distributed при добавлении шарда, а зафорсить перечитывание конфига? Потому как у нас на Distributed будет повешен бесконечный поток запросов, не хотелось бы, чтобы это было каким-то остановочным фактором для работы пользователей с distributed таблицами

Можно попробовать создать рядом новую версию и выполнить двойной RENAME - я не пробовал с Distributed, но вроде бы должно пройти.

а как вы в метрике удаляете данные из кх в рамках закона яровой?

или гдпр какого-нибудь

Коллеги, а в чем причина следующей ошибки? DB::Exception: Unknown user default. при вызове OPTIMIZE TABLE stat_v2 PARTITION '201807';

а как вы в метрике удаляете данные из кх в рамках закона яровой?

Надо чтобы Кристиан Шинкевич из Польши написал запрос в Яндекс с просьбой предоставить и удалить данные =)

Коллеги, а в чем причина следующей ошибки? DB::Exception: Unknown user default. при вызове OPTIMIZE TABLE stat_v2 PARTITION '201807';

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

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

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

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

да, есть

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

Ошибка при инсерте? Там да, бывает сложно - попробуйте аккуратно кавычки расставлять. При вставке из файла должен писать номер строки и контекст.

Ошибка при инсерте? Там да, бывает сложно - попробуйте аккуратно кавычки расставлять. При вставке из файла должен писать номер строки и контекст.

нет

нет

Ну значит нет. :)

У меня пишет: https://pastebin.com/rSZ59TwS

Коллеги, а в чем причина следующей ошибки? DB::Exception: Unknown user default. при вызове OPTIMIZE TABLE stat_v2 PARTITION '201807';

Попробуйте ту же команду выполнить на реплике-лидере?

но я ведь вставляю не у тебя, и не в таблицу твоей структуры, верно?

Попробуйте ту же команду выполнить на реплике-лидере?

а как понять кто лидер?

но я ведь вставляю не у тебя, и не в таблицу твоей структуры, верно?

Верно. Но что именно ты вставляешь и куда ты же не сказал :)

ну так и кликхаус мне не сказал, разве это не заметно?

ну так и кликхаус мне не сказал, разве это не заметно?

Мне не заметно :)

мне несложно еще раз процитировать: Exception on client: Code: 53. DB::Exception: Type mismatch in IN or VALUES section. Expected: String. Got: UInt64 Connecting to localhost:9000 as user default. Connected to ClickHouse server version 18.10.3 revision 54405.

КХ - это продукт с открытым кодом. Если что-то работает не идеально и вам хочется чтобы работало лучше - то есть несколько выходов. 1) выливать свою обиду на несовершенство мира в телеграмме 2) постараться обойти ошибку 3) попробовать исправить ошибку в исходном коде КХ 4) постараться максимально подробно описать шаги которые вопроизводят проблему, так чтобы кто-то другой смог в этом помочь. Первый пункт опробован. Переходим к следующему? :)

мне несложно еще раз процитировать: Exception on client: Code: 53. DB::Exception: Type mismatch in IN or VALUES section. Expected: String. Got: UInt64 Connecting to localhost:9000 as user default. Connected to ClickHouse server version 18.10.3 revision 54405.

Это ошибка. К которой привело выполнение такого запроса?..

inser into ... values ...

полей в таблице больше двух десятков, вставляется 100 тыщ строк

Не желательно вставлять 100 тыщ строк в формате values.

Не желательно вставлять 100 тыщ строк в формате values.

а вот это почему?

невозможно в моем случае вставлять иначе

вставляю в кучу таблиц и по 50к, и по 500к пачки, проблем не заметно

Не желательно вставлять 100 тыщ строк в формате values.

а варианты? через cli же так и вставляется

да и jdbc тоже через values пишет

да и jdbc тоже через values пишет

AFAIK jdbc внутри использует TSV.

Добрый день. Подскажите пожалуйста в чем может быть проблема. select dictGetString('some_dict_name', 'name', toUInt64(3)) as rname в ответ получаю Code: 53. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Third argument of function dictGetString must be (UInt64).

AFAIK jdbc внутри использует TSV.

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

а вот это почему?

Это не правило, VALUES использовать можно, но тот же TSV почти всегда будет работать быстрее. С Values - могут быть причуды - т.к. он может переключаться в режим парсования SQL отчего могут появляться всякие побочные эффекты.

В Values можно использовать фрагметы sql, типа INSERT INTO table x(date) VALUES (today());

Это не правило, VALUES использовать можно, но тот же TSV почти всегда будет работать быстрее. С Values - могут быть причуды - т.к. он может переключаться в режим парсования SQL отчего могут появляться всякие побочные эффекты.

таким не занимаемся =)

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

Если это SELECT - то jdbc внутри точно использует tab separated. При инсертах - не знаю, в jave не пишу. :)

просто сам по себе инсёрт запрос предполагает наличие values

или это уже не sql будет

TabSeparated пошустрее, но не сильно намного