记一次Dell存储使用4W小时bug，导致数据库数据丢失故障

故障复盘

本以为今年这个国庆节可以好好放松一下，结果在2号的时候，就被狠狠的打脸了，睡的正香的时候，收到一堆告警，赶紧拿起手机看看，告警的关键信息这里就去掉了。

[Zabbix告警] 在服务器:  IP: 
故障发生时间: 2020.10.02 - 04:21:52
告警级别: Average
告警信息: DB2 alive check
监控项数值: DB2 进程数量异常 : 0
事件ID: 908968693

数据库架构

看到数据库进程都没有了，顿时睡意全无，打开电脑看看，什么情况。在这里先看看发生故障的db2数据库高可用架构。

故障排查

登录到发生故障的数据库服务器，先用ps -ef|grep -i db2sys命令，检查数据库进程，进程没有，于是用df -h看看文件系统，结果显示，从共享存储挂载的文件系统目录全部消失。

于是猜想是不是切换到备库了，于是登录到备数据库服务器，同样使用ps -ef|grep -i db2sys命令，检查数据库进程，结果无进程。df -h的结果也是一样，看来RHCS并没有将数据库切换到备用服务器。这个时候基本可以断定，肯定是存储出现问题了。

这个时候赶紧联系系统组同事，看看存储是否正常。系统组同事不久之后反馈，存储上有4块SSD丢失，导致服务器识别不了共享存储，并且说短时间内无法修复此问题。

业务恢复

怎么办，赶紧想办法恢复业务。想用存储上的数据来启动数据库是不可能了，还好在上个季度，搭建了一套灾备库，与应用开发沟通之后，将业务切换到灾备库，其架构如下所示

要是没有这个灾备库，这个雷就真的炸了，不仅这个十一假期泡汤，后续的事情，我就不多说了，你们懂的。

故障原因

后来找DEll厂商排查，给出的答复是，dell powervault存储上有4块SSD盘的微码版本过低，触发了存储开机使用4W小时，存储就无法识别SSD盘，在这里真的想开骂了，还有比这更扯淡的吗。

建议

在这里给一些在使用oracle，db2数据库，采用双机+存储的高可用架构的公司，一定要做一个离线灾备库，保证数据有2份，不然一旦存储出现问题，那将是毁灭性的灾难，严重的话，估计公司都没啦。