已去除客户信息。
接到报障,客户说从ASM磁盘组DATA里踢了一块盘加到ARCH里,没加进去,再把盘加回DATA发现加不进去,然后DATA磁盘组挂了。
取回来日志,我读了一遍发现,不是这样的。
下面是当时事发的过程,客户从前一天下午就开始变更扩容,但是因为有一块盘原先应该给ARCH但是错给了DATA,并且已经rebalance完了,他们想纠正这个事情,强迫症是好事情。按道理说,踢出,加盘,就算是rebalance没有完成,也不会导致磁盘组整个坏掉,客户全程使用asmca操作的(我非常推荐用asmca来管理磁盘组,非常避讳用命令行),也没有用到force方式加盘。
事*故发生在第二天凌晨的2点21分。
最先从:
1 2 3 4 5 6 7 8 9 10 11 12 |
Fri Jun 28 14:21:05 2019 SQL> ALTER DISKGROUP DATA DROP DISK 'DATA_0008' /* ASMCA */ NOTE: GroupBlock outside rolling migration privileged region NOTE: requesting all-instance membership refresh for group=3 Fri Jun 28 14:21:07 2019 NOTE: membership refresh pending for group 3/0x5a29bed3 (DATA) Fri Jun 28 14:21:10 2019 GMON querying group 3 at 17 for pid 18, osid 42869 SUCCESS: refreshed membership for 3/0x5a29bed3 (DATA) SUCCESS: ALTER DISKGROUP DATA DROP DISK 'DATA_0008' /* ASMCA */ |
从DATA磁盘组drop DATA_008磁盘,这个MEMBER磁盘指向:
1 2 3 4 5 |
NOTE: cache opening disk 8 of grp 3: DATA_0008 path:/dev/mapper/asmARCH04p1 /dev/mapper/asmARCH04p1这个磁盘尾部是p1,这是/dev/mapper/asmARCH04这个磁盘的第一个分区(part 1) |
26秒之后,尝试向ARCH加盘(第一次误操作)(并且DATA的REBAL没有完成)
1 2 3 4 |
Fri Jun 28 14:21:31 2019 SQL> ALTER DISKGROUP ARCH ADD DISK '/dev/mapper/asmARCH04' SIZE 838860M /* ASMCA */ NOTE: Assigning number (1,3) to disk (/dev/mapper/asmARCH04) |
但是加错了盘,应该加/dev/mapper/asmARCH04p1(会报错,因为还在rebalance),但是加成了/dev/mapper/asmARCH04,这个盘的头部不是ASM的元数据,
是这个盘的分区表,ASM认为这个盘不是ASM磁盘组的,所以可以顺利加入ARCH磁盘组,并且会更新这个磁盘的头部,把分区表干掉:
1 2 3 4 |
Fri Jun 28 14:22:04 2019 NOTE: cache opening disk 3 of grp 1: ARCH_0003 path:/dev/mapper/asmARCH04 SUCCESS: ALTER DISKGROUP ARCH ADD DISK '/dev/mapper/asmARCH04' SIZE 838860M /* ASMCA */ |
因为/dev/mapper/asmARCH04p1这个分区虽然已经执行了从DATA的drop,但是它的rebalance操作没有完成。
所以在ARCH加盘的过程中DATA出现大量ASM block header错误,因为ARCH的add操作破坏了DATA的这个盘的信息。
日志如下:
1 2 3 4 5 6 7 8 9 10 |
Fri Jun 28 14:21:34 2019 WARNING: cache read a corrupt block: group=3(DATA) dsk=8 blk=10 disk=8 (DATA_0008) incarn=3915992655 au=0 blk=10 count=1 ORA-15196: invalid ASM block header [kfc.c:26086] [endian_kfbh] [2147483656] [10] [0 != 1] ORA-15196: invalid ASM block header [kfc.c:26086] [endian_kfbh] [2147483656] [10] [0 != 1] ORA-15196: invalid ASM block header [kfc.c:26086] [endian_kfbh] [2147483656] [10] [0 != 1] ERROR: cache failed to read group=3(DATA) dsk=8 blk=10 from disk(s): 8(DATA_0008) ORA-15196: invalid ASM block header [kfc.c:26086] [endian_kfbh] [2147483656] [10] [0 != 1] ORA-15196: invalid ASM block header [kfc.c:26086] [endian_kfbh] [2147483656] [10] [0 != 1] WARNING: Disk 8 (DATA_0008) in group 3 in mode 0x7f is now being taken offline on ASM inst 2 |
因为ARCH的操作,需要向/dev/mapper/asmARCH04的头部写入ASM的元数据,这导致/dev/mapper/asmARCH04p1这个分区消失,随后DATA磁盘组被强制DISMOUNT:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
WARNING: Disk 8 (DATA_0008) in group 3 in mode 0x7f is now being taken offline on ASM inst 2 NOTE: initiating PST update: grp = 3, dsk = 8/0xe9694e4f, mask = 0x6a, op = clear Fri Jun 28 14:21:34 2019 GMON updating disk modes for group 3 at 18 for pid 41, osid 92763 ERROR: Disk 8 cannot be offlined, since diskgroup has external redundancy. ERROR: too many offline disks in PST (grp 3) Fri Jun 28 14:21:35 2019 WARNING: dirty detached from domain 3 NOTE: cache dismounted group 3/0x5A29BED3 (DATA) SQL> alter diskgroup DATA dismount force /* ASM SERVER */ Received dirty detach msg from inst 1 for dom 3 |
这个操作触发ASM保护,去dismount掉其他磁盘组。ARCH的REBAL也被中断了(是好事),因为数据没有被覆盖,或者说没有被覆盖很多。
1 2 3 4 5 6 7 8 9 10 |
Fri Jun 28 14:22:59 2019 Errors in file /u01/app/grid/diag/asm/+asm/+ASM2/trace/+ASM2_ora_111675.trc: ORA-17503: ksfdopn:2 Failed to open file +DATA/prod/spfileprod.ora ORA-15001: diskgroup "DATA" does not exist or is not mounted Fri Jun 28 14:23:13 2019 SQL> ALTER DISKGROUP CRS DISMOUNT /* asm agent // {2:43393:946} / Fri Jun 28 14:23:13 2019 SQL> ALTER DISKGROUP ARCH DISMOUNT / asm agent // {2:43393:946} */ Fri Jun 28 14:23:13 2019 NOTE: stopping process ARB0 NOTE: rebalance interrupted for group 1/0x5a19bed1 (ARCH) |
我理解这个时候,数据基本上都在。但是随后ASM实例被重启了,不知道是agent做的还是人工做的。(这是第二个让事情不可收拾的操作)
1 2 3 4 5 6 7 8 |
Fri Jun 28 14:25:04 2019 Instance shutdown complete Fri Jun 28 14:38:03 2019 * instance_number obtained from CSS = 2, checking for the existence of node 0... * node 0 does not exist. instance_number = 2 Starting ORACLE instance (normal) |
重启之后,ASM主动去挂载各个磁盘组,只有DATA因为损坏无法挂载,但是ARCH是可以正常挂载的。
随即ARCH开始rebalance数据,擦除 asmARCH04 这个磁盘的数据,写入ARCH的的rebalance数据:
这是ARCH的成员盘信息:
1 2 3 |
NOTE: cache opening disk 1 of grp 1: ARCH_0001 path:/dev/mapper/asmARCH02p1 NOTE: cache opening disk 2 of grp 1: ARCH_0002 path:/dev/mapper/asmARCH03p1 NOTE: cache opening disk 3 of grp 1: ARCH_0003 path:/dev/mapper/asmARCH04 |
1 2 3 4 |
mount之后: Fri Jun 28 14:40:49 2019 NOTE: stopping process ARB0 SUCCESS: rebalance completed for group 1/0xb349b98a (ARCH) |
随后rebalance完成了,这一步意味着asmARCH04的asmARCH04p1分区(仍然数据DATA磁盘组)的原先数据被清空。这一步清除了盘前面的无数个AU。这些AU原先是DATA磁盘组的。
之后,又有从ARCH里drop这个磁盘的操作:
drop掉那个错误进入的整盘。事实上这一步已经没什么意义了:
1 2 3 4 |
Fri Jun 28 14:45:11 2019 NOTE: stopping process ARB0 SUCCESS: rebalance completed for group 1/0xb349b98a (ARCH) |
也成功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不需要你分区。越简单,越好。
留个脚印,证明我来过。
更严谨的表达是:磁盘不要分区
K总666~
更严谨的表达是:磁盘不要分成多个区,但4K对齐是要做的。