取消重新分配后如何从kafka代理中删除孤儿分区副本？
版本
我正在使用kafka 2.8.1 (撰写本文时最晚的2.x )。
背景
我有一个主题ingress，它有64个分区、3x复制和8个代理。在展开群集文档之后，我将集群扩展到12个代理。我不喜欢将--generate选项用于kafka-reassign-partitions.sh，因为它并不试图最小化数据移动。因此，我创建了一个手动的新任务，将副本移动到4个新的代理，调整首选领导人，并确保每个代理都有16个副本。我把重新分配的json分成16部分，这样我就可以控制移动的复制品，而不是一次移动整个世界。这个过程是最佳实践(请参阅docs、这里和这里)。
错误
但是，我在第一次重新分配时犯了一个错误，我取消了kafka-reassign-partitions.sh的kafka-reassign-partitions.sh选项。--execute上的相同脚本为您分配了一个json赋值，以撤消回滚的重新分配(参见最后的示例)。我也没有用这个来回滚被取消的调任。我更正了我的json文件，然后按照我的意愿重新分配全部196个副本。这里的文档意味着这应该是正确的。
如果不停止这类过程，则取消所有待决重新分配的效果无论如何都将通过创建新的重新分配来抵消。
问题
取消的重新分配错误地将分区3副本移动到broker 8，甚至在完成分区3的完全重新分配之后，broker 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实现这一点，因为我已经要求卡夫卡将分区3的副本移动到11、6和4 --而不是broker 8。
这个副本并不是最新的新写，但它确实显示在LogEndOffset指标中，所以kafka在某种程度上“知道”这个孤立的分区3副本。
分区3分配
{
"topic": "ingress",
"partition": 3,
"replicas": [
11,
6,
4
],
"log_dirs": [
"any",
"any",
"any"
]
}相关问题
有几个类似的问题暗示了这个问题，但是在AdminAPI之前，卡夫卡的版本已经过时了，因此建议手动编辑磁盘上的动物园管理员或文件，这对于这个生产集群来说是不可取的。
回滚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回答 1
Stack Overflow用户
发布于 2022-08-22 20:09:43
我以下列方式纠正了这一问题：
- 第一个，正如@OneCricketeer和相似问题的注释中所提到的，就是简单地使用
rm -r(可选地使用-f)，在代理上添加不知道的分区副本。
到目前为止，我还没有注意到卡夫卡或zk的任何问题，孤儿副本的度量标准也没有了。
到目前为止，这是最快的方法，但在生产中担心地做到这一点。
- 我还做的第二个选项是将代理添加回分区分配列表，使用
kafka-reassign-partitions.sh执行，并等待重新分配“接管”代理上孤立的副本。完成后，我从作业中删除了副本，然后看着kafka删除目录中的数据。
这个选项使用了卡夫卡工具，但在等待和数据移动中花费了明显的代价，特别是如果孤儿已经远远落后于同步副本。它必须跟上，只是要被删除。
最后，我肯定会尝试卡夫卡下一次，感谢@OneCricke粘性和合流卡夫卡社区的松懈。
https://stackoverflow.com/questions/73393376
复制相似问题
腾讯云开发者
