YashanDB |掉电后数据库启动报错 core dump?原来是 VMware 默认配置的“锅”!

在使用 VMware 虚拟机部署 YashanDB 的过程中，有用户反馈：一次突发掉电后数据库再也启动不了，手动尝试拉起时直接 core dump。本文将结合实际案例，解析原因并给出防范建议。

一、问题现场回顾

用户环境信息：

虚拟平台：VMware(默认安装方式)

操作系统：CentOS Linux 7(3.10内核)

YashanDB 版本：个人版 23.1.1.100 x86_64

手动拉起数据库命令：

nohup /home/yashan/yasdb_home/yashandb/23.1.1.100/bin/yasdb open -D /home/yashan/yasdb_data/db-1-1 &

日志输出：

Starting instance nomount
Instance started
Starting instance open
Segmentation fault (core dumped)

数据库未能启动成功，并生成 core 文件。

二、风险与影响

三、核心问题解析：虚拟磁盘未实时落盘

原因一：VMware 默认磁盘写策略非“实时写入”

VMware 出于性能优化，默认使用写缓存机制;

数据写入时先写入缓存，并不会立刻落入物理磁盘;

一旦掉电，缓存数据尚未落盘，数据库文件结构容易错乱。

原因二：LSN 不一致触发数据库 panic

数据库启动依赖 LSN(日志序列号)一致性校验：

控制文件记录系统全局 LSN;

Undo 文件记录每个数据块的 LSN;

掉电后 undo 中的 LSN 比 control 文件的还“新”;

数据库认为结构异常，触发 panic 报错。

四、分析过程与验证方式

验证 double write 功能开启(默认已开启，客户未修改);

查看 core 文件堆栈，定位报错为：

setGroupBlocksLsn → COD_PANIC

排查虚拟磁盘文件变化：

虚拟机中创建新文件后，宿主机磁盘文件修改时间无变化;

说明文件尚未落入实际物理存储。

VMware 写缓存策略验证：

默认为“独立-非永久”；

需手动设置为“独立-永久”才能实现实时落盘。

五、解决方案与建议

临时处理方式：

若无重要数据，建议重新安装 YashanDB;

使用最新版本并开启 double write 可增强容错。

永久规避建议：

六、经验总结