问题现象
问题出现的步骤/操作:
-
配置自动选举,数据库备库手动发起switch over,命令会报错
-
主、备库变为只读状态,数据库无法进行读写操作
-
shutdown immediate 停止数据库,此时发现数据库一直没有退出,业务人员反馈需要尽快恢复数据库的读写状态
-
kill -9杀死yasdb进程,数据库发生coredump 。重启数据库并使用failover将降备的数据库提升为主库
-
数据库恢复正常读写状态
相关问题单:数据库使用shutdown immediate无响应,操作系统层面强制停止数据库进程时coredump
问题的风险及影响
客户环境为测试环境,主备库均为只读状态,影响测试业务的开展。
问题影响的版本
YashanDB版本:22.2.10.100
问题发生原因
和现场确认,配置开启了自选举参数HA_ELECTION_ENABLED为TRUE,问题看起来各种诡异,根因都是这个参数配置错误。
该参数是分布式、或者一主多备(3个节点以上)才能配置,2个节点需要使用仲裁选举。可参考文档说明:[自动选举配置 | YashanDB Doc (yasdb.com)]
-
因为参数设置错误,数据库一直有选举的相关错误,主备状态异常。
-
在执行shutdown immediate之后,因自动选举数据库被重新拉起,可查看下面截图。
-
在kill -9杀死进程的时候,触发异常产生coredump。
一直都有选举失败情况:
shutdown,重新拉起并开始接收归档:
解决方法及规避方式
1、一主一备自动选举需要升级到22.2.12.100及以上或23.1版本,可以使用yasboot仲裁选举。
2、22.2.10及以下版本要使用自动选举需要部署一主多备(3个节点或以上)。节点少于3个,不能配置自动选举参数,主备切换使用switchover手动切换。
问题分析和处理过程
1、检查数据库日志,从run.log,可以看到数据库一直在做选举,且选举失败,主备状态一直异常。怀疑是选举参数配置有问题。
2、检查配置参数。发现开启了自选举参数HA_ELECTION_ENABLED为TRUE,该参数在22.2.10.100版本一主一备的情况下不适用。
3、确认core的原因。现场怀疑是kill进程导致undo没回滚完导致core,实际使用killYashanDB 会捕捉相应的信号量做相应的处理,保障可以优雅退出。但是kill -9命令发送的是SIGKILL信号,是一种不可被捕获信号,它强制目标进程立即停止运行,无法让程序优雅地退出。由于数据库有大量的内存、线程、文件句柄,kill -9无法保证资源退出先后顺序,内部资源被破坏,同时系统如果还有其他操作,出core是正常的。
4、core堆栈是在审计的步骤,研发分析发现审计逻辑不严谨,缺少校验(备机不需要审计),优化相应的校验逻辑。
经验总结
1、kill -9无法使YashanDB优雅退出。正常使用shutdown immediate 停止数据库,无法退出可以使用kill(不带-9)
2、22.2.10及以下版本要使用自动选举需要部署一主多备(3个节点或以上)。节点少于3个,不能配置自动选举参数。
3、出现core需要做严谨分析相应的逻辑,完善相应的校验。
标签:配置,YashanDB,选举,数据库,知识库,kill,自动,参数 From: https://www.cnblogs.com/YashanDB/p/18334005