примонтированный диск из Azure File Shares?
Подробнее:
1) clickhouse живет на отдельной VM, OC - ubuntu 20.x
2) Монтирую к VM диск:
sudo mount -t cifs //maAcc.file.core.windows.net/clickhousedb /var/opt/clickhouse -o vers=3.0,user=myUser,password=XXXXXw==,dir_mode=0777,file_mode=0777,actimeo=30,uid=997,gid=998
3) меняю пути в конфиге кликхауса (для data, tmp, user_files)
4) перезапускаю сервис
После перезапуска:
- в примонтированной Azure File share создаются директории, появляются файлы по пути /clickhouse/share/*
- в логах начинаются ошибки формата:
2022.09.27 19:45:24.659636 [ 4561 ] {} <Error> void DB::SystemLog<DB::MetricLogElement>::flushImpl(const std::vector<LogElement> &, uint64_t) [LogElement = DB::MetricLogElement]: std::exception. Code: 1001, type: std::__1::__fs::filesystem::filesystem_error, e.what() = filesystem error: in rename: Permission denied ["/var/opt/clickhouse/cl1/lib/clickhouse/store/4cf/4cf261e0-40f7-46f6-8cf6-14417faeb881/tmp_insert_202209_40_40_0/"] ["/var/opt/clickhouse/cl1/lib/clickhouse/store/4cf/4cf261e0-40f7-46f6-8cf6-14417faeb881/202209_40_40_0/"], Stack trace ...
——-
поиском по чату нашел похожие проблемы - но там везде люди на винде в WSL подключали диски. Может с "mount -t cifs" все-таки как-то можно ...
а нормальные диски в azure VM почему не хотите использовать? uid=101,gid=101 по идее... или у вас группа clickhouse 998 и пользователь clickhouse 997 ?
за винду могу сказать что это баг WSL2 который не может перенести все атрибуты файлов, позанимался этой проблемой нормально так.
там просто p9 файлуха не умеет в renameat2 syscall
Да, 997 это как раз clickhouse
понятия не имею но то что проблемы с rename это точно
вы на главный вопрос не ответили... почему нельзя ext4 нормальные диски которые Azure предоставляет использовать?
Шара дешевле обходилась при большом обьеме согласно нашей подписки. Но можно и диск конечно, раз с шарой никак.
Обсуждают сегодня