Подскажите, пожалуйста. Делали drop column, завис мёрж MUTATE_PART на одной

реплике, на других начали мержи по ttl отрабатывать через несколько дней и оно как-то зависло намертво.
Ошибка на одной реплике:
Code: 49, e.displayText() = DB::Exception: Part 20201113_20201114_423207_448935_10_819682 is covered by 20201113_20201114_423207_448935_11_819682 but should be mutated to 20201113_20201114_423207_448935_10_1124385. This is a bug. (version 20.10.3.30 (official build))
Ошибки на других двух:
Code: 49, e.displayText() = DB::Exception: Part 20201113_20201114_423207_448935_11_819682 intersects previous part 20201113_20201114_423207_448935_10_1124385 (state Committed). It is a bug. (version 20.10.3.30 (official build))

В логах на первой такое:
{} <Warning> default.rawlog_shard (ReplicatedMergeTreeQueue): Mutation with version 819682 not found in partition ID 202011 (trying to mutate part 20201113_20201114_423207_448935_10_819670)

{} <Error> default.rawlog_shard: auto DB::StorageReplicatedMergeTree::queueTask()::(anonymous class)::operator()(DB::StorageReplicatedMergeTree::LogEntryPtr &) const: Code: 49, e.displayText() = DB::Exception: Part 20201113_20201114_423207_448935_10_819682 is covered by 20201113_20201114_423207_448935_11_819682 but should be mutated to 20201113_20201114_423207_448935_10_1124385. This is a bug., Stack trace (when copying this message, always include the lines below):

0. DB::StorageReplicatedMergeTree::tryExecutePartMutation(DB::ReplicatedMergeTreeLogEntry const&) @ 0xe12b12f in /usr/bin/clickhouse
1. DB::StorageReplicatedMergeTree::executeLogEntry(DB::ReplicatedMergeTreeLogEntry&) @ 0xe110eb0 in /usr/bin/clickhouse
2. ? @ 0xe18cecc in /usr/bin/clickhouse
3. DB::ReplicatedMergeTreeQueue::processEntry(std::__1::function<std::__1::shared_ptr<zkutil::ZooKeeper> ()>, std::__1::shared_ptr<DB::ReplicatedMergeTreeLogEntry>&, std::__1::function<bool (std::__1::shared_ptr<DB::ReplicatedMergeTreeLogEntry>&)>) @ 0xe481f95 in /usr/bin/clickhouse
4. DB::StorageReplicatedMergeTree::queueTask() @ 0xe146eeb in /usr/bin/clickhouse
5. DB::BackgroundProcessingPool::workLoopFunc() @ 0xe294b53 in /usr/bin/clickhouse
6. ? @ 0xe295683 in /usr/bin/clickhouse
7. ThreadPoolImpl<std::__1::thread>::worker(std::__1::__list_iterator<std::__1::thread, void*>) @ 0x7b8963d in /usr/bin/clickhouse
8. ? @ 0x7b8d153 in /usr/bin/clickhouse
9. start_thread @ 0x7fa3 in /usr/lib/x86_64-linux-gnu/libpthread-2.28.so
10. clone @ 0xf94cf in /usr/lib/x86_64-linux-gnu/libc-2.28.so
(version 20.10.3.30 (official build))

А вы случайно одновременно не использовали версии < 20.5 и >= 20.5?

Недавно обновлялись с 19 до 20.10.

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

Отключали всю запись в кх, у нас три кластера, по очереди обновляли каждый. Часа полтора заняло, наверное.

Сложно тут подсказать, мало информации. Хорошо бы issue на гитхабе завести. Может до апдейта уже какой-то странный стейт был. Может во время апдейта были рестарты старых версий? Может запустили DROP COLUMN пока версии были разные? Чтобы починить можно выбрать реплику на которой есть все данные, сделать alter table detach partition и потом attach обратно (только на ней одной). Отменятся все мержи и мутации, которые были назначены, куски перекачаются на другие реплики.

drop column делали через несколько дней после апдейта. Пробовал удалить эту очередь из зукипера и делать рестарт реплики как в https://github.com/ClickHouse/ClickHouse/issues/10368, mutate_part не ушла. С attach/detach есть проблема, у нас в этой партиции 3Тб, гнать на реплики очень сложно будет.

Удалить очередь чего?