MK
Господа
Size: a a a
2019 December 17
MK
А кто пробовал CH собирать с LTO?
MK
Истории успеха пилите, потому-что у меня пока какие-то странные ошибки при линковке вываливаются
DT
OPTIMIZE без FINAL - асинхронный
с FINAL синхронный
с FINAL синхронный
ээ, разве?
DT
OPTIMIZE без FINAL тоже синхронный, просто ты запускаешь всего одну итерацию смерживания партов
а когда с FINAL то все смерживается до конца
а когда с FINAL то все смерживается до конца
N
Добрый день. Кто-то сталкивался? Выше писали, что пофиксили еще в 19.15. Но в 19.16 сохраняется.
2019.12.17 15:05:28.203337 [ 435 ] {} <Fatal> BaseDaemon: (version 19.16.2.2 (official build)) (from thread 192) Received signal Segmentation fault (11).
2019.12.17 15:05:28.203387 [ 435 ] {} <Fatal> BaseDaemon: Address: NULL pointer. Access: read. Unknown si_code.DT
Добрый день. Кто-то сталкивался? Выше писали, что пофиксили еще в 19.15. Но в 19.16 сохраняется.
2019.12.17 15:05:28.203337 [ 435 ] {} <Fatal> BaseDaemon: (version 19.16.2.2 (official build)) (from thread 192) Received signal Segmentation fault (11).
2019.12.17 15:05:28.203387 [ 435 ] {} <Fatal> BaseDaemon: Address: NULL pointer. Access: read. Unknown si_code.у меня такое есть на 19.17 когда какая то проблема с http запросом
GP
Доброго дня, подскажите пожалуйста, сегодня запустил тяжелый запрос на копирование данных из одной таблицы в другую. Запрос завис, через некоторое время запустил kill query на него. Запрос из талицы processes пропал, но: теперь при обращении к таблице, куда копировал, запросы выполняются бесконечно долго, при попытке записи в другие таблицы пишет DB::Exception: Too many parts (304). Merges are processing significantly slower than inserts. и оперативы процесс clickhousa стал есть куда больше. Вопрос как можно это порешать, и почему так вышло?
DC
И еще вопрос. Вызов optimize - это синхронный или асинхронный запрос? На тестовой базе выполняется слишком быстро и сложно отследить. В доке про это ничего нет -)
Синхронный
DC
Добрый день. Кто-то сталкивался? Выше писали, что пофиксили еще в 19.15. Но в 19.16 сохраняется.
2019.12.17 15:05:28.203337 [ 435 ] {} <Fatal> BaseDaemon: (version 19.16.2.2 (official build)) (from thread 192) Received signal Segmentation fault (11).
2019.12.17 15:05:28.203387 [ 435 ] {} <Fatal> BaseDaemon: Address: NULL pointer. Access: read. Unknown si_code.такой сегфолт у множества разных багов существующих и будущих.
ИИ
Друзья, а можете рассказать быстро ли работает кверя по json?
DC
Друзья, а можете рассказать быстро ли работает кверя по json?
В сотни раз медленее чем по распаршенным полям
DC
Подскажите, пожалуйста, где можно узнать подробнее про replication_alter_partitions_sync и optimize. Кейс такой: есть таблица с миллиардами записей на движке ReplicatedCollapsingMergeTree, в течении дня она пополняется новыми записями + изменяются старые, ночью я хочу я вызвать optimize на тех партициях, где он не успел пройти в фоне и изменившиеся партиции скопировать в другую таблицу. Какая партиция будет выбрана при копировании? Та, что успела оптимизироваться, или любая?
Что странное вы описали. Т.е. за день вы добавляете возможные дубликаты в таблицу t. Ночью запустится optimize на все партиции где партов больше одного. И затем все скопируется в таблицу s? А не проще запросом просто выбрать с final ?
НМ
Коллеги, приветствую, не подскажете ли, есть ли в CH возможность найти по like '%value%' значение, пробежавшись по всем полям всех таблиц, в том числе системных? даже можно чисто системных...
либо как вариант (может быть даже более простой) - прописываются ли где-то в БД адреса зукипера?
либо как вариант (может быть даже более простой) - прописываются ли где-то в БД адреса зукипера?
DC
Коллеги, приветствую, не подскажете ли, есть ли в CH возможность найти по like '%value%' значение, пробежавшись по всем полям всех таблиц, в том числе системных? даже можно чисто системных...
либо как вариант (может быть даже более простой) - прописываются ли где-то в БД адреса зукипера?
либо как вариант (может быть даже более простой) - прописываются ли где-то в БД адреса зукипера?
Нет не прописываются(не отображаются).
при смене адреса зукиперов нужен рестарт кх.
при смене адреса зукиперов нужен рестарт кх.
DC
Системные таблицы виртуальные. Они отображают структуры из памяти в табличном виде.
DC
Такой like невозможен.
НМ
Нет не прописываются(не отображаются).
при смене адреса зукиперов нужен рестарт кх.
при смене адреса зукиперов нужен рестарт кх.
спасибо, тогда будем искать дальше происходящую магию
DC
спасибо, тогда будем искать дальше происходящую магию
В чем магия?
НМ
В чем магия?
с query_log
если в кратце - мы игрались с настройками CH в тестовой среде, поднимали зукипер и т.д.
в определенный момент, мы решили, что мы готовы внедрять CH закупили сервак, детачнули таблицы с тестовой среды, залили на серв, приаттачили их, запустили, все работает, все счастливы.
пока не заглянули в query_log который оказался пустым, точнее в нем записи заканчиваются на дате отключения тестового сервака.
разница между тестовым окружением и текущим - на тесте был зукипер, тут его нет.
в целом админов понять можно - нет кластера => зукипер особо и не нужен.
сегодня админы пол дня возились с конфигами, но не могут понять что не так
если в кратце - мы игрались с настройками CH в тестовой среде, поднимали зукипер и т.д.
в определенный момент, мы решили, что мы готовы внедрять CH закупили сервак, детачнули таблицы с тестовой среды, залили на серв, приаттачили их, запустили, все работает, все счастливы.
пока не заглянули в query_log который оказался пустым, точнее в нем записи заканчиваются на дате отключения тестового сервака.
разница между тестовым окружением и текущим - на тесте был зукипер, тут его нет.
в целом админов понять можно - нет кластера => зукипер особо и не нужен.
сегодня админы пол дня возились с конфигами, но не могут понять что не так