小编fpa*_*ici的帖子

我在这个集群上遇到了标题中的场景：

• 5 个分片，5 个副本
• 谷歌云计算
• 使用 ReplicatedReplacingMergeTree 仅在集群（分片和复制）上一张表。如果需要，我可以提供架构，但问题不应该依赖于此
• Clickhouse 21.8.13.1.altinitystable。（但也于30年7月20日转载）

这是事件的顺序：

• 我OPTIMIZE TABLE .... PARTITION .... FINAL在每个分片的一个节点上执行了一次。该分区相当大 (120Gb)，因此该过程将花费超过一小时的时间。
• 优化开始并像往常一样在 system.merges 和 system.replication_queue 中可见。
• 在此过程中，其中一个节点由于 GCP 维护事件而重新启动，并在几分钟后恢复。
• Clickhouse 重新启动后，它会按预期重新启动合并。尽管三个 GET_PART 操作（我假设在停机期间创建且必须复制的部分）并未启动，因为它们正在等待大型合并完成。请参阅下面的replication_queue 表的输出。90-20220530_0_1210623_1731部分确实被 OPTIMIZE 语句生成的合并所覆盖

SELECT
    replica_name,
    postpone_reason,
    type
FROM system.replication_queue

（已格式化）

replica_name:    snuba-errors-tiger-4-4 
postpone_reason: Not executing log entry queue-0055035589 for part 90-20220530_0_1210420_1730 because it is covered by part 90-20220530_0_1210623_1731 that is currently executing.
type:            GET_PART

replica_name:    snuba-errors-tiger-4-4 
postpone_reason: Not executing log entry queue-0055035590 for part 90-20220530_1210421_1210598_37 because …