问题现象
问题出现的步骤/操作：
● 配置自动选举，数据库备库手动发起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)]
自动选举配置 组 1
● 因为参数设置错误，数据库一直有选举的相关错误，主备状态异常。
● 在执行shutdown immediate之后，因自动选举数据库被重新拉起，可查看下面截图。
● 在kill -9杀死进程的时候，触发异常产生coredump。
一直都有选举失败情况：
自动选举配置 2
shutdown，重新拉起并开始接收归档：
自动选举配置 组3
解决方法及规避方式
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需要做严谨分析相应的逻辑，完善相应的校验。
