关于kafka:kafka实战分区重分配可能出现的问题和排查问题思路生产环境实战干货非常干建议收藏

81次阅读

共计 8032 个字符，预计需要花费 21 分钟才能阅读完成。

日常运维
问题排查
怎么可能少了滴滴开源的
滴滴开源 LogiKM 一站式 Kafka 监控与管控平台

这篇文章源自于, 一位群友的问题, 而后就写下了这篇文章

进群加 V :jjdlmn_

Kafka 专栏整顿地址 请戳这里 0.0

先定义一下名词: 迁徙前的 Broker：OriginBroker、迁徙后的正本 TargetBroker

前提

在这之前如果你比拟理解 <font color=red> 分区重调配的原理 </font> 的话, 上面的可能更好了解;
举荐你浏览一下上面几篇文章(如果你点不进去阐明我还没有公布)

[【kafka 源码】ReassignPartitionsCommand 源码剖析(正本扩缩、数据迁徙、正本重调配、正本跨门路迁徙)]()
[【kafka 运维】正本扩缩容、数据迁徙、正本重调配、正本跨门路迁徙]()

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

如果你不想费那个精力, 那间接看上面我画的这张图, 你本人也能剖析进去可能呈现的问题; 以及怎么排查

所有异常情况

Kafka 专栏整顿地址 请戳这里

1. TargetBroker 若不在线, 迁徙脚本执行会失败

TargetBroker 若不在线, 在开始执行工作脚本的时候，校验都不会被通过呢

情景演示

BrokerId 角色 状态 正本
0 一般 Broker 失常 test-0
1 一般 Broker 宕机 无

当初将分区topic-test-0 从 Broker0 迁徙到 Broker1


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

执行异样

Partitions reassignment failed due to The proposed assignment contains non-existent brokerIDs: 1
kafka.common.AdminCommandFailedException: The proposed assignment contains non-existent brokerIDs: 1
        at kafka.admin.ReassignPartitionsCommand$.parseAndValidate(ReassignPartitionsCommand.scala:348)
        at kafka.admin.ReassignPartitionsCommand$.executeAssignment(ReassignPartitionsCommand.scala:209)
        at kafka.admin.ReassignPartitionsCommand$.executeAssignment(ReassignPartitionsCommand.scala:205)
        at kafka.admin.ReassignPartitionsCommand$.main(ReassignPartitionsCommand.scala:65)
        at kafka.admin.ReassignPartitionsCommand.main(ReassignPartitionsCommand.scala)

2. TargetBroker 在开始迁徙过程中宕机，导致迁徙工作始终在进行中

<font face=” 黑体 ” color=red size=5>Kafka 专栏整顿地址 请戳这里 </font>

个别这种状况是呈现在, 写入了节点 /admin/reassign_partitions/ 之后, 有一台 / N 台 targetBroker 中途宕机了, 导致这台 Broker 不能失常的创立新的正本和同步 Leader 操作, 就不可能持续往后面走了

情景演示

模仿这种状况, 咱们能够手动写入了节点 /admin/reassign_partitions/ 重调配信息例如：

  1. 创立一个节点写入的信息如下, 其中 Broker-1 不在线; 模仿在调配过程中宕机了;

    {"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[1]}]}
  2. 看到 /broker/topics/{topicName} 中的节点曾经变更为上面的了

  3. 接下来应该要像 Broker- 1 发送 LeaderAndIsr 申请让它创立正本并且同步 Leader；然而这个时候 Broker- 1 是不在线的状态；所以就会导致 这个工作始终在进行中, 如果你想进行其余的重调配就会提醒如下

    There is an existing assignment running.

    解决办法

只有晓得什么状况, 那解决问题思路就很清晰了, 只有把挂掉的 Broker 重启就行了;

3. 被迁徙正本没有找到 Leader, 导致 TargetReplica 始终不能同步正本

<font face=” 黑体 ” color=red size=5>Kafka 专栏整顿地址 请戳这里 </font>

只有被迁徙的正本的 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. 限流导致重调配始终实现不了

Kafka 专栏整顿地址 请戳这里

咱们个别在做分区正本重分配任务的时候, 个别都会加上一个限流值
--throttle : 迁徙过程 Broker 之间传输的速率, 单位 bytes/sec
留神这个值是 Broker 之间的限流, 并不仅仅指的是这次迁徙的几个分区正本的限流；而是蕴含其余 Topic 本身失常的数据同步的流量; 所以如果你这个限流值设置的很小, 速率比失常状况下的同步速率还要小
又或者你的同步速率比创立音讯的速率都要慢, 那么这个工作是永远完不成的！

情景演示

  1. 创立重分配任务, 限流值 1

     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. 数据量太大, 同步的贼慢

<font face=” 黑体 ” color=red size=5>Kafka 专栏整顿地址 请戳这里 </font>

呈现这个状况是很常见的一个事件, 它也不属于异样, 性能问题你没方法, 然而往往咱们做数据迁徙的时候会疏忽一个问题；那就是过期数据太多, 迁徙这个过期数据自身就没有什么意义;
能够看我之前的文章 Kafka 的灵魂伴侣 Logi-KafkaManger(4)之运维管控–集群运维 (数据迁徙和集群在线降级)

缩小迁徙的无效数据, 可能大大增加数据迁徙的效率;

解决方案

<font color=red> 缩小迁徙的数据量 </font>
如果要迁徙的 Topic 有大量数据（Topic 默认保留 7 天的数据），能够在迁徙之前长期动静地调整 retention.ms 来缩小数据量;
当然手动的来做这个操作真的是太让你烦心了, 你能够有更聪慧的抉择

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

<font color=green size=5> 滴滴开源 Logi-KM 一站式 Kafka 监控与管控平台 </font>

可视化的进行数据迁徙、分区正本重调配;

设置限流、减小数据迁徙量、迁徙实现主动清理限流信息

排查问题思路

<font face=” 黑体 ” color=red size=5>Kafka 专栏整顿地址 请戳这里 </font>

下面我把我能想到的所有可能呈现的问题解决方案都列举了进去; 那么碰到了
重分配任务始终在进行中怎么疾速定位和解决呢？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]}]}

<font color=red> 所以咱们先看节点的数据，可能让咱们指定 是哪个分区重分区呈现了问题 ;</font>

从下面数据能够指定, 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]
  1. 同时能够看到 Broker-1 是存活的
  1. 然而不在 ISR 外面的
  2. 判断进去 可能同步速率更不上, TargetBroker 可能网络情况不好, 或者自身压力也挺大；换个 TargetBroker

  3. 间接删除节点 /admin/reassign_partitions , 而后从新执行一下重分配任务; 重调配到[0,2] 中

    {"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[0,2]}]}


    能够看到曾经在 zk 中写入了新的分配情况;
    然而 topic 节点中却没有变更 AR 和ARS

    这是因为Controller 尽管收到了节点的新增告诉/admin/reassign_partitions; 然而在校验的时候, 它内存外面保留过之前的重分配任务, 所以对 Controller 而言, 它认为之前的工作还是没有失常完结的, 所以也就不会走后门的流程;

  4. 从新选举 Controller 角色 , 从新加载/admin/reassign_partitions ; 我在文章[【kafka 源码】Controller 启动过程以及选举流程源码剖析]() 外面剖析过,Controller 从新选举会从新加载 /admin/reassign_partitions 节点并持续工作的执行; 切换之后如下, 变更失常

    <font color=red > 切换 Controller, 须要你被动去删除 zk 节点 /controller</font>
    当然还有更简略的形式 滴滴开源 LogiKM 一站式 Kafka 监控与管控平台 如下

    指定一些闲暇的 Broker 当做 Controller,并立刻切换 是一个理智的抉择;

解决方案

  1. 数据量太大是因为很多过期数据; 如果你重调配的时候没有思考清理过期数据; 那么就重新分配把
    然而重分配任务同一时间只能有一个, 所以你只能暴力删除/admin/reassign_partitions ; 而后重新分配一下;
    留神重新分配的时候, 请务必设置长期的数据过期工夫, 缩小迁徙数据；并且还要让Controller 切换一下;
  2. 总结起来是
    ①. 删除节点/admin/reassign_partitions
    ②. 从新执行重分配任务
    ③. 让Controller 产生重选举

排查工具 + 思考

<font face=” 黑体 ” color=red size=5>Kafka 专栏整顿地址 请戳这里 </font>

剖析完下面的问题, 起始这个问题排查起来, 还是挺麻烦的, 看这个看那个指标什么的;
是不是能够有一个工具来 <font color=red size=4> 主动帮我 排查问题 + 提供解决方案 </font>;
既然排查思路有了, 可视化，自动化，工具化 也不是什么难事吧;
所以我在 滴滴开源 LogiKM 一站式 Kafka 监控与管控平台 上筹备提一个 ISSUE, 来简略的实现这么一个性能;
看什么时候比拟空的时候来实现它, 你要是有趣味, 也能够一起来实现它!

事实案例剖析

周五快下班的时候, 群外面有个同学问了一句上面这个问题, 而后我就我回复了一下;
起初为了具体分析就拉了一个小群来寻找蛛丝马迹

进群加 V: jjdlmn_

具体的日志我就不贴出来了, 太多了;

这位同学在 进行分区重调配的过程中, 长久了很久, 始终在进行中, 起初去百度 说让在 zk 中删除 重分配任务节点;
我告知了节点之后, 而后立马删除了这个节点, 起初发现某一台迁徙的 TargetBroker 挂了, 让他们重启之后, 重调配的工作仍旧接着进行上来了, 也就是说 TargetBroker 仍然失常的实现了正本的调配;

问题剖析

其实这个问题就是咱们下面剖析过的 第二种状况 2. TargetBroker 在开始迁徙过程中宕机，导致迁徙工作始终在进行中
具体为什么 TargetBroker 为什么会宕机 这不是咱们剖析的领域;

因为 TargetBroker 宕机了, 导致工作不能完结; 这个时候只须要重启 TargetBroker 就能够了;

尽管他们间接暴力删除了节点 /admin/reassign_partitions ; 问题也不大;
影响点在下一次开始重调配的工作时候, Controller内存外面还是报错的之前的信息, 所以下一次的工作不会被执行;
然而如果你让 Controller 重新分配之后, 那么就会继续执行了, 没有什么影响;

尽管他们这次删除了节点, 也外面开始了下一次的调配; 然而因为它重启了 TargetBroker；让原来的工作顺利的进行了上来; 哪怕没有切换Controller, 也是不会影响下一次的重分配任务的;(因为顺利进行 Controller 被告诉的之前的曾经完结了)

如果你有其余可能呈现的异样, 或者其余有对于 kafka、es、agent 等等相干问题, 请分割我, 我会补充这篇文章

欢送 Star 和共建 由滴滴开源的 kafka 的治理平台, 十分优良十分好用的一款 kafka 治理平台

滴滴开源 LogiKM 一站式 Kafka 监控与管控平台

Kafka 专栏整顿地址 请戳这里

正文完
Kafka
发表至： Kafka
2021-07-17
 0
关于kafka:大数据之-Hadoop10Kafka
关于kafka:如何使用Delta-Lake构建批流一体数据仓库
如何将-Redis-用于微服务通信的事件存储
关于kafka:二Kafka命令行操作和架构原理