通过一次fio破坏库故障看达梦的优缺点---惜分飞

以前恢复过一个case(达梦数据库,主备节点同时被fio破坏fio测试io,导致磁盘文件系统损坏故障恢复),这两天又接到一个类似故障。由于我对达梦数据库本身不太熟悉，有不足之处希望指出，也请勿怪

故障背景描述

1. 客户达梦数据库运行在arm服务器的linux环境

2. 两台机器做了达梦的DataWatch(类似oracle的dataguard)

3. 主库上有多份数据库备份,但是备份和数据库文件放都放在同一块磁盘的同一个分区上

4. 由于数据库运行较慢,应用厂商先在主库上进行了fio性能测试,然后数据库发生自动切换,切换到备库(当时现场没有发现异常),然后还继续在主库上进行了一次fio测试

5. 再在数据库备库(现在已经切换为主库)的机器上又进行了一次fio测试,然后数据库也异常,至此达梦的主备环境全部异常,三次的fio具体操作命令:

   fio --direct=1 --iodepth=32 --rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio --numjobs=4 --group_reporting --time_based --runtime=60 --filename=/dev/vdb --name=4k_iops_test

6. 根据当时测试的fio结果显示主库两次测试一共写入数据大概2G左右,备库写入大概1.2G左右数据

7. 当前数据库的block size设置为32k(也就是说在32k里面随机写中任何4k的数据这个block就破坏)

8. 虽然客户是央企但是由于商务招标等原因导致达梦现在不是他们的数据库中标厂商,而且这个库没有正式授权和任何售后服务,甚至安装实施都非达梦工程师.基于这样的情况,应用厂商通过多种途径联系上达梦公司高层,才给予了一定的技术支持.

恢复过程和思路

1. 对于当前的情况,是选择优先恢复主库还是备库的磁盘考虑：虽然主库破坏写入的多一些,但是由于主库中有多份有效备份,因此考虑先让客户对现场主库环境被破坏的vdb磁盘进行镜像,然后使用专业的软件对文件系统进行分析后,可以直接看到达梦相关的数据文件,而且文件系统元数据较为完整

因为fio随机写,从备份集的元数据状态上看备份文件文件数量正确,而且状态良好

2. 恢复出来达梦相关数据文件和所有有效备份文件,上传到新准备的和以前操作系统,数据库版本一样的机器上,然后进行尝试恢复.

3. 非常不幸所有备份集通过dmrman的check backupset命令检测返回无效备份包,但是达梦官方无法提供进一步信息,这个想通过备份集来恢复的思路基本上走死.

4. 考虑让达梦厂商基于恢复的数据文件强制拉库,但是比较不幸由于fio的随机写入破坏导致拉库过程中报page check error,而且达梦工程师经过多次尝试均无法跳过,推断可能是涉及核心字典对象异常,无法规避,数据库无法打开.

5. 达梦工程师考虑通过dmdul工具进行提取,结果无法成功加载字典信息,反馈给研发说该工具不支持当前数据库版本,短期内无法让工具支持,这个希望也放弃.

6. 基于这种情况,再次对备库的fio破坏的磁盘进行恢复,然后通过备库恢复出来的数据文件和主库的数据文件的启动坏块进行互补,然后由达梦工程师打开数据库.

7. 然后尝试dmexpdp导出数据,由于还有字典异常导致导出失败(虽然可以进一步通过替代的方式修复一些坏块,也许可以绕过但是每次报错一个坏块,然后修复导出效率太低,放弃该方法)

8. 尝试通过dmdbcheck检查全库坏块情况,也非常不幸,这个命令也需要检查很多字典,虽然通过人工修复了一些字典报错数据块,但是还是无法执行,最后放弃

9. 在达梦工程师建议下,他们采用了达梦的数据迁移工具按照表迁移到新库中,对于报错的块进行修复,然后再次尝试迁移,这样不停的尝试完成了大部分的迁移工作

10. 少量表通过block修复之后依旧报坏块,而且达梦工程师那边反馈当前版本无法通过表级别和全局方式跳过坏块,导致这些表如果有一个坏块无法修复,数据就无法正常迁移

11. 对于这种情况,提供给他们类似oracle rowid抢救数据的思路进一步抢救数据(打开的主备库都进行类似操作,然后进行对比获取最大限度的数据恢复)

故障恢复回顾

1. 在客户没有购买最终授权和服务,甚至可能最终整体出局的情况下,达梦厂商给予了非常大的支持,这点值得表扬

2. 达梦数据库对于异常库的诊断分析功能不够完善,主要体现在:

2.1）在数据库非正常关闭的情况下无法检测数据文件坏块情况,对于这个故障,如果有类似oracle的dbv功能,然后配合脚本可以快速的实现坏块填补,会节省大量的反复尝试报错,然后修复,再尝试,再修复的工作

2.2）数据库在open的过程中提示信息不够明确友好,不便于恢复调试,比如类似oracle数据库open过程的明确日志,如果有整个启动过程的类似10046跟踪到具体sql和数据块更好

2.3）达梦的离线提取工具,对版本依赖太强,没有更好的兼容低版本,使得极端情况下,达梦售后工程师缺少兜底工具和底气

2.4）现场达梦工程师反馈当前客户的达梦数据库版本,无法全局和当个表的跳过坏块,严重不合理

2.5）dmdbcheck工具对系统字典依赖太强,如果部分字典不能被正常解析(比如有坏块),直接导致检查终止,不合理

2.6）在我接触另外一些国产库中,研发的响应速度要比达梦的迅速,也许是当前客户协调的资源不够导致,商务问题等(以前有客户其他国产库故障比这个小,客户也比这个小,但是直接协调不错的研发资源快速解决问题)

3. 又一次在主备库上面同时执行了fio,又是把备份和生产数据放在同一个磁盘上,这些非常不合理,希望所有人引以为戒

后续期待

一、对于产品方面

1. 提供离线文件的坏块检测，类似oracle的dbv工具

2. 对外提供一些数据块结构信息，并完善数据块结构的设计，便于第三方对其做一些工具开发，弥补厂商的不足

3. 数据库层面提供跳过表坏块和全局坏块的设置（不确定是否现在新版本已经支持）

4. dmdul工具目前向下兼容性不好，支持功能不全，希望可以达到oracle dul级别的功能支持

5. 对于数据库的日志和跟踪功能进一步完善，类似做到oracle级别的跟踪(10046可以跟踪到启动过程读取的每一个数据块情况，看到每一条具体的sql)和日志体系

二、对于服务方面

1. 随着达梦数据库越来越多的客户使用，将来各种异常恢复的情况肯定也会越来越多，整个团队在这个方面经验不足

2. 特殊情况下，售后和研发团队的对接，以及研发团队的应急相应速度进一步完善