Всем доброго времени суток! Подскажите пожалуйста о чем говорят следующие

логи?
<Information> MergeTreePartsMover: Failed to swap 202104_902_902_0. Active part doesn't exist. Possible it was merged or mutated. Will remove copy on path '/opt/clickhouse_cold/data/logs/detached/202104_902_902_0/'.
2021.04.15 11:10:59.984514 [ 29766 ] {} <Information> MergeTreePartsMover: Failed to swap 202104_95_855_732. Active part doesn't exist. Possible it was merged or mutated. Will remove copy on path '/opt/clickhouse_cold/data/logs/detached/202104_95_855_732/'.
2021.04.15 11:11:05.306568 [ 29772 ] {} <Information> MergeTreePartsMover: Failed to swap 202104_898_898_0. Active part doesn't exist. Possible it was merged or mutated. Will remove copy on path '/opt/clickhouse_cold/data/logs/detached/202104_898_898_0/'.

Всем доброго времени суток! Кто нибудь может подсказать куда копать? Заранее благодарю за ответ.

у вас реплицируемые таблицы? данные как вставляете в Distributed или напрямую? всякие там OPTIMIZE ... и т.п. употребляете? все реплики живые? мутациями пользуетесь?

1 шард, две реплики, дистрибьютед таблиц нет, optimize и мутации не употребляем

правда в макросах указан один и тот же номер шарда ( 01 ), но почему то вывод select * from system.clusters показывает два шарда: ─cluster──┬─shard_num─┬─shard_weight─┬─replica_num─┬─host_name─────── ads_repl │ 1 │ 1 │ 1 │ ch03-adv ads_repl │ 2 │ 1 │ 1 │ ch04-adv но так было всегда и проблем раньше небыло

в путях для ReplicatedMergeTree номер шарда через макрос прописывается {shard} <remote_servers> скорее всего скопировали и macros.xml неправильный поправьте судя по всему у вас данные теперь не в репликах, а разбиты на две части ... куда вставляли там и остались...

через {shard} в путях и прописываем макросы, данные на двух серверах бьются по кол-ву (инсерты идут только на 1 сервер)

только на 1 сервере постоянно идут сообщения вида <Information> MergeTreePartsMover: Failed to swap 202104_89357_95544_5359. Active part doesn't exist. Possible it was merged or mutated. Will remove copy on path '/opt/clickhouse_cold/data/medtizer/logs/detached/202104_89357_95544_5359/ и с каждым таким сообщением файлов в detached каталоге становится больше

если у вас на обоих серверах system.macros одинаковый {shard} это норм и должен еще быть {replica} разные и они должны быть прописаны тоже в пути

реплика указаны разные ( через {replica}), шард одинаковый

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

у вас никаких storage policy не используется? SELECT * FROM system.disks одну запись показывает?

используется: ┌─name───────────┬─path──────────────────┬───free_space─┬───total_space─┬─keep_free_space─┐ │ cold_data_disk │ /opt/clickhouse_cold/ │ 27217444864 │ 593055903744 │ 40000000000 │ │ default │ /var/lib/clickhouse/ │ 126492344320 │ 1331831013376 │ 0 │ └────────────────┴───────────────────────┴──────────────┴───────────────┴─────────────────┘

ну, есть сильное подозрение что у вас данные свежие достаточно которые еще не успели отреплицироваться переезжают в cold_data_disk надо storage policy чинить IMHO

даже если и так то они же не должны отдетачиваться...

part_log отсутствует... а вот инфа из system.parts по одной из таких партов partition: 202104 name: 202104_2572687_2572687_0 part_type: Wide active: 0 marks: 2 rows: 20 bytes_on_disk: 4053 data_compressed_bytes: 2373 data_uncompressed_bytes: 4847 marks_bytes: 1632 modification_time: 2021-04-16 15:54:39 remove_time: 2021-04-16 15:54:42 refcount: 1 min_date: 0000-00-00 max_date: 0000-00-00 min_time: 2021-04-16 15:54:38 max_time: 2021-04-16 15:54:39 partition_id: 202104 min_block_number: 2572687 max_block_number: 2572687 level: 0 data_version: 2572687 primary_key_bytes_in_memory: 34 primary_key_bytes_in_memory_allocated: 192 is_frozen: 0 database: db1 table: logs_views engine: ReplicatedMergeTree disk_name: default path: /var/lib/clickhouse/data/db1/logs_views/202104_2572687_2572687_0/ hash_of_all_files: 7bd3295d45dcfabd4abb3dca72cd9924 hash_of_uncompressed_files: 4b72eb153ffe6d0675c3fea537569600 uncompressed_hash_of_compressed_files: fdaa595acb90bf0023d961ae900406b1 она находится на системной диске который использует политику default, вторая (кастомная политика) используется для монтирования в /opt, непонятно почему туда этот парт перемещается, да еще и в detached. На системном диске свободно порядка 160Гб