love wife love life —Roger的Oracle/MySQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

都是换盘惹的祸

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL数据恢复博客

本文链接地址: 都是换盘惹的祸

前不久某客户的分布式Oracle 集群环境(我司的zdata分布式架构);某个存储节点因为内存损坏并进行更换后;后续客户方工程师发现另外一个节点有个硬盘报警;因此就更换了该磁盘;悲剧从此开始。。。

此时如果你收工mount磁盘组会报缺少磁盘。

这里缺少的磁盘其实就是之前被更换的磁盘。我们进一步分析数据库日志发现,其实之前有些节点的磁盘被自动offline drop后;其实数据库正在进行rebalance操作;然而这个时候又重启了存储节点(因为换内存);在该节点还没重启完成之前;另外一个节点被换了磁盘导致数据库直接crash了。

可能说起来有点绕口;简单解释一下;数据是normal冗余,即有1个副本;解释一条数据A和其副本A1 分别在2个存储节点上;当一个节点重启后,其磁盘还没被集群所识别到时,另外一个节点恰好换盘,而A1副本可能刚好落在这个盘上。由于数据不完整;那么db肯定立马crash。

当然最后处理比较简单;将该磁盘再插回机器后,重新加入到mount force diskgroup发现可以正常启动;而数据库稍后也开始进行rebalance了。

由于客户的数据库比较大,60TB左右;因此整个处理时间较长;很多协调的工作,再加上客户机房也非常远,往返2小时。

针对这个case;事后我们进行了复盘验证;其实可以使用更快的处理方法解决;当然存在一定风险;因为这涉及到对于asm元数据的处理;主要处理pst即可。

如下是简单测试过程。

当然生产库的操作建议慎重;如需帮助请联系我们。

 

 

Leave a Reply

You must be logged in to post a comment.