Всем привет. На одном из шардов наблюдаю в system.replication_queue такую ошибку

(видимо давно застрявшую): last_exception: Code: 234. DB::Exception: No active replica has part 20230625_4384_4417_2 or covering part. (NO_REPLICA_HAS_PART) (version 22.7.5.13 (official build)).
Я не знаю как это произошло, но подозреваю, что это из-за того, что машина несколько раз зависала, а кворум вставки не был включен (если вторая реплика вообще существовала на тот момент).
Эта реплика показывает двухмесячный Absolute delay - видимо из-за этого парта (остальные данные "вокруг" - вроде совпадают).
Допустим, я хочу "забыть" об этом парте - как это сделать? В select * from system.parts where name = '20230625_4384_4417_2' его нет.

select * from system.zookeeper where path = '/clickhouse/tables/1/some.table/replicas/1-1/parts' and name='20230625_4384_4417_2' format Vertical
- тоже нету.

count() на репликах при этом различается SELECT count() from some.table__shard.

select * from system.zookeeper where path = '/clickhouse/tables/1/some.table/replicas/1-1/queue' format Vertical
name: queue-0000791719
create_time: 2023-06-26 15:34:32
source replica:
block_id:
get
20230625_4384_4417_2

select * from system.replicas where table = 'table__shard' format Vertical
queue_size: 1
inserts_in_queue: 1
queue_oldest_time: 2023-06-26 15:34:32
inserts_oldest_time: 2023-06-26 15:34:32
oldest_part_to_get: 20230625_4384_4417_2
absolute_delay: 5738629

SELECT * FROM clusterAllReplicas('cluster-name',system.part_log) WHERE name='20230625_4384_4417_2' ORDER BY event_time FORMAT Vertical можно посмотреть если ничего не найдете... попробуйте просто ALTER TABLE .. .ON CLUSTER 'cluster-name' DETACH PART '20230625_4384_4417_2';

в part_log ничего не нашлось 🤷🏿 detach part фейлит с DB::Exception: No part 20230625_4384_4417_2 in committed state. (NO_SUCH_DATA_PART)

А в replication_queue Какая source replica стоит?

пустое значение

Как раз тот хост, с которого нужно тянуть данные + есть обычные мержи (основной сервер .79, реплика .19) │ default │ jaeger_index_local │ 10.72.134.19 │ 0 │ queue-0000722271 │ MERGE_PARTS │ 2023-09-02 10:25:13 │ 0 │ 10.72.134.79 │ 20230902_52026_52057_3 │ ['20230902_52026_52037_2','20230902_52038_52048_2','20230902_52049_52054_1','20230902_52055_52055_0','20230902_52056_52056_0','20230902_52057_52057_0'] │ 0 │ 1 │ 1 │ │ 1970-01-01 00:00:00 │ 2023-09-02 10:25:14 │ 1 │ Not executing log entry queue-0000722271 for part 20230902_52026_52057_3 because it is not disjoint with part 20230902_52049_52054_1 that is currently executing. │ 2023-09-02 10:25:13 │ Regular │

лучше через SELECT * FROM system.replication_queue WHERE table='jaeger_index_local' FORMAT Vertical расшарить а то так читать неудобно... в расшаренных данных нет упоминания проблемного парта 20230625_4384_4417_2

человек перепутал, видимо, вопрос был мне :) ответил уже выше - пустое значение в source replica

а событие какое? как выглядит вывод вообще select указанного?

replica_name: 1-1 position: 0 node_name: queue-0000791719 type: GET_PART create_time: 2023-06-26 15:34:32 required_quorum: 0 source_replica: new_part_name: 20230625_4384_4417_2 parts_to_merge: [] is_detach: 0 is_currently_executing: 0 num_tries: 3032067 last_exception: Code: 234. DB::Exception: No active replica has part 20230625_4384_4417_2 or covering part. (NO_REPLICA_HAS_PART) (version 22.7.5.13 (official build)) last_attempt_time: 2023-09-02 02:59:36 num_postponed: 0 postpone_reason: last_postpone_time: 1970-01-01 00:00:00 merge_type:

ну что ж... zkCli.sh или clickhouse-keeper client в помощь...

а что можно сделать? удалить джоб из очереди? как-то стрёмно.. как определяется задержка репликации? - у меня что-то сомнения что она рассосётся после этого

я думаю что absolute_delay считается как разница между min(create_time) из system.replication_queue он же queue_oldest_time, inserts_oldest_timemerges_oldest_time, part_mutations_oldest_time из system.replicas) и last_queue_update из system.replicas https://www.perplexity.ai/search/1e5885a1-2d34-4eca-a5d0-ca3cd95bbc55?s=u

хм, спасибо, подумаю что с этим делать..

все эти таблицы в system просто в итоге пробрасывают запросы к zookeeper Данным и в принципе очередь можно чистить но только в исключительных случаях, когда через ATTACH / DETACH ничего не получилось сделать можно еще если INSERT контроллируете сделать DETACH / ATTACH TABLE db.name и потом SYSTEM RESTART REPLICA db.name оно должно со стророны реплики очередь пересоздать...

спасибо, потесчу