在使用 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 可增强容错。
永久规避建议：
六、经验总结
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。