2. 看到/broker/topics/{topicName} 中的节点已经变更为下面的了

There is an existing assignment running.

解决方法

只要知道什么情况,那解决问题思路就很清晰了, 只要把挂掉的Broker重启就行了;

3. 被迁移副本没有找到Leader,导致TargetReplica一直不能同步副本

---

只要被迁移的副本的Leader服务挂了,并且还没有选举出新的Leader, 那么就没地方同步了

这种情况跟 情况2类似,但也有不同, 不同在于 这里可能是其他的Broker挂了导致的

情景演示

| BrokerId | 角色 | 状态 | 副本 |

| — | — | — | — |

| 0 | 普通Broker | 正常 | 无 |

| 1 | 普通Broker | 宕机 | test-0 |

现在将分区test-0 从Broker1 迁移到 Broker0

{“version”:1,“partitions”:[{“topic”:“test”,“partition”:0,“replicas”:[0],“log_dirs”:[“any”]}]}

看上面的图, TargetReplica会收到LeaderAndIsr 然后开始创建副本，并且zk中也写入了TargetBroker的AR信息;

然后开始去同步Leader的副本信息,这个时候Leader是谁? 是Broker-1上的test-0;(只有一个副本)，然后准备去同步的时候,OriginBroker不在线,就同步不了,所以TargetReplica只是创建了副本,但是还没有同步数据;如下

1. TargetReplica被创建,但是没有数据; 又因为OriginBroker不在线,所以也没有被删除副本(下图kafka-logs-30 是Broker0;kafka-logs-31是Broker1)

2. 因为整个分区重分配任务没有完成，所以 /admin/reassign_partitions/还未删除

{“version”:1,“partitions”:[{“topic”:“test”,“partition”:0,“replicas”:[0]}]}

3. /broker/topics/{topicName} 中的节点会更新为下图, 其中AR RR都还没有被清空

4. brokers/topics/test/partitions/0/state节点 看Leader为-1，并且ISR中也没有加入 TargetBroker

只要是没有同步成功,那么整个分区流程就会一直进行中;

解决方案

一般出现这种情况还是少见的,基本上单副本才会出现这种情况

一般就算OriginBroker挂了,导致一个副本下线了,那么其他的副本会承担起Leader的角色

如果只有一个副本,那么就会造成这种异常情况了,这个时候只需要把OriginBroker重启一下就行了

4. 限流导致重分配一直完成不了

---

我们一般在做分区副本重分配任务的时候,一般都会加上一个限流值

--throttle : 迁移过程Broker之间传输的速率,单位 bytes/sec

注意这个值是Broker之间的限流, 并不仅仅指的是这次迁移的几个分区副本的限流；而是包含其他Topic自身正常的数据同步的流量; 所以如果你这个限流值设置的很小, 速率比正常情况下的同步速率还要小

又或者你的同步速率比创建消息的速率都要慢, 那么这个任务是永远完不成的！

情景演示

sh bin/kafka-reassign-partitions.sh --zookeeper xxxx:2181/kafka3 --reassignment-json-file config/reassignment-json-file.json --execute --throttle 1

2. 基本上这个速率是别想完成了，admin/reassign_partitions节点一直在

3. zk中的限流配置

解决方案

将限流阈值设置大一点，重新执行一下上面的脚本，限流值加大

sh bin/kafka-reassign-partitions.sh --zookeeper xxxx:2181/kafka3 --reassignment-json-file config/reassignment-json-file.json --execute --throttle 100000000

(虽然这里执行之后还是会提醒你有任务在进行中,但是会重写限流信息的)

千万记得 任务结束要用 --verify来把限流值移除掉! 不然他会一直存在的;

5. 数据量太大,同步的贼慢

---

出现这个情况是很常见的一个事情,它也不属于异常, 性能问题你没办法,但是往往我们做数据迁移的时候会忽略一个问题； 那就是过期数据太多,迁移这个过期数据本身就没有什么意义;

可以看我之前的文章 Kafka的灵魂伴侣Logi-KafkaManger(4)之运维管控–集群运维(数据迁移和集群在线升级)

减少迁移的有效数据,能够大大增加数据迁移的效率;

解决方案

减少迁移的数据量

如果要迁移的Topic 有大量数据（Topic 默认保留7天的数据），可以在迁移之前临时动态地调整retention.ms 来减少数据量;

当然手动的来做这个操作真的是太让你烦心了, 你可以有更聪明的选择

Kafka的灵魂伴侣Logi-KafkaManger(4)之运维管控–集群运维(数据迁移和集群在线升级)

滴滴开源Logi-KM一站式Kafka监控与管控平台

可视化的进行数据迁移、分区副本重分配;

设置限流、减小数据迁移量、迁移完成自动清理限流信息

排查问题思路

======================================================================

上面我把我能想到的所有可能出现的问题解决方案都列举了出来; 那么碰到了

重分配任务一直在进行中怎么快速定位和解决呢？There is an existing assignment running.

1. 先看/admin/reassign_partitions里面的数据

---

假设一次任务如下; 有两个分区 test-0分区分在Broker[0,1] test-1分区在Broker[0,2]

{“version”:1,“partitions”:[{“topic”:“test”,“partition”:0,“replicas”:[0,1]},

{“topic”:“test”,“partition”:1,“replicas”:[0,2]}]}

恰好图中Broker1宕机了,test-0就不能完成了,test-1则正常完成; 那么这个时候/admin/reassign_partitions节点就是

{“version”:1,“partitions”:[{“topic”:“test”,“partition”:0,“replicas”:[0,1]}]}

所以我们先看节点的数据，能够让我们指定 是哪个分区重分区出现了问题 ;

从上面数据可以指定, test-0 这个分区没有完成,对应的Broker有 [0,1]

2. 再看brokers/topics/{TopicName}/partitions/{分区号}/state数据

---

通过步骤1 我知道 test-0 有问题,我就直接看节点/brokers/topics/test/partitions/0/state得到数据

这里分两种情况看

1. 如下

{“controller_epoch”:28,“leader”:0,“version”:1,“leader_epoch”:2,“isr”:[0]}

可以发现 ISR:[0], 只有0 ； 正常来说应该是我上面设置的[0,1]; 那问题就定位在 Broker-1中的副本没有加入到ISR中;

接下来的问题就是排查为啥Broker-1 没有加入到ISR了；

2. 如下, leader:-1 的情况

{“controller_epoch”:28,“leader”:-1,“version”:1,“leader_epoch”:2,“isr”:[0]}

leader:-1 表示当前没有Leader; 新增的副本没有地方去同步数据，就很迷茫;

所以接下来要排查的就是其该TopicPartition的其他副本所在Broker是不是都宕机了; 如何确定其他Broker?

看AR是否都正常;AR数据在brokers/topics/{topicName}可以看到 ;

当然你可以通过 滴滴开源-LogIKM 一站式Kafka监控与管控平台 更简单的去排查这个步骤;如下

3. 根据步骤2确定对应的Broker是否异常

---

如果找到有Broker异常，直接重启就完事了;

4.查询限流大小

---

如果步骤3还没有解决问题,也没有Broker异常,那么再判断一下流量限制的问题了

1. 首先看看节点/config/brokers/{brokerId} 是否配置了限流信息;

2. 还有节点/config/topics/{topicName}的信息

3. 并且看到Broker节点也没有加入到ISR, 那么妥妥的同步速率问题了

4. 如果查询到的限流值比较小的话,可以适当的调大一点

sh bin/kafka-reassign-partitions.sh --zookeeper xxxx:2181/kafka3 --reassignment-json-file config/reassignment-json-file.json --execute --throttle 100000000

5. 重新执行重分配任务(停止之前的任务)

---

如果上面还是没有解决问题,那么可能是你副本数据量太大,迁移的数据太多, 或者你TargetBroker网络情况不好等等,网络传输已经达到上限,这属于性能瓶颈的问题了，或许你该考虑一下 是不是重新分配一下；或者找个夜深人静的晚上做重分配的操作;

情景演示

1. test-0 分区 原本只在Broker [0]中, 现在重分配到 [0,1], 用--throttle 1 模拟一下网络传输速率慢， 性能瓶颈等

这个节点一直会存在,一直在进行中,adding_replicas 也一直显示[1]

2. 同时可以看到 Broker-1 是存活的

3. 但是不在ISR里面的

4. 判断出来 可能同步速率更不上, TargetBroker可能网络状况不好,或者本身压力也挺大； 换个TargetBroker

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）

那么如何才能正确的掌握Redis呢？

为了让大家能够在Redis上能够加深，所以这次给大家准备了一些Redis的学习资料，还有一些大厂的面试题，包括以下这些面试题

• 并发编程面试题汇总

• JVM面试题汇总

• Netty常被问到的那些面试题汇总

• Tomcat面试题整理汇总

• Mysql面试题汇总

• Spring源码深度解析

• Mybatis常见面试题汇总

• Nginx那些面试题汇总

• Zookeeper面试题汇总

• RabbitMQ常见面试题汇总

JVM常频面试:

Mysql面试题汇总（一）

Mysql面试题汇总（二）

Redis常见面试题汇总（300+题）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

• Spring源码深度解析

• Mybatis常见面试题汇总

• Nginx那些面试题汇总

• Zookeeper面试题汇总

• RabbitMQ常见面试题汇总

JVM常频面试:

[外链图片转存中…(img-zl8RV1fH-1712790406784)]

Mysql面试题汇总（一）

[外链图片转存中…(img-y6LXYZ3v-1712790406784)]

Mysql面试题汇总（二）

[外链图片转存中…(img-0LDCDfXm-1712790406784)]

Redis常见面试题汇总（300+题）

[外链图片转存中…(img-CkDrCab8-1712790406785)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-fflcZM1R-1712790406785)]