一个U盘引发的“血案”
4月26日，一个“风平浪静”的日子
奔波忙碌的4月，难得有一天“得闲”
施工和同事相约公司楼下顺旺基
17:25 ，一通电话，打乱所有节奏
来自驻场同事的“救命call”
“某卫生机构客户数据库服务器挂了！！！”
DBA的天性，神经立马紧绷起来
施工放下筷子，飞奔上楼
此时，心急如焚的客户也飚来了电话
“@@#￥！@#！#业务都停了！@！#！@#*￥￥#%#@”
17:30 施工成功上线，远程核查数据库
发现HIS生产系统rac两个节点“罢工”！
尝试启动，数据库一直报错！
核心数据库怎么会无缘无故“宕机”？
”尝试多种方法，依旧找不到根源
此时，距离故障时间，已有近30分钟
HIS等业务系统，是卫生机构运转的“命脉”
业务系统长时间“瘫痪”，数据无法读取，无疑是致命的！
当务之急，先恢复业务系统的正常运行！
咋整？？
有容灾系统吗？有！
有数据备份吗？有！
美创灾备系统，是时候展现真正的技术了！
施工当机立断，在征得客户的首肯后
联系灾备工程师“帅哥林”
立刻远程协助客户切换容灾
17:45 开始容灾切换
17:48 切换完毕
17:50 容灾库正式接管
由于交换机缓存没有及时释放，原生产ip飘到容灾主机后没能及时识别，容灾接管耽误了些许时间。尽管有小插曲，但美创容灾在10分钟内迅速接管业务系统，保证了HIS业务系统的正常运行，最大程度上减少客户因业务停滞时间导致无可挽回的损失。（美小创忍不住，竖起了骄傲的大拇指）。
事情并没有结束！好端端，业务系统怎么就崩了？
要知道，容灾系统接管，不是长久之计，关键还是要恢复生产系统。
rac生产系统的两个节点怎么会突然无法工作，总不可能是两台机器都坏了吧！施工登陆数据库后台日志发现，在16:02左右，数据库文件已经出现坏块。
到了16:48，数据库已经彻底不能用了!
这时候查看asm信息，发现DATA数据盘已经不正常!
多年的运维经验给予他一个判断，很有可能是存储出问题了！施工赶紧查看服务器操作系统日志，问题的根源确实在这里！
施工发现，操作系统里面有个移除多路径dm设备报错，这些dm设备是rac生产系统的共享盘。其中的dm-7正是rac数据盘DATA对应的设备，也就是存放生产数据库数据的地方。正是这个移除多路径设备的动作导致生产系统最终损坏。
在这个日志里面，还有一个明显的“信号”！
USB存储设备插入拔出日志提醒！
怎么会有USB存储设备插入到生产服务器？？？
重新缕下思路：
这是数据盘DATA对应的路径/dev/asm-disk8
下面找到绑定asm-disk8多路径设备的uuid
根据uuid去找相应的多路径设备名
再去看操作系统日志
可以有个较为清晰的判断了：客户将移动硬盘格式化并将其路径添加到了mpathj设备，也就是数据盘所在的位置，这样u盘一拔出也就相当于mpathj设备被移出，而且不止插拔了一次，最终导致数据库不能正常运行。
事后求证，原来客户想用移动硬盘拷贝数据库服务器文件，但是普通移动硬盘插在linux服务器上无法正常识别，于是客户将其进行格式化处理。悲剧发生了，很不巧，格式化后的硬盘与oracle数据库盘相关联，当拔出移动硬盘时，连带数据库盘一起被移除，便出现了数据库报错、失联的状态。
真相终于大白！
剥丝抽茧，一步步探究，尽显美创工程师的钻研精神和责任心。
由于mpatchj设备已经被更改过，再次确认环境的时候数据盘已经彻底掉了，且主机也无法识别被移除多路径设备，施工通宵达旦联系存储工程师重新划盘让生产系统认到多路径设备mpatchj，并修复生产系统数据库。
“帅哥林”再利用美创灾备系统及时将数据库切换回原生产环境中。直到第二日（4月27日）下午，700G生产数据成功恢复到生产系统中，保证了生产系统的安全稳定。
一个U盘引发的“血案”，就问你，还敢在生产库上随便插U盘吗？中肯建议，为了业务连续性，不要在生产库服务器上面插拔并格式化任何存储设备！！
故障处理完了，反观整个事件，试想一下，如果没有灾备系统，业务不能第一时间接管会怎样？如果没有备份数据，数据一经丢失，要付出多大代价？
美创科技容灾备份系统，围绕着数据安全连续性保护，从根本上保证数据一致性，降低灾难发生时的业务停滞时间，同时实现对文件、视频、图片、数据库等定时备份、定期转存，避免因信息系统业务中断导致经济损失、名誉受损，更甚者，重要数据丢失。
阅读推荐
围观
热文
热文