в system.replicas поле is_readonly
и есть метрика кол-во select value from system.metrics where metric = 'ReadonlyReplica'
мои заливалки останавливаются если ReadonlyReplica не 0

спасибо, а как правильно почистить такие парты из system.replication_queue?

Code: 234, e.displayText() = DB::Exception: No active replica has part 20200620-2-0_0_93_20 or covering part (version 20.3.11.97 (official build))

разбираться лень данные не жалко =) там уже 1581 попытка была...

Code: 234, e.displayText() = DB::Exception: No active replica has part 20200620-2-0_0_93_20 or covering part (version 20.3.11.97 (official build))

либо удалить из зукипера и сделать system restart replica https://github.com/ClickHouse/ClickHouse/issues/10368#issuecomment-616310015
либо detach partition / attach  -- но тогда реплики будут качать партицию

спасибо.
ещё такой вопрос.
у нас вставки в дистрибютед, при ридонли на одном шарде, что происходит?
фейлятся конкретные вставки в конкретные шарды только?

>фейлятся конкретные вставки в конкретные шарды только?
да

Ребят добрый день ! Помогите пожалуйста советом если кто сталкивался с рабой clickhouse copier если кластер zookeeper состоит из трёх серверов q, w, e. И мне нужно перебросить все данные с кластера A clickhouse на кластер B clickhouse. Я буду создавать задание на копирование данных между кластерами clickhouse  пример на одном сервере zookeeper  q и этого хватит? Или же это задание надо продублировать на всех нодах кластера zookeeper то есть ещё и на w и e.

на одном.

кластер зк -- это одна бд. Всегда одинаковая копия данных на все нодах ЗК, имеено для этого и нужен ЗК.

Спасибо вам большое

есть какие нибудь идеи почему может такое может быть?
в system.replicas
future parts=0, queue size=1-2, merge_in_queue=1-2

что интересно лидер = 02. Т.е. вообще неясно как таблица на 01 может иметь больше строк.
вставки везде идут в локальный Distributed engine.
единственная разница - в 01 выставлен
max_bytes_to_merge_at_min_space_in_pool=100G (чтобы он продолжал делать мерджи больших файлов когда мало потоков в пуле)

кол-во партов cnt -- разное?

да, на паре хостов партов в партиции по 150-180 штук осталось, и не мерджит сам

лидер -- это тот кто первый заргузился (или не становился RO) , он назначает мержи и все

>max_bytes_to_merge_at_min_space_in_pool=100G (чтобы он продолжал делать мерджи больших файлов когда мало потоков в пуле)
я не думаю что такой режим работы кто-то тестировал

мы делали чтобы пнуть мерджи когда материалайзТТЛ все "положил"

max_bytes_to_merge_at_min_space_in_pool  по идее про малое кол-во места на диске, а не про потоки

не проще кол-во background воркреров сделать больше?

не, там формула (из кода смотрели)
если мало потоков, меньше чем трешолд, он рисует экспоненту и ограничивает размер парта который пойдет на мердж

какой-то страшный геморой и все чтобы не дропать партиции кроном?

да мы то его уберем (параметр в дефолт), вопрос как такое вообще возможно?

т.е. сценарий такой:
01 был лидером, не успевал мерджить
потом упал в РО
потом 02 стал лидером, но ему что-то не прилетело?

не совсем ясно как вообще возможно.

как возможно разное количество строк, все вставки строго в дистрибютед?
как возможно что парты разные?
ну и как это починить =)

да, кто же знал что он так все положит=)  но с такой логикой можно слишком далеко зайти, тоже опасно