# 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、重启 **第一步：停服务** ```bash # 以kill的方式，停Kafka服务。 # 强调：不能以kill -9的方式停服！！！ ``` **第二步：修改配置** ```bash # 对本次重启需要进行修改的配置进行修改； # 强烈要求将本次修改的配置的具体操作步骤罗列出来； ``` **第三步：Broker限流** ```bash # 如果在停服务和启动服务之间的时间间隔非常的久，导致启动后需要同步非常多的数据，则在启动服务之前，我们需要做好副本同步之间的限流，否则可能会拉打满带宽，挂其他Broker等。 # 这里的需要同步的数据量怎么样算多，这个没有一个非常准确的值，只要说可能将leader带宽打满，拉挂其他Broker都算是数据量大。 ``` **第四步：起服务** ```bash # 启动Kafk服务，然后观察服务是否正常 ``` --- #### 2.2.2、观察 **第一步：观察启动日志** ```bash # 查看server.log文件，看到该日志后表示Kafka服务端已启动完成 [2021-11-17 14:07:22,459][INFO][main]: [KafkaServer id=2] started # 查看server.log文件，检查是否存在ERROR及FATAL日志，如果出现这些日志，需要暂停升级并分析出现这些日志的影响。 ``` **第二步：观察服务监控** 如果可以做到下列指标的监控的话，建议都在监控系统中，配置上这些监控。 这一步正常来说只要配置上了，如果出现异常监控系统会主动通知，不需要我们细致的去看，所以虽然列的比较多，但是操作的时候不太需要主动去看所有的指标。 ```bash # 服务存活监控； # 错误日志监控； # GC监控； # 脏选举监控； # ISR收缩速度监控； # leader=-1监控； # 网络处理线程负载监控； # 请求处理线程负载监控； # 副本未同步监控； # 系统负载监控(CPU、磁盘IO、磁盘容量、网络带宽、网络丢包、TCP连接数、TCP连接增速、文件句柄数)； ``` **第三步：检查变更是否生效** 这一步骤没有什么好说的，就是检查是否生效。 **第四步：观察流量是否正常** ``` 观察一：存在Broker组的概念，则可以观察重启所在的Broker组的整个流量和重启之前是否基本一致。 观察二：重点选取几个Broker上的Topic，观察流量是否出现异常，比如突然没有流入或流出流量了。 ``` **第五步：等待副本同步完成** ```bash # 查看整个集群的副本同步状态，确保整个集群都是处于已同步的状态。该信息可以通过LogiKM查看。 # 实际上是不需要整个集群所有的Broker处于已同步的状态，只需要是落在所重启的Broker上的所有的分区都处于同步状态即可，但是这个不太好判断，因此简单粗暴的就是看整个集群都处于同步状态。 ``` ### 2.3、其他重要说明 - 如果重启中需要同步非常大的数据量，Broker本身负载也较高，则建议重启操作要避开leader rebalance的时间； - 重启的过程中，会进行leader的切换，最后一台操作完成之后，需要进行leader rebalance； --- ## 3、信息记录 操作中，很难避免就不出现任何问题，出现问题时就需要我们做好相关的记录，比如记录： - 1、重要的业务及其Topic； - 2、敏感的业务及其Topic； - 3、特殊客户端的业务及其Topic； - 4、不合理使用的业务及其Topic； 后续我们可以将这些Topic进行重点保障，以及再次进行操作的时候，我们能够更准确的触达到用户。