ну и в я ее вижу │ (32,202103)  │               5 │ 1.59 MiB   │

Ну ок, хорошо

бальшое спасибо, попробую щас с другими таблицами... там и с десяток

вам надо на реплике(ах) удалить все из detached/32-202103*
attach атачит на одной реплике (остальные качают), а detach детачит на всех.

а с вьюхами также поступать?

postpone_reason:        Not executing log entry for part 20210302_20210308_1395726_1395754_2 because source parts size (14.20 GiB) is greater than the current maximum (88.08 MiB).

на другой таблице еще такое всплыло

Это уже другая "ошибка", значит уже идут другие мержи, которые заняли все место в пуле, нужно подождать.
SELECT * FROM system.merges;

спасибо

Очень часто при падениях - реплики пытаются синхронизироваться друг с другом и начинается.. (мержи партов чаще всего. В зависимости от размера самих партов - этот процесс может затянуться)

Если там проблема такая же как и в первой таблице, то да

У вас вьюхи с TO написаны?(пишут в отдельную таблицу)

database:               default
table:                  .inner.reports_mv_rails_ips_replicated
replica_name:           01
position:               2
node_name:              queue-0044389303
type:                   GET_PART
create_time:            2021-03-06 01:33:55
required_quorum:        0
source_replica:
new_part_name:          20210301_654815_912038_76751
parts_to_merge:         []
is_detach:              0
is_currently_executing: 1
num_tries:              16432
last_exception:         Code: 234, e.displayText() = DB::Exception: No active replica has part 20210301_654815_912038_76751 or covering part (version 19.7.3.9 (official build))
last_attempt_time:      2021-03-08 23:02:33
num_postponed:          0
postpone_reason:
last_postpone_time:     0000-00-00 00:00:00

я только не могу детачить то что начинается с точки

Рестарт реплика. Он, вроде, тот же attach/detach делает
Upd. Хз как с вьюхами, не увидел

SYSTEM RESTART REPLICAS не помогло

👍 спасибо

на самом деле это очень странно что тем более несколько реплик смогли потерять не _0 парты, такого не должно быть несмотря ни на какие сбои железа.

_0 -- инсерт может быть потерян, при перезагрузке железа, потому что он существует только на одной реплике и не записан на диск, все остальное >_0 не должно теряться

ALTER TABLE default.`.inner.reports_mv_rails_ips_replicated`
DETACH PARTITION ID '20210301';

огромное спасибо, Дмитрий. Теперь похоже все отлично