(2 шарда + 2 реплики), в какой-то момент мы отказались от репликации, конвертировали все таблици из Replicated в обычные но оставили шардирование, то есть поверх шардированных таблиц осталась Distributed таблица
В конфигурации <remote_servers> убрали у каждого шарда реплику и стали писать только в 2 первых сервера и вроде все хорошо, но на диске стали заканчиваться inode
Выяснилось что они уходят на мелкие файлы (сейчас их 100 млн) в каталогах:
на одном сервере
/var/lib/clickhouse/store/71b/71b11585-6976-4a12-bb42-d11516d87915/shard2_all_replicas
и на втором
/var/lib/clickhouse/store/71b/71b11585-6976-4a12-bb42-d11516d87915/shard1_all_replicas
Изучение документации на предмет что за каталоги shard1_all_replicas/shard2_all_replicas и почему в них пишется много мелких файлов не дало результат
Подскажите в чем может быть беда?
Это инсерты в distributed таблицу, которые она затем ппередает в шарды. Посмотрите в логе кх , там должны быть записи почему не удается.
Удалось выяснить имя этой таблички по uuid, но пока совершенно непонятно почему в каталоге копятся файлы, у других distributed табличек файлы появляются и исчезают довольно быстро, а у этой там миллионы накопились В логе только видно огромное количество такого 2023.05.04 14:46:20.080841 [ 683076 ] {} <Debug> log.sn.DirectoryMonitor: Sending /var/lib/clickhouse/store/71b/71b11585-6976-4a12-bb42-d11516d87915/shard1_all_replicas/168349883.bin to 172.27.100.135:9000 (1.00 rows, 119.00 B bytes) и еще больше insert что в нее прилетают от киттенхаусов вида 2023.05.04 14:50:59.298265 [ 767032 ] {7f874ceb-ac48-4479-b668-beffada2d1d5} <Debug> executeQuery: (from [::ffff:10.172.230.204]:60212, user: kittenhouse) INSERT INTO log.sn(time,free,transport_class_type,carmodel,carname,caryear,city_id,latitude,status,transport_type,sn_id,order_id,driver_id,longitude) VALUES (stage: Complete) Ошибок по сути и нет, все вставляется и передается, иначе и быть не может, тогда бы и по другим таблицам копились файлы
Возможно ли такое, что там просто лежит какое-то старье, возможно ранее был сбой передачи и они не удалились и остались (или какой-то баг в КХ) Можно ли остановить КХ, переименовать этот каталог и запустить КХ ? А потом просто удалить этот каталог.
просто посмтреть по времени создания файлов можно, если старые можно просто удалить
понял, огромное спасибо!
есть ещё system.distribution_queue, там очередь distributed таблиц, и ошибки там могут быть видны
Ну разбирайтесь почему по одной строке китенхауз присылает. Он должен аккумулировать
Можно просто все старые .bin файлы удалить в этом каталоге find -mtime .. -delete
какие-то ошибка там есть, но не сильно понятные Code: 32. DB::Exception: Attempt to read after eof: while receiving packet from 172.27.100.135:9000: While sending /var/lib/clickhouse/store/71b/71b11585-6976-4a12-bb42-d11516d87915/shard1_all_replicas/168176264.bin. (ATTEMPT_TO_READ_AFTER_EOF) (version 23.2.6.34 (official build))
Не ответила та нода куда инсертили
это сильно долго для 100 млн мелких файлов в каталоге, имхо проще stop click/mv dir/start click, а потом через rsync с пустым каталогом снести его
Обсуждают сегодня