记一次生产 Kafka 挂掉的那几分钟

开发 架构 Kafka
Hello,大家好,我是阿粉,作为一个后端工程师不经历几次生产事故怎么能成长!阿粉工作几年来,大大小小,重要不重要的事故也经历了不少,有损失几十万的,有对业务毫无影响但是不应该发生的,每一次事故都是一次成长,而且从每次的事故中阿粉都能学到很多东西,不单单是解决问题,更重要的是对线上有了更深的敬意!

[[350058]]

本文转载自微信公众号「Java极客技术」,作者鸭血粉丝。转载本文请联系Java极客技术公众号。  

 Hello,大家好,我是阿粉,作为一个后端工程师不经历几次生产事故怎么能成长!阿粉工作几年来,大大小小,重要不重要的事故也经历了不少,有损失几十万的,有对业务毫无影响但是不应该发生的,每一次事故都是一次成长,而且从每次的事故中阿粉都能学到很多东西,不单单是解决问题,更重要的是对线上有了更深的敬意!

背景

上周下午两点多的时候,阿粉正在悠闲的敲着代码,零星的看到几条报警机器人发的 Kafka 集群负载高的报警信息,看到是负载高而已就没怎么在意,更何况这个点还不是高峰期,想着过会应该就好了。谁知道过了一会不见好,而且还越来越多,赶紧拿着电脑跑到运维处去看看是什么情况。不看不知道,一看吓一跳,集群中某个 topic 的数据写不进去了!但是生产者端没有任何报错,看上去还在正常写入,集群却在报错,而且消费端也没有消费到数据。

报错内容如下:

  1. [2020-10-28 15:12:32,923] ERROR [KafkaApi-2] Error when handling request {replica_id=-1,max_wait_time=500,min_bytes=1,topics=[{topic=xxxx,partitions=[{partition=0,fetch_offset=409292609,max_bytes=1048576}]}]} (kafka.server.KafkaApis) 
  2. java.lang.IllegalArgumentException: Magic v1 does not support record headers 

看到这程序肯定是没有问题的,因为最近没有升级,尝试重启集群和服务但是问题依旧存在, 这个时候为了保证业务的稳定,考虑到这个 topic 可能有问题,决定删掉这个 topic 然后自动重新创建,虽然会丢失部分数据,但是并不会产生大的影响,但是如果服务长时间写不进去数据将会更严重。

处理

好在我们的服务是基于 Nacos 做的服务配置与发现,修改 Nacos 里面的 Kafka 集群配置临时切换到另一套集群里面,然后重启服务,因为我们没有开启 Nacos 配置自动生效。切换过后数据正常写入到新的集群,然后手动将旧集群中的有错误的 topic 删掉,删掉出错的 topic 过后集群变得一切正常,没有出现上面的错误。既然没有错误了,通过修改 Nacos 将集群配置切换回来,一切也正常。

整个事故从发现到解决差不多经历了二十几分钟,但是因为刚开始忽略了报警信息,导致差不多影响了一个小时的数据,好在这个数据对线上业务本身不会出现大的影响,而且通过切换到临时集群以及日志数据,还可以找回来一部分。

事后复盘了一下,主要总结了以下几点,分享给大家,共勉:

  1. 敬畏线上!线上环境报警信息第一时间查看确保没问题!
  2. 保证线上数据安全,及时备份和切换临时环境(这块一定要做好动态配置,别慢慢的还要走发布流程,推荐使用 Nacos);
  3. 事后复盘,回顾整个处理过程,哪些地方可以优化,哪些地方做的不对浪费了时间,下次再遇到这种情况是否可以快速解决。生产上时间就是金钱,事故多一分钟就多一分钟风险,有点时候一分钟可以改变很多东西。

上面的错误网上大部分说的都是版本冲突,但是阿粉这边并没有升级过,所以这个问题就比较玄学了。

总结

遇到问题不可怕,没有人能保证服务不出问题,我们要做的就是在遇到问题的时候沉着泠静,想到应对策略,在最短的时间的想到最好的解决方案,减少风险和损失才是最重要的。另外我们一定懂得敬畏线上,特别的那些非常重要的业务,不然一旦出现问题后果都是很严重的。

最后邀请你加入我们的知识星球,这里有 1800+ 优秀的人与你一起进步,如果你是小白那你是稳赚了,很多业内经验和干货分享给你;如果你是大佬,那可以进来我们一起交流分享你的经验,说不定日后我们还可以有合作,给你的人生多一个可能。

 

责任编辑:武晓燕 来源: Java极客技术
相关推荐

2022-06-01 06:17:42

微服务Kafka

2018-12-06 16:25:39

数据库服务器线程池

2021-03-01 06:14:50

环境高并发延迟

2020-09-25 07:57:42

生产事故系统

2019-11-18 13:42:55

MySQL数据库迁移

2019-08-19 01:34:38

数据库SQL数据库优化

2019-11-22 08:05:01

数据库mysql分区

2019-12-12 10:38:10

mysql数据库nnodb

2019-01-21 11:17:13

CPU优化定位

2021-01-12 07:57:36

MySQLBinlog故障处理

2019-08-15 11:30:06

SQL数据库ASH

2013-07-02 09:58:38

ClojureClojure教程

2016-09-30 15:13:01

Python代码

2020-12-15 11:18:43

系统磁盘lvm数据库

2019-12-16 07:18:42

数据库SQL代码

2019-09-27 17:24:26

数据库优化sql

2019-07-25 08:30:58

数据库服务器故障

2009-12-29 09:01:46

ADSL断线

2019-09-08 17:52:10

数据库log file sy等待事件

2019-12-02 08:09:57

境数据库连接超时自动回收
点赞
收藏

51CTO技术栈公众号