磐维数据库（PanWeiDB）是由中国移动基于中国本土开源数据库openGauss打造的自研数据库产品，主要面向ICT基础设施。它具有高性能、高可靠性、高安全性和高兼容性的特点，能够支持集中式、分布式、云原生、一体机等多种应用场景。目前，磐维数据库已在中国移动的多个省（区、市）公司及专业公司部署应用。
案例背景
本文将分享江西移动公司在现场做高可用演练时遇到的主库切换超时问题：智慧网格系统-业务库（下面统称网格通）在做高可用应急演练时，手动执行switchover切换主备，在历时2分钟后，切换的命令显示：“switchover command timeout”，主备切换失败，暂停高可用演练。
环境描述
- OS版本：BCLinux for Euler 21.10 (LTS-SP2)
- DB版本：panweidb 1.0.0
- 兼容模式：B 模式
- 磐维数据库架构：一主两备高可用
问题描述
登录数据库用户执行切换主节点命令，集群主备手动切换失败，备库未升主，表现为：
1、切换命令超时
2、集群处于无主状态
3、过段时间后，恢复为原先状况，主备切换未成功
问题分析
针对切换失败问题，本次分析将以时间为线索，逐渐分析出在切换过程中主库（6001）和备库（6002）发生的事件。
注：以下出现的cms为cm_server的缩写，cma为cm_agent的缩写
1、22:18:25：查看主库的cms日志可以发现cma在向备库发送switchover指令。
2、22:18:27：在备库的cma日志中可以看到在收到了cms的switchover指令，并处于等待升级状态。
3、22:19:15： 在备库“等待升级成主节点”的过程中。通过主库的cma日志中发现：在第五次检测为假死状态后，主库被判定为假死并重启。
4、22:19:26： 在备库的system_call日志查看到switchover timeout after 60 seconds. please manually check the cluster status.，在这期间6001是处于重启状态（上一张图有说明），导致switchover无法成功
5、22:20:27： 在备库的cma日志中可以看到，此时备库收到cms的failover（故障转移）指令降为备库，即node type is 2。
分析结论
在切换过程中主库被cma检测到假死，会被杀掉重启，从而其失去主角色。而备库在switchover升主的过程中，发现6001角色不是primary了，就会促使其认为发生异常，switchover无法成功，因而switchover失败。 此时cms将集群恢复为原先状态，即6001为主节点，6002为同步节点，6003为异步节点。
解决方法
通过上面的问题分析和结论可知，cm_server存在"僵死检测机制"。故，为避免在switchover时同类故障复发，需要做出如下修改：
1、对cms的僵死检测参数phony_dead_effective_time**经行调整。
1）参数说明： 用于数据库节点僵死检测，当检测到的僵死次数大于该参数值，认为进程僵死，将进程重启
2）修改参数：gs_guc reload -Z cmserver -N all -I all -c "phony_dead_effective_time=300"
3）检查参数：cm_ctl list --param --server | grep phony_dead_effective_time
2、在switchover命令中添加超时延迟参数设置该切换命令超时的时间为3000秒。
cm_ctl switchover -n 2 -D /database/panweidb/data -t 3000
总结
本次案例算是意料之外的情况，因为在业务上线前已经做过高可用演练，且在写方案时每一步操作都是在测试环境实操过。但在生产上还是发生了未曾预料的事——切换超时。所以，文章的最后，和读者分享一些心得：在核心库或者业务量大的库在割接上线到磐维数据库之前，最好结合源端的情况模拟出相对应业务量去做高可用演练，也可以在模拟割接时测试一下高可用的情况。
