2021.09.18 08:23:32.038512 [ 1428 ] {} <Error> auto DB::IBackgroundJobExecutor::jobExecutingTask()::(anonymous class)::operator()()

const: Code: 243, e.displayText() = DB::Exception: Cannot reserve 3.42 GiB, not enough space, Stack trace (when copying this message, always include the lines below):

0. DB::Exception::Exception(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int, bool) @ 0x88b64ca in /usr/bin/clickhouse
1. ? @ 0xfd9c676 in /usr/bin/clickhouse
2. DB::MergeTreeData::reserveSpace(unsigned long, std::__1::shared_ptr<DB::Space>) @ 0xfd9c4bb in /usr/bin/clickhouse
3. DB::MergeTreeData::cloneAndLoadDataPartOnSameDisk(std::__1::shared_ptr<DB::IMergeTreeDataPart const> const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, DB::MergeTreePartInfo const&, std::__1::shared_ptr<DB::StorageInMemoryMetadata const> const&) @ 0xfda25cc in /usr/bin/clickhouse
4. DB::MergeTreeDataMergerMutator::mutatePartToTemporaryPart(DB::FutureMergedMutatedPart const&, std::__1::shared_ptr<DB::StorageInMemoryMetadata const> const&, DB::MutationCommands const&, DB::BackgroundProcessListEntry<DB::MergeListElement, DB::MergeInfo>&, long, DB::Context const&, std::__1::unique_ptr<DB::IReservation, std::__1::default_delete<DB::IReservation> > const&, std::__1::shared_ptr<DB::RWLockImpl::LockHolderImpl>&) @ 0xfdd8a25 in /usr/bin/clickhouse
5. DB::StorageMergeTree::mutateSelectedPart(std::__1::shared_ptr<DB::StorageInMemoryMetadata const> const&, DB::StorageMergeTree::MergeMutateSelectedEntry&, std::__1::shared_ptr<DB::RWLockImpl::LockHolderImpl>&) @ 0xfb327fe in /usr/bin/clickhouse
6. ? @ 0xfb41b88 in /usr/bin/clickhouse
7. ? @ 0xfd12967 in /usr/bin/clickhouse
8. ThreadPoolImpl<ThreadFromGlobalPool>::worker(std::__1::__list_iterator<ThreadFromGlobalPool, void*>) @ 0x88f8fd8 in /usr/bin/clickhouse
9. ThreadFromGlobalPool::ThreadFromGlobalPool<void ThreadPoolImpl<ThreadFromGlobalPool>::scheduleImpl<void>(std::__1::function<void ()>, int, std::__1::optional<unsigned long>)::'lambda1'()>(void&&, void ThreadPoolImpl<ThreadFromGlobalPool>::scheduleImpl<void>(std::__1::function<void ()>, int, std::__1::optional<unsigned long>)::'lambda1'()&&...)::'lambda'()::operator()() @ 0x88faf9f in /usr/bin/clickhouse
10. ThreadPoolImpl<std::__1::thread>::worker(std::__1::__list_iterator<std::__1::thread, void*>) @ 0x88f65af in /usr/bin/clickhouse
11. ? @ 0x88fa043 in /usr/bin/clickhouse
12. start_thread @ 0x76db in /lib/x86_64-linux-gnu/libpthread-2.27.so
13. clone @ 0x12171f in /lib/x86_64-linux-gnu/libc-2.27.so
(version 21.4.3.21 (official build))
2021.09.18 08:23:32.038548 [ 1288 ] {} <Error> auto DB::IBackgroundJobExecutor::jobExecutingTask()::(anonymous class)::operator()() const: Code: 243, e.displayText() = DB::Exception: Cannot reserve 3.40 GiB, not enough space, Stack trace (when copying this message, always include the lines below):

Check inodes df -i

И используйте свежую версию кликхауса

хорошая идея, но нет 1%

clickhouse-server --version ClickHouse server version 21.8.4.51 (official build).

Странно. In recent versions we have added better diagnostics on free space. It will show you the filesystem path, the amount of total and free space and inodes.

Тогда забейте. Может у вас бекап делался на этот же диск или ещё что-то, что на короткий промежуток времени забило диск. Посмотрите в мониторинге.

бэкапа нет... )

Optimize тоже не запускали?

А зря. Можно сделать хотя бы самый простой инкрементальный, чтобы места много не занимал. Раз в сутки сохранять новые записи за эти сутки в csv и гзипом. Так хоть можно будет восстановить всё кроме последнего дня.

у нас резервирование, и на второй сервак льются те же данные, типа дев

не запускали Вопросик такой, есть где лог по подкапотным операциям кликхауса, время планового того же optimize к примеру

В конфиге есть путь до файла и уровень логирования. Попробуйте выкрутить на максимум.

уже выставлени trace