大分区的 OPTIMIZE FINAL 阻止了 GET_PART 操作并阻止节点接受查询

Question

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

• 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 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-0055035591 for part 90-20220530_1210599_1210623_6 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:
type:            MERGE_PARTS

• 复制延迟的指标增加到 1:30 分钟，并且分布式表在合并完成之前（90 分钟后）不会向该节点发送任何查询

这是正常行为吗？如果是，有没有办法防止长合并在重新启动时阻止复制？ max_replica_delay_for_distributed_queries在集群上设置为 300 秒。我原以为 1:30 分钟的延迟会被忽略，但事实似乎并非如此，因为没有查询被路由到受影响的节点。还有另一种方法可以告诉 Clickhouse 忽略复制延迟吗？

谢谢菲利波