KingbaseES V8R3 集群运维案例 --操作系统‘soft lockup’引起的failover切换

案例说明：

在国产中标麒麟系统生产环境中，监控发现KingbaseES V8R3集群发生了failover的主备切换，客户需要给出分析报告，说明此次集群发生failover切换的原因，本次文档通过分析说明了此次切换产生的具体原因。

适用版本：

KingbaseES V8R3

集群架构：

node 12（10.116.*.12）----原主库
node 11（10.116.*.11）----原备库

一、案例分析步骤

1、读取集群日志（cluster.log、failover.log、recovery.log）获取集群failover切换时间点。
2、分析主备库sys_log，查看日志记录，是否因为数据库业务负载导致切换产生。
3、读取主备库系统日志（message）获取切换发生时，系统的状态信息。
4、结合系统日志、集群日志、数据库日志，总结产生切换发生的具体原因。

二、案例分析总结

1、从”Dec  8 00:43:43”，node 12（主库）操作系统开始出现‘soft lockup’，Soft lockup名称解释：所谓，soft lockup就是说，这个bug没有让系统彻底死机，但是若干个进程（或者kernel thread）被锁死在了某个状态（一般在内核区域），很多情况下这个是由于内核锁的使用的问题。

2、从sys_log看，node 12（主库）缺失“2022-12-08 00:45---00:51”的sys_log日志，这和系统message记录‘soft lockup’时的时间对应，出现‘soft lockup’后，导致系统假死，数据库服务无法正常运行。

3、从cluster.log分析，node 12（主库）缺失‘2022-12-08 00:43:23---01:02:12’日志，这和系统message记录‘soft lockup’时的时间对应，出现‘soft lockup’后，导致系统假死，集群管理kingbasecluster服务无法正常运行。

4、从‘2022-12-08 00:43:11’开始，node 11（备库），无法和主机node 12（主库）的kingbasecluster及数据库服务（54321）正常通讯。

5、node 11（原备库）在‘2022-12-08 00:43:32’开始，尝试连接主库数据库服务，超过连接失败阈值次数后（10），发起failover的切换，并在‘2022-12-08 00:45:10’，执行failover切换，和node 11的failover.log记录的日志信息匹配。

6、node 11 failover.log记录在‘2022-12-08 00:45:10’，node 11（原备库），执行failover主备切换。

从以上分析看，此次主备failover切换，是因为主库出现了‘soft lockup’故障导致，主库系统假死，主库集群管理服务（kingbasecluster）和数据库服务（kingbase）均无法正常运行，导致备库发起了failover切换。

三、故障原因

Soft lockup：这个bug没有让系统彻底死机，但是若干个进程（或者kernel thread）被锁死在了某个状态（一般在内核区域），很多情况下这个是由于内核锁的使用的问题。

如下所示：系统message日志信息

内核参数kernel.watchdog_thresh（/proc/sys/kernel/watchdog_thresh）系统默认值为10。如果超过2*10秒会打印信息，注意：调整值时参数不能大于60。

Linux内核对于每一个cpu都有一个监控进程，在技术界这个叫做watchdog（看门狗）。通过ps –ef | grep watchdog能够看见，进程名称大概是watchdog/X（数字：cpu逻辑编号1/2/3/4之类的）。如果进程进入死锁或者进入死循环，长时间看门狗进程得不到调度，系统检测到进程占用cpu的时间超出特定的时间值后，会打印soft lockup告警，告警包含占用时长和进程名以及pid。

从本次的’soft lockup‘故障看，应该和系统网络进程有关（ping）。

参考文档：https://access.redhat.com/solutions/3615651

四、案例总结

此次系统’soft lockup‘的故障，经操作系统管理人员确认，是系统的bug引起。