金仓数据库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引起。 更多信息，参见https://help.kingbase.com.cn/v8/index.html