记一次Kafka集群的故障恢复

女主宣言

本文是作者根据实际经验总结出的关于Kafka集群的故障恢复相关的总结,希望对大家有所帮助。

PS:丰富的一线技术、多元化的表现形式,尽在“HULK一线技术杂谈”,点关注哦!

Kafka 集群部署环境

1、kafka 集群所用版本 0.9.0.1

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


Part

1

1

集群故障发生

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

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


2

故障解决

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


640?wx_fmt=png


● 这个问题就很明了了, 在之前的文章里有过介绍: 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的工作~~~~~~


3

集群恢复

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

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

● 业务反馈Topic可以重新写入;



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


Part

2

1

集群故障再次发生

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

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

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


2

故障解决

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

640?wx_fmt=png

  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的加载情况, 发现对应的

    640?wx_fmt=png

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

    640?wx_fmt=png

    也没有发生任何的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;


3

故障恢复

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


总结

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

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

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


HULK一线技术杂谈

由360云平台团队打造的技术分享公众号,内容涉及云计算数据库大数据监控泛前端自动化测试等众多技术领域,通过夯实的技术积累和丰富的一线实战经验,为你带来最有料的技术分享

640?wx_fmt=gif
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
kafka集群中的某台服务器宕机时,我们可以采取以下步骤来恢复kafka partition数据: 1. 首先,我们需要检查宕机服务器的硬件状况并确保服务器可以正常启动。如果是硬件故障导致宕机,我们需要修复或更换故障的硬件设备。 2. 然后,我们需要找出宕机服务器上的kafka数据目录。在该目录中,我们可以找到kafka partition的日志和索引文件,以及其他相关的元数据。 3. 接下来,我们需要将宕机服务器上的数据目录复制到一台正常运行的kafka服务器上。确保复制过程中保持数据的一致性。 4. 一旦数据目录复制完成,我们需要更新kafka的配置文件以指向新的数据目录。在配置文件中,我们需要修改`log.dirs`参数来指定新的数据目录路径。 5. 在更新配置文件后,我们可以启动kafka服务器,并使用命令`bin/kafka-server-start.sh <path_to_config_file>`来启动kafka。 6. 一旦kafka服务器成功启动,它将读取复制的数据目录,并恢复partition的数据。在此过程中,kafka会检查和修复任何可能的数据损坏。 7. 最后,我们可以使用kafka的工具来验证数据恢复情况。通过连接到kafka服务器并使用命令行工具来消费和生产消息,我们可以确保partition的数据已成功恢复。 总结而言,当kafka集群中的某台服务器宕机时,我们可以通过将宕机服务器上的数据复制到正常服务器上,并更新配置文件来恢复kafka partition的数据。这样,在新的服务器上启动kafka后,数据将会被读取和恢复,从而保证数据的一致性和可用性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值