记一次Kafka集群的故障恢复Kafka源码分析-汇总

  • Kafka 集群部署环境
    1. kafka 集群所用版本 0.9.0.1
    2. 集群部署了实时监控: 通过实时写入数据来监控集群的可用性, 延迟等;

集群故障发生

  • 集群的实时监控发出一条写入数据失败的报警, 然后马上又收到了恢复的报警, 这个报警当时没有重要,没有去到对应的服务器上去看下log, 恶梦的开始啊~~~
  • 很快多个业务反馈Topic无法写入, 运维人员介入

故障解决

  • 运维人员首先查看kafka broker日志, 发现大量如下的日志:
[2017-10-12 16:52:38,141] ERROR Processor got uncaught exception. (kafka.network.Processor)
java.lang.ArrayIndexOutOfBoundsException: 18
        at org.apache.kafka.common.protocol.ApiKeys.forId(ApiKeys.java:68)
        at org.apache.kafka.common.requests.AbstractRequest.getRequest(AbstractRequest.java:39)
        at kafka.network.RequestChannel$Request.<init>(RequestChannel.scala:79)
        at kafka.network.Processor$$anonfun$run$11.apply(SocketServer.scala:426)
        at kafka.network.Processor$$anonfun$run$11.apply(SocketServer.scala:421)
        at scala.collection.Iterator$class.foreach(Iterator.scala:742)
        at scala.collection.AbstractIterator.foreach(Iterator.scala:1194)
        at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
        at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
  • 这个问题就很明了了, 在之前的文章里有过介绍: Kafka运维填坑, 上面也给出了简单修复, 主要原因是 新版kafka 客户端 sdk访问较旧版的kafka, 发送了旧版 kafka broker 不支持的request, 这会导致exception发生, 然后同批次select出来的所有客户端对应的request都将被抛弃不能处理,代码在 SocketServer.scala里面, 大家有兴趣可以自行查阅
    1. 这个问题不仅可能导致客户端的request丢失, broker和broker, broker和controller之间的通讯也受影响;
    2. 这也解释了为什么 实时监控 先报警 然后又马上恢复了: 不和这样不被支持的request同批次处理就不会出现问题;
  • 解决过程:
    1. 我们之前已经修复过这个问题, 有准备好的相应的jar包;
    2. 运维小伙伴开始了愉快的jar包替换和启动broker的工作~~~~~~

集群恢复

  • kafka broker的优雅shutdown的时间极不受控, 如果强行kill -9 在start后要作长时间的recovery, 数据多的情况下能让你等到崩溃;
  • 集群重启完, 通过log观察, ArrayIndexOutOfBoundsException异常已经被正确处理, 也找到了相应的业务来源;
  • 业务反馈Topic可以重新写入;

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

集群故障再次发生

  • 很多业务反馈使用原有的group无法消费Topic数据;
  • 用自己的consumer测试, 发现确实有些group可以, 有些group不能消费;
  • 一波不平一波又起, 注定是个不平凡的夜晚啊, 居然还有点小兴奋~~~

故障解决

  • 查看consumer测试程序不能消费时的日志,一直在重复如下log:
Group "xxx" coordinator is xxx.xxx.xxx.xxx:9092 id 3
Broker: Not coordinator for group
  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的加载情况, 发现对应的__consumer_offsets正在被Loading;
Loading offsets and group metadata from [__consumer_offsets,19] (kafka.coordinator.GroupMetadataManager)
  1. 没有找到下面类似的加载完成的日志:
Finished loading offsets from [__consumer_offsets,27] in 1205 milliseconds. (kafka.coordinator.GroupMetadataManager)

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

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

故障恢复

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

总结

  • 对实时监控的报警一定要足够重视;
  • 更新完jar包, 重启broker时, 三台存储__consumer_offsets partition合部同时重启,均在Loading状态, 这种作法不合适,最多同时重启两台, 留一台可以继续提供coordinattor的功能;
  • 加强对log compact失效的监控, 完美方案是找到失效的根本原因并修复;

Kafka源码分析-汇总

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java帮帮-微信公众号-技术文章全总结

Java并发学习1【面试+工作】

22380
来自专栏玄魂工作室

Hacker基础之Linux篇:进阶Linux命令二

发音类似<砰>,对黑客而言,这就是成功实施黑客攻击的声音,砰的一声,被<黑>的电脑或手机就被你操纵了

15520
来自专栏JavaEE

spring整合quartz框架前言:quartz简介:spring整合quartz:总结:

在一些项目中,往往需要定时的去执行一些任务,比如商城项目,每天0点去统计前一天的销量。那么如何实现呢,总不可能我们每天0点手动的去执行统计销量的方法吧,这时就q...

7410
来自专栏黑泽君的专栏

day69_淘淘商城项目_02

  由于淘淘商城是基于soa的架构,表现层和服务层是不同的工程。所以要实现商品列表查询需要两个系统之间进行通信。   如何实现远程通信?

35820
来自专栏微服务生态

论代码级性能优化变迁之路(二)

在上一篇我们主要介绍了所遇到问题的五点,那么今天接下来讨论剩下的问题,我们先再回顾一下之前讨论的问题:

8520
来自专栏Java后端技术栈

分布式锁简单入门以及三种实现方式介绍

很多小伙伴在学习Java的时候,总是感觉Java多线程在实际的业务中很少使用,以至于不会花太多的时间去学习,技术债不断累积!等到了一定程度的时候对于与Java多...

11910
来自专栏Java职业技术分享

如果你想搞懂“分布式锁”,必须要看这篇文章 ,看了很意外!

对于锁大家肯定不会陌生,在 Java 中 synchronized 关键字和 ReentrantLock 可重入锁在我们的代码中是经常见的,一般我们用其在多线程...

5.5K30
来自专栏Java架构师进阶

2018年一线互联网公司Java高级面试题总结

3、hashmap hastable 底层实现什么区别?hashtable和concurrenthashtable呢?

13510
来自专栏JAVA高级架构

2018年一线互联网公司Java高级面试题总结

1、hashcode相等两个类一定相等吗?equals呢?相反呢? 2、介绍一下集合框架? 3、hashmap hastable 底层实现什么区别?hashta...

60180
来自专栏Android 研究

Android启动流程——1序言、bootloader引导与Linux启动

前面讲解的很多内容都很抽象,所以本次系列决定"接点地气",准备开始讲解大家熟悉的Activity了,为了让我以及大家更好的理解Activity,我决定本系列...

31510

扫码关注云+社区

领取腾讯云代金券