破案了....

举报
石臻臻的杂货铺 发表于 2021/09/14 12:17:15 2021/09/14
【摘要】 生产环境实战文章

直接跳到末尾:读者福利 赠4本书籍!

🔥《Kafka运维管控平台》🔥
✏️更强大的管控能力✏️
🎾更高效的问题定位能力🎾
🌅更便捷的集群运维能力🌅
🎼更专业的资源治理🎼
🌞更友好的运维生态🌞

有人报案

最近技术群里面有几个同学碰到了 删除Topic的问题, 怎么样也删除不掉,然后我协助排查之后,就做个记录,写篇文章,大家在碰到这类型的问题的时候应该怎么去排查
在这里插入图片描述

收集线索

  1. not retrying deletion 异常
  2. 版本:kafka_2.11-2.0.0
  3. 删除前在执行重分配,但是失败了,强制停止数据迁移,手动删除了节点/admin/reassign_partitions
  4. 再次重新删除提示异常Topic test is already marked for deletion
  5. 所有Broker均在线
  6. delete.topic.enable=true
  7. 检查了每个Broker都没有副本被删除,甚至也没有被标记为--delete

调查线索

从我们收集到的线索来看,有两个突破口

  1. not retrying deletion
  2. Topic test is already marked for deletion

我们先看,第2个突破口,打开kafka_2.11-2.0.0源码,全局搜索关键字is already marked for deletion
在这里插入图片描述
这个表示,你已经标记了这个topic删除了, 在zk上写入了节点/amin/delete_topics/{topicName}
上面收集线索时候我们知道是它重新执行删除的时候抛出的异常,说明zk节点已经写入了,已经准备删除了;
这里没有什么问题

问题在于为什么没有执行删除呢
所以下一个突破口就在于

Not retrying deletion of topic ....

在这里插入图片描述

通过源码我们可以看到,出现了这个异常表示的是:当前这个topic不符合重试删除的条件

怎么样才符合重试删除条件?

在这里插入图片描述

  1. 在删除队列topicsToBeDeleted里面;这个队列是从zk节点/amin/delete_topics获取的数据
  2. 当前还未开始对该Topic进题删除; 判定条件是没有副本处于开始删除的状态「ReplicaDeletionStarted」(当然如果delete.topic.enable=false这条肯定满足)
  3. 主题没有被标记为不符合删除条件; 不符合删除条件的都保存在topicsIneligibleForDeletion

抽丝剥茧,接近真相

上面的3个条件,通过对方了解到

  1. /amin/delete_topics 节点下面有数据, 线索排除

  2. 让对方查询了Deletion started for replicas这个日志,日志表示的是哪些副本状态变更成「开始删除」 ,日志有查询到如下在这里插入图片描述
    然后让查询Dead Replicas (%s) found for topic %s (这个表示的是哪些副本离线了) 也查询到如下在这里插入图片描述
    在这里插入图片描述
    从日志,和源码我们可以得出,Not retrying deletion of topic 的原因是: 删除流程已经开始,但是存在离线的或不可用的副本 ,哪些副本异常,从上面的Dead Replicas (%s) found for topic %s 的日志可以得知, 既然知道了原因,那么解决方案:聚焦副本为何离线了,让副本恢复正常就行了 不过这里我们还有再重点说一下第3种情况

  3. 前面2个说完了,接着说一下topicsIneligibleForDeletion到底是什么,什么情况下才会放到这里面来呢?

不符合Topic删除的条件是什么?

Controller初始化的时候判断条件

kafka_2.11-2.0.0 没有这个步骤

  1. 数据正在迁移中
    判断数据是否在迁移中是通过判断topic的是否存在要新增或者删除的副本, 查询/brokers/topics/{topicName}节点中有没有这两个属性值在这里插入图片描述
    在这里插入图片描述
  2. topic副本所在Broker有宕机导致的副本不在线
  3. 副本所在的数据目录log.dirs存在脱机磁盘

运行中判断条件

  1. 发起的StopReplica 请求返回异常,加入不符合删除条件
  2. 删除的过程中,发现该Topic 有副本重分配的操作 则加入不符合删除条件
  3. 删除的过程,有副本下线了,则加入不符合删除条件
  4. 开始执行副本重分配的操作, 则加入不符合删除条件

结案

经过深入源码排查走访,我们基本上确定了问题的根源

副本离线,导致的删除流程不能完成; 通过查询日志,也锁定了那些个嫌疑犯,好家伙还是团伙作案

在这里插入图片描述

最后的解决方案也很粗暴,找到副本不正常的那几台Broker, 重启 …之后副本疯狂同步(其他一些topic数据同步);最终topic正常删除了

排查手册

为了以后出现同样类似的问题,我总结了一下问题的排查手段,给大家指明一条思路; 快速破案

  1. 确保 delete.topic.enable=true ;配置文件查询
  2. 确保当前该topic没有进行 「副本重分配」 , 查询zk节点/admin/reassign_partitions的值是否有该topic、或者 节点/brokers/topics/{topicName}节点里面的属性adding_replicasremoving_replicas有没有值
  3. 确保所有副本所属Broker均在线
  4. 确保副本均在线, (Broker在线并且log.dirs没有脱机), 搜日志"Dead Replicas " 关键字查询到哪些副本异常

解放方案
根据上面的排查顺序,对应不同的解决方案;
如果正在进行 「副本重分配」 那么等待分配完成就可以正常删除了
如果是副本不在线,那么就去解决为啥不在线,该重启就重启

幕后黑手

这就完了吗?

「log.dir为什么会脱机呢?」 「脱机跟数据迁移有关系吗?」

在这里插入图片描述
在这里插入图片描述

根据以往的问题,好像数据迁移总是会伴随着一些删除上的问题
导致数据目录脱机的原因的最终BOSS是 「副本重分配」吗?

留下悬念, 下期再见!


交个朋友,再赠4本,欢度每周五

image.png

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。