ASM误操作的教训- -不要熬夜变更,不要用分区

已去除客户信息。

接到报障,客户说从ASM磁盘组DATA里踢了一块盘加到ARCH里,没加进去,再把盘加回DATA发现加不进去,然后DATA磁盘组挂了。

取回来日志,我读了一遍发现,不是这样的。

下面是当时事发的过程,客户从前一天下午就开始变更扩容,但是因为有一块盘原先应该给ARCH但是错给了DATA,并且已经rebalance完了,他们想纠正这个事情,强迫症是好事情。按道理说,踢出,加盘,就算是rebalance没有完成,也不会导致磁盘组整个坏掉,客户全程使用asmca操作的(我非常推荐用asmca来管理磁盘组,非常避讳用命令行),也没有用到force方式加盘。

事*故发生在第二天凌晨的2点21分。

最先从:

从DATA磁盘组drop DATA_008磁盘,这个MEMBER磁盘指向:

26秒之后,尝试向ARCH加盘(第一次误操作)(并且DATA的REBAL没有完成)

但是加错了盘,应该加/dev/mapper/asmARCH04p1(会报错,因为还在rebalance),但是加成了/dev/mapper/asmARCH04,这个盘的头部不是ASM的元数据,
是这个盘的分区表,ASM认为这个盘不是ASM磁盘组的,所以可以顺利加入ARCH磁盘组,并且会更新这个磁盘的头部,把分区表干掉:

因为/dev/mapper/asmARCH04p1这个分区虽然已经执行了从DATA的drop,但是它的rebalance操作没有完成。
所以在ARCH加盘的过程中DATA出现大量ASM block header错误,因为ARCH的add操作破坏了DATA的这个盘的信息。

日志如下:

因为ARCH的操作,需要向/dev/mapper/asmARCH04的头部写入ASM的元数据,这导致/dev/mapper/asmARCH04p1这个分区消失,随后DATA磁盘组被强制DISMOUNT:

这个操作触发ASM保护,去dismount掉其他磁盘组。ARCH的REBAL也被中断了(是好事),因为数据没有被覆盖,或者说没有被覆盖很多。

我理解这个时候,数据基本上都在。但是随后ASM实例被重启了,不知道是agent做的还是人工做的。(这是第二个让事情不可收拾的操作)

重启之后,ASM主动去挂载各个磁盘组,只有DATA因为损坏无法挂载,但是ARCH是可以正常挂载的。
随即ARCH开始rebalance数据,擦除 asmARCH04 这个磁盘的数据,写入ARCH的的rebalance数据:
这是ARCH的成员盘信息:

随后rebalance完成了,这一步意味着asmARCH04的asmARCH04p1分区(仍然数据DATA磁盘组)的原先数据被清空。这一步清除了盘前面的无数个AU。这些AU原先是DATA磁盘组的。
之后,又有从ARCH里drop这个磁盘的操作:
drop掉那个错误进入的整盘。事实上这一步已经没什么意义了:

也成功rebalance完成了。将近5分钟时间说明/dev/mapper/asmARCH04上的数据有很大可能之前被抹除了5分钟。因完全未知抹除的是哪些DATA盘组的数据。
所以恢复难度较大。

这个盘目前的数据构成是,former的磁盘头,一部分arch的数据,和一部分原先DATA的数据。DATA的数据又是打散的。所以恢复难度非常大。
我建议是从备份和ARCH的归档,恢复数据库。如果ARCH中有数据库的redolog的副本,基本可以实现无损恢复。

事后,我在想,如果对ASM很熟悉的话,踢除的盘应该是FORMER状态,而不是CANDIDATE状态,如果知道这个,asmca加盘看到的状态异常就得警醒。

此外,在上一波rebalance没有完成的时候,asmca似乎是看不到这个盘的,操作者原先应该是想找p1的,但是这个盘没有从rebalance里走出来。asmca看不到,加上熬夜太久,凌晨两三点是人最困的时候,一看到有arch04这个盘,就它了。一顿操作猛如虎。

所以,不要熬夜变更,上天是不会眷顾熬夜的人的。如果实在要操作的话,找俩年轻力壮的小伙子做,互相check。

不要用分区。ASM不需要你分区。越简单,越好。

3 thoughts on “ASM误操作的教训- -不要熬夜变更,不要用分区

Kamus 发表评论 取消回复