KnowStreaming/docs/zh/Kafka分享/Kafka常见问题解答/Kafka集群滚动重启实践/Kafka集群滚动重启实践.md

Kafka集群平稳滚动重启实践

[TOC]

0、前言

Kafka集群的滚动重启，是一件非常危险的事情，操作不当的情况下可能会导致Kafka集群不可服务。即便操作上准确无误，也可能因为业务方服务非常敏感、服务健壮性不足、使用的客户端存在BUG等原因，导致业务方业务受损。

基于以上的原因以及我们以往的经验，我们梳理了一下在对Kafka集群滚动重启中，需要做的事情以及注意的点。

1、用户告知

1.1、告知内容

提前告知用户:

• 我们要做什么；
• 为什么要做；
• 可能的影响，及简单处理方式，比如因为leader会切换，node客户端可能会消费中断，需要重启等；
• 联系人；
• 操作时间；在操作时间选择上，建议选择业务方在的工作时间，方便出问题后能及时协同处理

告知内容例子：

标题：
[2021-11-11] XXX-Kafka 集群升级至 kafka_2.12-xxxx

变更原因：
1、性能优化 

变更内容：
1、集群单机连接数限制调整到 1200 

变更影响：
升级过程中会有leader切换，理论上无影响，有问题及时联系kafka服务号 

联系人：
xxxxx@xxxx.com

计划时间：
2021-11-11T10:00:00+08:00 至 2021-11-11T16:30:00+08:00 

1.2、相关建议

• 增加对自身服务监控，比如监控服务对应的Topic的流量，监控消费的Lag等指标，以便出现问题时能被及时发现；

---

2、滚动重启

真正操作前，建议演练一下。

---

2.1、整体操作流程

• 1、再次通知用户，我们现在要开始进行重启操作，有问题随时联系；
• 2、重启非Controller的一台Broker；
• 3、观察重启后指标等是否都正常，如果出现异常则进行相应的处理；
• 4、告知用户我们已重启一台，xxx分钟后，要操作剩余所有的机器，让用户注意自身服务是否正常，有问题随时反馈；
• 5、xxx分钟后，剩余机器逐台重启，Kafka-Controller放在最后重启；
• 6、操作完成后，告知用户已操作完成，让用户关注自身服务是否正常，有问题随时反馈；

---

2.2、单台操作流程

单台操作时，主要分两部分，第一部分时操作进行重启，第二部分是重启完成之后观察服务是否正常。

2.2.1、重启

第一步：停服务

# 以kill的方式，停Kafka服务。

# 强调：不能以kill -9的方式停服！！！

第二步：修改配置

# 对本次重启需要进行修改的配置进行修改；

# 强烈要求将本次修改的配置的具体操作步骤罗列出来；

第三步：Broker限流

# 如果在停服务和启动服务之间的时间间隔非常的久，导致启动后需要同步非常多的数据，则在启动服务之前，我们需要做好副本同步之间的限流，否则可能会拉打满带宽，挂其他Broker等。

# 这里的需要同步的数据量怎么样算多，这个没有一个非常准确的值，只要说可能将leader带宽打满，拉挂其他Broker都算是数据量大。

第四步：起服务

# 启动Kafk服务，然后观察服务是否正常

---

2.2.2、观察

第一步：观察启动日志

# 查看server.log文件，看到该日志后表示Kafka服务端已启动完成
[2021-11-17 14:07:22,459][INFO][main]: [KafkaServer id=2] started

# 查看server.log文件，检查是否存在ERROR及FATAL日志，如果出现这些日志，需要暂停升级并分析出现这些日志的影响。

第二步：观察服务监控

如果可以做到下列指标的监控的话，建议都在监控系统中，配置上这些监控。

这一步正常来说只要配置上了，如果出现异常监控系统会主动通知，不需要我们细致的去看，所以虽然列的比较多，但是操作的时候不太需要主动去看所有的指标。

# 服务存活监控；
# 错误日志监控；
# GC监控；
# 脏选举监控；
# ISR收缩速度监控；
# leader=-1监控；
# 网络处理线程负载监控；
# 请求处理线程负载监控；
# 副本未同步监控；
# 系统负载监控(CPU、磁盘IO、磁盘容量、网络带宽、网络丢包、TCP连接数、TCP连接增速、文件句柄数)；

第三步：检查变更是否生效

这一步骤没有什么好说的，就是检查是否生效。

第四步：观察流量是否正常

观察一：存在Broker组的概念，则可以观察重启所在的Broker组的整个流量和重启之前是否基本一致。

观察二：重点选取几个Broker上的Topic，观察流量是否出现异常，比如突然没有流入或流出流量了。

第五步：等待副本同步完成

# 查看整个集群的副本同步状态，确保整个集群都是处于已同步的状态。该信息可以通过LogiKM查看。

# 实际上是不需要整个集群所有的Broker处于已同步的状态，只需要是落在所重启的Broker上的所有的分区都处于同步状态即可，但是这个不太好判断，因此简单粗暴的就是看整个集群都处于同步状态。

2.3、其他重要说明

• 如果重启中需要同步非常大的数据量，Broker本身负载也较高，则建议重启操作要避开leader rebalance的时间；
• 重启的过程中，会进行leader的切换，最后一台操作完成之后，需要进行leader rebalance；

---

3、信息记录

操作中，很难避免就不出现任何问题，出现问题时就需要我们做好相关的记录，比如记录：

• 1、重要的业务及其Topic；
• 2、敏感的业务及其Topic；
• 3、特殊客户端的业务及其Topic；
• 4、不合理使用的业务及其Topic；

后续我们可以将这些Topic进行重点保障，以及再次进行操作的时候，我们能够更准确的触达到用户。