CH с двумя шардами cl01, cl02 и машиной zookeeper. Машины CH идентичны.
На каждой из машинах есть таблица сырыми данными логов MergeTree, Distributed таблица над ними и буферные таблицы, которые, в свою очередь надстроены над Distributed таблицей.
Данные заливались в буферные таблицы и в какой-то момент на одном из шардов (cl02) очень быстро закончилось место.
Вероятно, это произошло из-за того, что отвалился зукипер, который был неверно настроен (не удалял логи).
Зукипер настроили, почистили и оставили кластер в покое, отключив заливку данных.
Занятое под данные место на проблемном сервере cl02 стало уменьшаться — за двое суток процент занятого места уменьшился со 100% до 8%.
При этом, что удивительно, количество записей на cl02 осталось прежним, а количество записей на cl01 значительно выросло.
Данные о занятом месте и о количестве записей не меняются уже несколько часов, поэтому можно предположить, что активности с репликацией данных между серверами и слияния кусков закончены.
Я посчитал среднее количество байт на запись и получается, что на одном сервере это 24 байта на запись, а на другом 7 байт на запись.
Как такое возможно?
Выше слепки за вчера и за сегодня, соответственно.
А зачем в вашей схеме с двумя шардами - зукипер? Он же только для репликации нужен
Ну вообще может быть и мержинг партов, но не объясняет почему есть такой дисбаланс в распределении данных по серверам
Уточните, в конфиге КХ internal_replication включена?
А вы место занятое смотрите в system.parts? Или на диске du-df? Потому что это возможно парты в детачед или в дистрибьютид
Обсуждают сегодня