Всем привет. помогите, пожалумста, кто чем может. досталось вот такое хозяйство

кластер кликхауса версии 22.3.7.28. в нем есть шард из 2х реплик. на обоих в определенной БД (назовем ее FOO) когда-то была создана таблица ReplicatedReplacingMergeTree (назовем ее BAR). этот шард некоторое время назад разломали (что конкретно там делали - уже неизвестно). выглядело это так, что 1я реплика работает, а 2я не стартует. сегодня починили 2ю реплику, она стартанула. делаю на ней show tables in FOO, а таблицы BAR нет.

думаю - "ок, с этой репликой хрен пойми что происходило, и это уже неважно, я просто создам таблицу заново, и она насосёт данных с 1й реплики"

таблица с 1го раза не создалась, т.к. в zookeeper-е валялась znode ее 2й реплики. я ее удалил через zkCli.sh (rmr /clickhouse/tables/<shard id>/<table name>/replicas/<replica id>) и создал таблицу, после чего данные успешно поехали с 1й реплики на 2ю. через несколько часов данные полностью синхронизировались, и тут я заметил следующий косяк (он вообще не критичный, но глаз мозолит)

короче, в /var/lib/clickhouse/data/FOO лежат симлинки на каталоги вида /var/lib/clickhouse/store/<something id>/<uuid>, в которых уже содержатся сами данные таблиц. типа такого:
# ls -l /var/lib/clickhouse/data/FOO/
total 0
...
lrwxrwxrwx 1 clickhouse clickhouse 51 Sep 6 2022 BAR -> /var/lib/clickhouse/store/569/569a4d9d-0347-42f8-b25d-5ae7a0558f88/
...

так вот, с моей таблицей вышло так, что ее симлинк (/var/lib/clickhouse/data/FOO/BAR) указывает не туда, где таблица находится на самом деле:
select name, data_paths from system.tables where database = 'FOO' and table = 'BAR';

SELECT
name,
data_paths
FROM system.tables
WHERE (database = 'FOO') AND (table = 'BAR')

Query id: 9cddea7d-399b-4720-8339-292ff518f838

┌─name──data_paths──────────────────────────────────────────────────────────────┐
│ BAR │ ['/var/lib/clickhouse/store/426/426ee10b-1f78-4c0c-8d6d-b6f80d2053d9/'] │
└───────────────────────────────────────────────────────────────────────────────┘

1 rows in set. Elapsed: 0.004 sec.

т.е., по факту таблица FOO.BAR находится здесь:
/var/lib/clickhouse/store/426/426ee10b-1f78-4c0c-8d6d-b6f80d2053d9/

а ее симлинк из /var/lib/clickhouse/data/FOO/BAR указывает в другое место:
/var/lib/clickhouse/store/569/569a4d9d-0347-42f8-b25d-5ae7a0558f88/

как я понял, это произошло из-за того, что какие-то старые ошметки этой таблицы валялись на файловой системе, и перед ее повторным созданием я их не удалил. теперь кликхаус о них тупо не знает

вопрос вот в чем:
1. можно ли это как-то поправить? хотелось удалить старые данные и быть уверенным, что кликхаус их точно уже не контролирует
2. не будет ли это влиять на работу кликхауса?

о, я сам спросил - сам ответил. в логах КХ при пересоздании таблицы сообщил, что не может создать симлинк, т.к. он уже есть: 2023.09.05 11:04:17.250397 [ 922745 ] {2fff172c-ffc8-4460-857f-98463bc657f6} <Warning> DatabaseAtomic (FOO): std::exception. Code: 1001, type: std::__1::__fs::filesystem::filesystem_error, e.what() = filesystem error: in create_directory_symlink: File exists [/var/lib/clickhouse/store/426/426ee10b-1f78-4c0c-8d6d-b6f80d2053d9/] [/var/lib/clickhouse/data/FOO/BAR] да, надо было сначала удалить его вместе с его target-каталогом. но вот вопрос: а зачем вообще используются эти симлинки, если КХ и без них функционирует?

нашел вот такую issue: https://github.com/ClickHouse/ClickHouse/issues/6787 тут Алексей пишет буквально следующее: On table creation it will: ... - create symlink /data/database/table that resembles the structure of DatabaseOrdinary; ... а потом: Additional considerations: ... - symlinks are actually unneeded but will be created for easy introspection/debugging. ... короче, я так понял, симлинки эти - просто для удобства администраторов. КХ на них не обращает внимания