当Kafka分区不可用且副本被损坏时如何尽量减少数据的丢失

本篇文章为大家展示了当Kafka分区不可用且副本被损坏时如何尽量减少数据的丢失，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

创新互联主要从事网站设计、网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务秀峰,十年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18982081108

下面专门对分区不可用进行故障重现，并给出我的一些骚操作来尽量减少数据的丢失。

故障重现

下面我用一个例子重现现分区不可用且 leader 副本被损坏的例子：

使用 unclean.leader.election.enable = false 参数启动 broker0；
使用 unclean.leader.election.enable = false 参数启动 broker1；
创建 topic-1，partition=1，replica-factor=2；
将消息写入 topic-1；
此时，两个 broker 上的副本都处于 ISR 中，broker0 的副本为 leader 副本；
停止 broker1，此时 topic-1 的 leader 依然时 broker0 的副本，而 broker1 的副本从 ISR 中剔除；
停止 broker0，并且删除 broker0 上的日志数据；
重启 broker1，topic-1 尝试连接 leader 副本，但此时 broker0 已经停止运行，此时分区处于不可用状态，无法写入消息；
恢复 broker0，broker0 上的副本恢复 leader 职位，此时 broker1 尝试加入 ISR，但此时由于 leader 的数据被清除，即偏移量为 0，此时 broker1 的副本需要截断日志，保持偏移量不大于 leader 副本，此时分区的数据全部丢失。

我的建议

在遇到分区不可用时，是否可以提供一个选项，让用户可以手动设置分区内任意一个副本作为 leader？

因为集群一旦设置了 unclean.leader.election.enable = false，就无法选举 ISR 以外的副本作为 leader，在极端情况下仅剩 leader 副本还在 ISR 中，此时 leader 所在的 broker 宕机了，那如果此时 broker 数据发生损坏这么办？在这种情况下，能不能让用户自己选择 leader 副本呢？尽管这么做也是会有数据丢失，但相比整个分区的数据都丢失而言，情况还是会好很多的。

我的骚操作

首先你得有一个不可用的分区（并且该分区 leader 副本数据已损失），如果是测试，可以以上故障重现 1-8 步骤实现一个不可用的分区（需要增加一个 broker）：

当Kafka分区不可用且副本被损坏时如何尽量减少数据的丢失

此时 leader 副本在 broker0，但已经挂了，且分区不可用，此时 broker2 的副本由于掉出 ISR ，不可选为 leader，且 leader 副本已损坏清除，如果此时重启 broker0，follower 副本会进行日志截断，将会丢失该分区所有数据。

经过一系列的测试与实验，我总结出了以下骚操作，可以强行把 broker2 的副本选为 leader，尽量减少数据丢失：

1、使用 kafka-reassign-partitions.sh 脚本对该主题进行分区重分配，当然你也可以使用 kafka-manager 控制台对该主题进行分区重分配，重分配之后如下：

当Kafka分区不可用且副本被损坏时如何尽量减少数据的丢失

此时 preferred leader 已经改成 broker2 所在的副本了，但此时的 leader 依然还是 broker0 的副本。需要注意的是，分区重分配之后的 preferred leader 一定要之前那个踢出 ISR 的副本，而不是分区重分配新生成的副本。因为新生成的副本偏移量为 0，如果自动重分配不满足，那么需要编写 json 文件，手动更改分配策略。

2、进入 zk，查看分区状态并修改它的内容：

当Kafka分区不可用且副本被损坏时如何尽量减少数据的丢失