视频1 视频21 视频41 视频61 视频文章1 视频文章21 视频文章41 视频文章61 推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37 推荐39 推荐41 推荐43 推荐45 推荐47 推荐49 关键词1 关键词101 关键词201 关键词301 关键词401 关键词501 关键词601 关键词701 关键词801 关键词901 关键词1001 关键词1101 关键词1201 关键词1301 关键词1401 关键词1501 关键词1601 关键词1701 关键词1801 关键词1901 视频扩展1 视频扩展6 视频扩展11 视频扩展16 文章1 文章201 文章401 文章601 文章801 文章1001 资讯1 资讯501 资讯1001 资讯1501 标签1 标签501 标签1001 关键词1 关键词501 关键词1001 关键词1501 专题2001
Linux下OracleRAC一个节点宕机导致共享存储无法挂载的故障排除
2020-11-09 12:23:01 责编:小采
文档

环境:两台HP ML570 Linux AS4.5 Oracle 10g两台Server做了Oracle的RAC,通过SAN Switch连接到HP MSA1000故障现象:因为其中一个Ora

环境:

两台HP ML570 Linux AS4.5 Oracle 10g

两台Server做了Oracle的RAC,通过SAN Switch连接到HP MSA1000

故障现象:

因为其中一个Oracle rac node所在的机柜停电,导致两个rac node同时宕机,且Storage上mount的4个ocfs2分区的分区全部丢失(/dev/sda1变成了/dev/sda),无法mount,因此Oracle的服务也无法启动

故障分析及排除:

因客户DB资料没有备份,因此修复时非常小心

a.首先确定Storage在硬件及连通性上没有问题

b.确认os正常,且可以正常访问Storage

c.着手恢复丢失的分区表

因之前设定是的时候是由我来做的,所以对于分区的数量以及大小比较清楚,因此就按照上次的划分格式重新划分一次,目的是重建分区表,应该不会影响数据,因为客户没有备份,所以这个操作还是有很大风险的,但目前只能这么做了.

d.fdisk结束后,reboot server

奇迹出现了,数据还在,且服务启动正常

备注:世上没有绝对的事情,也没有百分之百的保险,虽然做了Oracle的RAC,但也只能保证两台Server的冗余,不能保证Storage的冗余,因此建议客户以后一定要做一个可行的备份策略,并按照其执行.

但还有一个问题,始终没有想明白,就是RAC的一个节点停电宕机,怎么会导致Storage上公用分区的分区表丢失呢?

下载本文
显示全文
专题