记一次 Kafka 集群的故障恢复

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:

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