KingbaseES V8R3 集群运维系列之 -- 主备切换信号量(semctl)故障分析案例

KingbaseES V8R3集群运维案例之---主备切换信号量(semctl)故障分析案例

案例说明：
某项目KingbaseES V8R3一主一备流复制集群在主备切换测试中出现故障，导致主备无法正常切换；由于bm要求，数据库相关日志无法从主机中获取，只能在现场进行分析；通过对比主备切换时的时间点，在集群的failover.log、recovery.log及数据库的sys_log日志中，发现故障原因。在切换过程中新主库（原备库）数据库启动时，出现下图所示的故障（semctl），导致数据库无法正常启动，一直处于recovery状态，导致集群主备切换后，原备库无法正常提升为新主库，集群出现“双备”状态，主备切换失败。在调整了信号量相关的参数后，主备切换亦无出现问题，切换故障问题解决。

sys_log日志信息：

semctl（61833283,15，SETVAL,0）failed
invalid argument

由于此项目sm，以下日志为测试环境复现获取：

......
terminating any other active server processes
WARNING,57P02,terminating connection because of crash of another server process,The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.,In a moment you should be able to reconnect to the database and repeat your command.
archiver process (PID 3766) exited with exit code 1
FATAL,57P03,the database system is in recovery mode
all server processes terminated; reinitializing
could not remove shared memory segment /KingbaseES.44345806: No such file or directory
semctl(156532736, 15, SETVAL, 0) failed: Invalid argument
......

系统环境：

操作系统：
kylin Server 10

适用版本：

KingbaseES V8R3

一、集群切换问题分析
集群切换失败有多方面原因，有集群或数据库及操作系统故障，所以在分析时，应该从集群和数据库及操作系统相关日志入手，主要是先找到发生故障的准确时间点，然后在同一时间点查看集群、数据库、操作系统相关的日志信息，综合分析，最终找到故障发生的原因。
1）确定切换时故障的时间点。
2）查看故障时间点，集群的cluster.log和recovery.log的日志信息，查看切换流程，分析故障原因。
3）分析故障时间点，failover.log日志，原备库数据库启动在recovery 模式，不能正常启动数据库，不能被提升为新主库。
4）分析故障时间点，在原备库的sys_log，发现数据库启动时出现semctl故障，导致数据库无法正常启动，数据库处于recovery模式。

sys_log日志错误信息：

semctl（61833283,15，SETVAL,0）failed
invalid argument

5）分析semctl故障 （semctl()函数）

该函数用来直接控制信号量信息，它的原型为：
int semctl(int sem_id, int sem_num, int command, ...);

如果有第四个参数，它通常是一个union semum结构，定义如下：
union semun {
    int val;
    struct semid_ds *buf;
    unsigned short *arry;
};

前两个参数与前面一个函数中的一样，command通常是下面两个值中的其中一个
SETVAL：用来把信号量初始化为一个已知的值。p 这个值通过union semun中的val成员设置，其作用是在信号量第一次使用前对它进行设置。
IPC_RMID：用于删除一个已经无需继续使用的信号量标识符。

=== 从以上信息获知，在sys_log中出现的semctl（setval）故障，应该和数据库主机中信号量的配置kernel.sem参数有关，可以调整信号量的参数大小。===

6）检测操作系统信号量的相关配置

如下所示，系统信号量的相关配置：

  原始参数配置：
    kernel.sem=250 162500 256 650
   # RemoveIPC=yes


 分析kernel.sem参数的配置：
kernel.sem=250     162500   256   650

         SEMMSL, SEMMNS, SEMOPM, SEMMNI

SEMMSL
含义：每个信号量set中信号量最大个数 设置：最小250；对于processes参数设置较大的系统建议设置为processes+10
SEMMNS
含义：linux系统中信号量最大个数 设置：至少32000；SEMMSL * SEMMNI
SEMOPM
含义：semop系统调用允许的信号量最大个数设置：至少100；或者等于SEMMSL
SEMMNI
含义：linux系统信号量set最大个数 设置：最少128

=此集群在刚部署完成，未有业务的情况下，切换正常，但是随着业务上线后，用户访问量增大，大量的并发进程访问共享内存，如果信号量的值设置较小，可能导致进程在访问共享内存时，导致信号量分配失败，所以需要调整kernel.sem参数的值。=

二、故障解决步骤

1）配置系统sysctl.conf文件，重新配置shsem参数，如下所示：

kernel.sem=50100 64128000 50100 1280

2）配置/etc/systemd/logind.conf 文件，RemoveIPC参数，如下所示：

RemoveIPC=no

3）重启服务：

systemctl daemon-reload 
systemctl restart systemd-logind.service   

三、执行主备切换测试

调整以上信号量的相关参数后，多次执行主备切换（1、sys_ctl关闭主库数据库服务；2、重启主库主机）都能正常切换，因此确定此次引起的切换故障和信号量参数配置有关。

四、测试配置RemoveIPC参数故障信息

如果在操作系统显式的将RemoveIPC=yes，主备切换时，sys_log将出现以下的故障：

semctl (5976836,0,IPC_RMID,.....)
failed:invailid argument

RemoveIPC参数在/etc/systemd/logind.conf中控制在用户完全注销时是否删除System V IPC对象。
该参数在 systemd 212(2014-03-25)版本中默认打开，RHEL7从219版本开始。显然，kylin中的该参数是默认关闭的。
当RemoveIPC = yes时，KingbaseES服务器使用的信号量对象在随机时间被删除，导致服务器崩溃。

五、总结
此次，KingbaseES V8R3集群主备切换的故障原因，是在部署时，没有按照部署手册对信号量的参数进行配置，导致切换过程发生故障。因此，前端实施过程中，必须严格按照部署手册进行集群的部署，以免后期在运行过程中，当业务量增加时，导致集群出现运行故障。
在KingbaseES官方文档的高可用最佳实践手册中，对部署高可用集群前的系统环境的准备做了详细的描述，用户在部署KingbaseES读写分离的集群前可以参考相关的文档。
如下图所示：

KingbaseES官方文档链接：https://help.kingbase.com.cn/v8/install-updata/install-linux/install-linux-2.html#id8