国庆节生产数据库存储bug，导致数据全丢失，心态炸裂

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

　　看到数据库进程都没有了，顿时睡意全无，打开电脑看看，什么情况。在这里先看看发生故障的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盘，在这里真的想开骂了，还有比这更扯淡的吗。