记一次 Kafka 集群的故障恢复

Kafka 集群部署环境

1、kafka 集群所用版本 0.9.0.1

2、集群部署了实时监控: 通过实时写入数据来监控集群的可用性, 延迟等;

Part 1

1 集群故障发生

• 集群的实时监控发出一条写入数据失败的报警, 然后马上又收到了恢复的报警, 这个报警当时没有重要,没有去到对应的服务器上去看下 log, 恶梦的开始啊~~~

• 很快多个业务反馈 Topic 无法写入, 运维人员介入

2 故障解决

• 运维人员首先查看 kafka broker 日志, 发现大量如下的日志:

• 这个问题就很明了了, 在之前的文章里有过介绍: Kafka 运维填坑, 上面也给出了简单修复, 主要原因是 新版 kafka 客户端 sdk 访问较旧版的 kafka, 发送了旧版 kafka broker 不支持的 request, 这会导致 exception 发生, 然后同批次 select 出来的所有客户端对应的 request 都将被抛弃不能处理,代码在 SocketServer.scala 里面, 大家有兴趣可以自行查阅

1.这个问题不仅可能导致客户端的 request 丢失, broker 和 broker, broker 和 controller 之间的通讯也受影响；’

2.这也解释了为什么 实时监控 先报警 然后又马上恢复了: 不和这样不被支持的 request 同批次处理就不会出现问题；

• 解决过程:

我们之前已经修复过这个问题, 有准备好的相应的 jar 包;

运维小伙伴开始了愉快的 jar 包替换和启动 broker 的工作~~~~~~

3 集群恢复

• kafka broker 的优雅 shutdown 的时间极不受控, 如果强行 kill -9 在 start 后要作长时间的 recovery, 数据多的情况下能让你等到崩溃；

• 集群重启完, 通过 log 观察, ArrayIndexOutOfBoundsException 异常已经被正确处理, 也找到了相应的业务来源；

• 业务反馈 Topic 可以重新写入；

然而, 事件并没有结束, 而是另一个恶梦的开始

Part 2

1 集群故障再次发生

• 很多业务反馈使用原有的 group 无法消费 Topic 数据;

• 用自己的 consumer 测试, 发现确实有些 group 可以, 有些 group 不能消费;

• 一波不平一波又起, 注定是个不平凡的夜晚啊, 居然还有点小兴奋~~~

2 故障解决

• 查看 consumer 测试程序不能消费时的日志,一直在重复如下 log:

1.第一条日志 说明 consumer 已经确认了当前的 coordinator, 连接没有问题;

2.第二条日志显示没有 Not coordinator, 对应 broker 端是说虽然 coordinator 确认了,但是没有在这个 coodinator 上找到这个 group 对应的 metada 信息;

3.group 的 metada 信息在 coordinator 启动或__consuser_offsets 的 partion 切主时被加载到内存,这么说来是相应的__consumer_offsets 的 partition 没有被加载;

4.关于 coordinator, __consumer_offsets, group metada 的信息可以参考 Kafka 的消息是如何被消费的?

• 查看 broker 端日志, 确认 goroup metadata 的相关问题

1.查找对应的__consumer_offsets 的 partition 的加载情况, 发现对应的

2.没有找到下面类似的加载完成的日志:

也没有发生任何的 exception 的日志

3.使用 jstack 来 dump 出当前的线程堆栈多次查看, 证实一直是在加载数据,没有卡死;

现在的问题基本上明确了, 有些__consumer_offsets 加载完成了,可以消费, 些没有完成则暂时无法消费, 如果死等 loading 完成, 集群的消费可以正常, 但将花费很多时间;

• 为何 loading 这些__consumer_offsets 要花费如此长的时间?

1.去到__conuser_offsets partition 相应的磁盘目录查看,发生有 2000 多个 log 文件, 每个在 100M 左右;

2.kaka 的 log compac 功能失效了, 这个问题在之前的文章里有过介绍: Kafka 运维填坑,

3.log compact 相关介绍可以参考 Kafka 的日志清理-LogCleaner

• 手动加速 Loading:

即使 log cleaner 功能失败, 为了加速 loading, 我们手动删除了大部分的 log 文件; 这样作有一定风险, 可能会导致某些 group 的 group metadata 和 committed offset 丢失, 从而触发客户端在消费时 offset reset;

3 故障恢复

• 所有__consumer_offset 都加载完后, 所有 group 均恢复了消费;

总结

• 对实时监控的报警一定要足够重视;

• 更新完 jar 包, 重启 broker 时, 三台存储__consumer_offsets partition 合部同时重启,均在 Loading 状态, 这种作法不合适,最多同时重启两台, 留一台可以继续提供 coordinattor 的功能;

• 加强对 log compact 失效的监控, 完美方案是找到失效的根本原因并修复;

本文转载自公众号 360 云计算（ID：hulktalk）。

原文链接：

https://mp.weixin.qq.com/s/_n7kGByxoJRkLVQpVYcPGg