Добрый день. Много раз уже обсуждали проблему No active replica

has part и зависшие парты в replication_queue. Всегда предлагаете решение detach+attach+system restart replica или идти чистить очередь руками.
Стали слишком часто появляться такие зависшие парты в очереди репликации по конкретной таблице. На нее идет достаточно много небольших инсертов. Пишем в один сервер еще с 2х читаем, в них не пишем. Можно ли как-то заставить парт остаться на сервере куда пишем, смерджиться и дальше отправить на реплики?

репликация это по сути лог в котором реплики события типа GET_PART, ATTACH_PART, MERGE_PART регистрируют вообще при обработке GET_PART ищется не сам парт для скачивания, а парт его покрывающий по номерам блоков вы может что-то еще делаете кроме мелких вставок с этими партами? если по system.part_log во всех репликах поискать по имени парта (там два поля part_name и source_part_names кажется массив) то что выдает?

да, висит GET_PART в очереди репликации с такой ошибкой No active replica has part 73ee5f8e20f8e56fd891b646bedf6add_8971_8975_1 or covering part source replica пустая, num_tries>1000. В part_log по part_name=‘73ee5f8e20f8e56fd891b646bedf6add_8971_8975_1’ нашел DownloadPart+RemovePart

<background_schedule_pool_size>256</background_schedule_pool_size> <background_fetches_pool_size>16</background_fetches_pool_size> не хватает у вас фетч пула, не успевает скачивать реплика

выставлено в 1024+64

надо смотреть тогда что происходит. Сколько инсертов в секунду?

конкретно в эту таблицу, или вообще?

вообще

4-6 штук

надо читать лог, почему парт _0 не был скачан

может ли быть такое, что парт уже смерджился на реплике, куда был вставлен и далее не может скачаться репликой?

еще весь лог постоянно засран таким 2023.11.06 14:36:16.489537 [ 67525 ] {} <Warning> (ReplicatedMergeTreePartCheckThread): Checking part 73ee5f8e20f8e56fd891b646bedf6add_14067_14738_448 2023.11.06 14:36:16.614118 [ 67525 ] {} <Warning> (ReplicatedMergeTreePartCheckThread): Checking if anyone has a part 73ee5f8e20f8e56fd891b646bedf6add_14067_14738_448 or covering part.

это не так работает. делается insert. Появляется парт _0, реплики создают GET задание реплики или качают или нет (может у них пул занят или они вообще выключены) реплика назначает мерж и мержит какие-то парты в _1, реплики назначают себе такой же мерж если реплики не имеют исходных партов, то они их ждут какое-то время, потом сдаются и качают _1 если _1 уже нету, то они скачают _2 и т.д.

да и пофиг zgrep "Checking if anyone has a part" clickhouse-server.log.1.gz|wc -l 85

на реплике, куда идет вставка нашел, что этот парт получился в результате мерджей таких партов [‘73ee5f8e20f8e56fd891b646bedf6add_8960_8960_0','73ee5f8e20f8e56fd891b646bedf6add_8961_8961_0','73ee5f8e20f8e56fd891b646bedf6add_8962_8962_0','73ee5f8e20f8e56fd891b646bedf6add_8963_8963_0','73ee5f8e20f8e56fd891b646bedf6add_8964_8964_0']

ну ищите почему их не было на других репликах

а они полюбому должны быть хотя бы на одной реплике?

ну реплика которая их смержила их имела, т.е. они точно были на реплике в которую вы инсертите

на одной реплике ничего нет по этим партам, на других есть DownloadPart+RemovePart

я правильно понимаю, что нужно эти в зукипер и там все чистить для этой реплики, которая не может найти парт? И почему такое может регулярно случаться? Проблем с рестартом машины, сетью или что еще можно посмотреть?

ну такого не может быть

да это само починится, почему надо что-то чистить?

у меня была такая история - в кубере на нодах зукипера кончалось место. Не хватало параметра autopurge: purgeInterval: 1

Стикер

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

какая версия КХ? я бы читал лог, понять почему реплика не смогла скачать _0 парт

Старая версия 21.2.9.41 В очереди появился новый парт, который завис Вот что в логах https://pastila.nl/?00ac30c5/917a9e817df5da182572f097b64b5b98#CvhP2IkkMn3JJinVqKyR+g== Из этой таблицы 1 раз в час данные переносятся в другую таблицу и партиция удаляется на сервере, на котором вставляются данные. Мб это как-то может приводить к проблеме?

по идее если партиция дропается, то репликам не нужен был бы этот парт. попробуйте system sync replica перед drop partition , может это какой-то старый баг

ок, попробуем добавить