取消重新分配后如何从 kafka 代理中删除孤立的分区副本？

Question

版本

我正在使用 kafka 2.8.1（撰写本文时最新的 2.x）。

背景

我有一个ingress包含 64 个分区、3x 复制和 8 个代理的主题。我按照扩展集群文档将集群扩展到 12 个代理。我不喜欢使用该--generate选项，kafka-reassign-partitions.sh因为它不会尝试最小化数据移动。因此，我创建了一个手动新分配，将副本移动到 4 个新代理，调整首选领导者并确保每个代理有 16 个副本。我将重新分配 json 分成 16 个部分，这样我就可以控制移动副本，而不是一次性移动整个世界。此过程是最佳实践（请参阅此处和此处的文档）。

错误

然而，我在第一次重新分配时犯了一个错误，我用--cancel选项取消了它kafka-reassign-partitions.sh。相同的脚本为--execute您提供了一个 json 分配来撤消回滚的重新分配（请参阅最后的示例）。我也没有使用它来回滚已取消的重新分配。我更正了 json 文件，并根据需要继续重新分配所有 196 个副本。这里的文档暗示这应该已经纠正它。

如果不停止此类进程，则取消所有挂起的重新分配的效果将通过创建新的重新分配而被抵消。

问题

取消的重新分配错误地将分区 3 副本移至代理 8，甚至在完成分区 3 的完全重新分配后，部分“孤立”副本仍保留在代理 8 上。请参阅此处的目录大小：

> kubectl exec kafka-8 -c kafka -- du -h /var/lib/kafka/data/topics
616G    /var/lib/kafka/data/topics/ingress-28
615G    /var/lib/kafka/data/topics/ingress-40
618G    /var/lib/kafka/data/topics/ingress-8
615G    /var/lib/kafka/data/topics/ingress-48
613G    /var/lib/kafka/data/topics/ingress-0
617G    /var/lib/kafka/data/topics/ingress-24
617G    /var/lib/kafka/data/topics/ingress-36
615G    /var/lib/kafka/data/topics/ingress-60
617G    /var/lib/kafka/data/topics/ingress-52
617G    /var/lib/kafka/data/topics/ingress-12
615G    /var/lib/kafka/data/topics/ingress-4
616G    /var/lib/kafka/data/topics/ingress-32
616G    /var/lib/kafka/data/topics/ingress-20
469G    /var/lib/kafka/data/topics/ingress-3 // <--- the orphaned partial replica. 
617G    /var/lib/kafka/data/topics/ingress-56
617G    /var/lib/kafka/data/topics/ingress-44
617G    /var/lib/kafka/data/topics/ingress-16
11T     /var/lib/kafka/data/topics

它不显示在副本列表中

Topic: ingress  Partition: 3    Leader: 4       Replicas: 4,6,11        Isr: 11,6,4

问题

删除这个孤立副本的方法是什么？理想情况下，无需手动将其从卷中删除，也无需手动编辑 Zookeeper 节点。

我似乎无法通过这种方式做到这一点，kafka-reassign-partitions.sh因为我已经要求 Kafka 将分区 3 的副本移动到代理到 11、6 和 4，而不是代理 8。

该副本不会与新写入保持同步，但它确实显示在指标中，LogEndOffset因此 kafka 在某种程度上“意识到”这个孤立的分区 3 副本。

分区 3 分配

 {
      "topic": "ingress",
      "partition": 3,
      "replicas": [
        11,
        6,
        4
      ],
      "log_dirs": [
        "any",
        "any",
        "any"
      ]
    }

相关问题

有几个类似的问题暗示了这个问题，但这些问题都很旧，而且对于 AdminAPI 之前的 kafka 版本来说，因此建议手动编辑 Zookeeper 或磁盘上的文件，这对于这个生产集群来说是不合需要的。

• 最相似，但没有答案：删除未使用的卡夫卡分区
• Kafka 0.10.0.1 代理故障后分区重新分配
• 如何从kafka_2.10-0.8.1.1中删除不一致的kafka主题元数据数据
• 分区的重新分配无限地陷入“仍在进行中”状态

回滚 json 示例

Current partition replica assignment

{"version":1,"partitions":[{"topic":"ingress","partition":16,"replicas":[1,5,8],"log_dirs":["any","any","any"]},{"topic":"ingress","partition":17,"replicas":[
2,6,9],"log_dirs":["any","any","any"]},{"topic":"ingress","partition":18,"replicas":[3,7,10],"log_dirs":["any","any","any"]},{"topic":"ingress","partition":19
,"replicas":[4,0,11],"log_dirs":["any","any","any"]}]}

Save this to use as the --reassignment-json-file option during rollback

Answer 1

我通过两种方式纠正了这个问题：

1. 第一个，正如 @OneCricketeer 和类似问题的评论中提到的，是简单地rm -r（可选地-f）代理上不知道它的额外分区副本。

到目前为止，我还没有注意到 kafka 或 zk 的任何问题，并且孤立副本的指标也消失了。

这是迄今为止最快的方法，但在生产中却担心这样做。

2. 我所做的第二个选项是将代理添加回分区分配列表，使用 执行kafka-reassign-partitions.sh，然后等待重新分配以“接管”代理上的孤立副本。完成后，我从任务中删除了副本，并观察 kafka 删除了目录中的数据。

此选项使用可用的 kafka 工具，但在等待时间和数据移动方面付出了显着的代价，特别是如果孤立副本远远落后于同步副本的话。它必须赶上，才能被删除。

最后，我下次一定会尝试kafka-kit，感谢 @OneCricketeer 和融合的 kafka 社区 slack。