кроме дистрибутивных таблиц. Иногда, из-за интенсивного входного потока забивается диск , из-за того, что не успевает передать далее.
Каким-то образом можно установить лимит свободного места, чтобы при достижении порога, каким-то образом не позволялось далее вставлять ?
такого нет, по сколько записей у вас за один INSERT в distributed прилетает? что значит на сервере нет ничего кроме distributed? а вставка целевая куда идет? distributed временные данные только .bin файлах хранит... а дальше обычным INSERT в целевые таблицы вставляет у вас отдельный диск под основные данные? и отдельный под временные?
> что значит на сервере нет ничего кроме distributed? Это и значит, что нет других таблиц/бд, за исключением системных. > а вставка целевая куда идет? В иные сервера дальше, через эти таблицы. > distributed временные данные только .bin файлах хранит... Да, все верно. именно ими и забивает. > у вас отдельный диск под основные данные? и отдельный под временные? Нет, на основном, где стоит кликхаус, там и бины хранятся (ждут своей очереди на отправку) Идею понял: внутренних механизмов нет. Я надеялся, что есть что-то вроде storage policy как для MT, где можно явно назначить минимум свободного места на диске.
ну вы еще не ответили на вопрос сколько у вас строк в одном INSERT запросе в эту disbtibuted?
https://clickhouse.com/docs/en/operations/server-configuration-parameters/settings#background_distributed_schedule_pool_size
> > а вставка целевая куда идет? > В иные сервера дальше, через эти таблицы. ну то есть у вас в remote_servers не прописан тот сервер на котором вы запускаете INSERT INTO distributed_table? или прописан?
>> ну вы еще не ответили на вопрос сколько у вас строк в одном INSERT запросе в эту disbtibuted? Вставка от 300к до миллиона, бывает и больше. >> ну то есть у вас в remote_servers не прописан тот сервер на котором вы запускаете INSERT INTO distributed_table? или прописан? нет, не прописан.
сколько шардов в кластере при этом? internal_replication true Для шардов?
Обсуждают сегодня