写点什么

记一次 Kafka 集群的故障恢复

  • 2019-11-20
  • 本文字数:1744 字

    阅读完需:约 6 分钟

记一次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


2019-11-20 13:052484

评论

发布
暂无评论
发现更多内容

NFTScan | 11.27~12.03 NFT 市场热点汇总

NFT Research

NFT NFT\ NFTScan

亚马逊云科技宣布推出四项Zero-ETL集成特性

财见

inBuilder低代码平台新特性推荐-第十三期

inBuilder低代码平台

开源 低代码

金融大模型的微调实战

百度开发者中心

金融 大模型 #人工智能

KubeWharf:解析云原生未来的分布式操作系统

数字扫地僧

KubeWharf

京东商品详情接口在电商行业中的重要性及实时数据获取实现

Noah

DevSecOps研讨会年终专场来啦!邀您共探如何打好DevOps基础,赋能创新

龙智—DevSecOps解决方案

智能LED屏幕未来升级方向

Dylan

个性化 定制化 LED显示屏 全彩LED显示屏 led显示屏厂家

数据“库”的增删改查

小齐写代码

浪潮信息存储助力企业智能化变革

财见

09 | 队列:队列在线程池等有限资源池中的应用

鲁米

10 | 递归:如何用三行代码找到“最终推荐人”.md

鲁米

淘宝商品详情接口在电商运营中的应用实例

Noah

2023年度项目深入探索:AI与大模型在实际应用中的全景

数字扫地僧

盘点那些国际知名的黑客(下篇)

禅道项目管理

互联网 黑客 计算机网络

淘宝API接口申请指南

联讯数据

大模型训练:预训练模型与数据标准化

百度开发者中心

深度学习 #人工智能 LLM

it统一运维平台怎么样?有可以推荐的品牌吗?

行云管家

IT运维 安全运维 统一运维

数据的力量:Web3 游戏运营指南

Footprint Analytics

区块链游戏 游戏运营 Web3 游戏

KubeWharf:基于Kubernetes的分布式操作系统,助力云原生化部署和管理

bug菌

Kubernetes 社区征文

苹果万能视频播放器 Elmedia Video Player Pro中文最新版

胖墩儿不胖y

Mac软件 视频播放器 视频播放

C++空类的那点事儿

树上有只程序猿

C++ 空类

开源大模型与微调策略概览

百度开发者中心

大模型 #人工智能 LLM

一种全新的日志异常检测评估框架:LightAD

华为云开发者联盟

人工智能 机器学习 深度学习 华为云 华为云开发者联盟

记一次Kafka集群的故障恢复_文化 & 方法_扫帚的影子_InfoQ精选文章