НМ
включили тестовый, и каким-то органом, стали писаться логи в основной
Доброго времени суток.
Можно ли строку "2019-12-14T18:40:50Z" привести к DateTime ?
Size: a a a
2019 December 17
DC
с query_log
если в кратце - мы игрались с настройками CH в тестовой среде, поднимали зукипер и т.д.
в определенный момент, мы решили, что мы готовы внедрять CH закупили сервак, детачнули таблицы с тестовой среды, залили на серв, приаттачили их, запустили, все работает, все счастливы.
пока не заглянули в query_log который оказался пустым, точнее в нем записи заканчиваются на дате отключения тестового сервака.
разница между тестовым окружением и текущим - на тесте был зукипер, тут его нет.
в целом админов понять можно - нет кластера => зукипер особо и не нужен.
сегодня админы пол дня возились с конфигами, но не могут понять что не так
если в кратце - мы игрались с настройками CH в тестовой среде, поднимали зукипер и т.д.
в определенный момент, мы решили, что мы готовы внедрять CH закупили сервак, детачнули таблицы с тестовой среды, залили на серв, приаттачили их, запустили, все работает, все счастливы.
пока не заглянули в query_log который оказался пустым, точнее в нем записи заканчиваются на дате отключения тестового сервака.
разница между тестовым окружением и текущим - на тесте был зукипер, тут его нет.
в целом админов понять можно - нет кластера => зукипер особо и не нужен.
сегодня админы пол дня возились с конфигами, но не могут понять что не так
system.query_log ? Она не реплицируется. И не имеет отношения к зукиперу. Писать или не писать зависит от параметра сессии log_queries=1
DC
Доброго времени суток.
Можно ли строку "2019-12-14T18:40:50Z" привести к DateTime ?
Можно ли строку "2019-12-14T18:40:50Z" привести к DateTime ?
при вставке date_time_input_format=best_effort
при селекте parseDateTimeBestEffort()
при селекте parseDateTimeBestEffort()
НМ
но в конфиги никакие правки не вносились, CH не перезапускался, а записи стали появляться, при этом не все, что тоже не менее странно, а только от defaul юзера под которым заходят админы
AR
при вставке date_time_input_format=best_effort
при селекте parseDateTimeBestEffort()
при селекте parseDateTimeBestEffort()
А это не сильно сказывается на продуктивности (вставка идет в пиках до 40к записей в секунду)
DC
но в конфиги никакие правки не вносились, CH не перезапускался, а записи стали появляться, при этом не все, что тоже не менее странно, а только от defaul юзера под которым заходят админы
параметр можно выставить в профиле пользователя и в сессии с клиента
DC
А это не сильно сказывается на продуктивности (вставка идет в пиках до 40к записей в секунду)
не знаю.
AR
Спасибо
НМ
но настройки клиента не менялись, при переносе, старались максимально бесшовно провести перенос, и создали отдельную копию CH залили данные, потом просто поменяли ip серверов, подменив тест и прод.
по идее, все должно было остаться как прежде.
очень странно, в любом случае - спасибо за направление, передам это все админам, пусть смотрят.
по идее, все должно было остаться как прежде.
очень странно, в любом случае - спасибо за направление, передам это все админам, пусть смотрят.
TM
нормально работает, пару месяцев назад правда драйвер внезапно сломался на новой версии графаны 🙂 решили откатом графаны на предыдущую версию
использую с этой дашбордой
https://grafana.com/grafana/dashboards/9561
использую с этой дашбордой
https://grafana.com/grafana/dashboards/9561
data:"Code: 60, e.displayText() = DB::Exception: Table default.undefined doesn't exist. (version 19.15.3.6 (official build)) "
Не js случайно сломался? :)
TM
Это лог ответа при попытке создать query из графаны
S
OPTIMIZE без FINAL тоже синхронный, просто ты запускаешь всего одну итерацию смерживания партов
а когда с FINAL то все смерживается до конца
а когда с FINAL то все смерживается до конца
ой извините
AB
data:"Code: 60, e.displayText() = DB::Exception: Table default.undefined doesn't exist. (version 19.15.3.6 (official build)) "
Не js случайно сломался? :)
а табличку из которой выбираете задали? он именно на это ругается
TM
Он ее не видит, она выбрана в списке
TM
То есть он ее сам же предлагает, а когда запрос идет делать, теряется значение
IG
Что странное вы описали. Т.е. за день вы добавляете возможные дубликаты в таблицу t. Ночью запустится optimize на все партиции где партов больше одного. И затем все скопируется в таблицу s? А не проще запросом просто выбрать с final ?
Ну,
1) с final придется переписывать всю таблицу, а так я дропну определенные партици во второй таблице, и скопирую их из первой
2) final выполняется в один поток + никак не влияет на сами файлы на жестком диске, а значит их потом придется в любом случае мержить в фоне
Так в чем тогда профит?
1) с final придется переписывать всю таблицу, а так я дропну определенные партици во второй таблице, и скопирую их из первой
2) final выполняется в один поток + никак не влияет на сами файлы на жестком диске, а значит их потом придется в любом случае мержить в фоне
Так в чем тогда профит?
AB
То есть он ее сам же предлагает, а когда запрос идет делать, теряется значение
странно, ну я вот только что проверил - у меня адекватно ведет себя на графане 6.3.6, двайвер 1.9.0
S
Code: 48, e.displayText() = DB::Exception: Method createColumn() is not implemented for data type Set (version 19.17.4.11)
а кто знает что это за ошибка?
совершенно не понимаю на что ругается
а кто знает что это за ошибка?
совершенно не понимаю на что ругается
TM
У меня вот 6.5.2, ей буквально 6 дней, оказывается. Драйвер 1.9.3. Видимо пора пробовать откатываться :)