问题的出现:
服务器是2台
Sun F280R,磁盘阵列是3310,VCS。3310有5块磁盘,1个做hot spare,另外4个两两mirror做成2个LUN。2个LUN在
系统中分别生成2个vmdisk。2个DG,dbdg和appdg。每个DG只有一个vmdisk。
一次故障的发生,VCS无法使dbdg正常切换,检查发现是dbdg无法import。
server2# vxdisk -o alldgs list
DEVICE TYPE DISK GROUP STATUS
c1t0d0s2 sliced rootdisk rootdg online
c3t1d0s2 sliced - (dbdg) online
c3t1d1s2 sliced appdg01 appdg online
server2# vxdg import dbdg
vxvm:vxdg: ERROR: Disk group dbdg: import failed: Disk group has no valid configuration copies
server2#
dbdg上的数据无法访问了。
解决问题的思路:
经过查看资料得知,这种错误是由于DG的配置信息被破坏所造成的。DG的configuration信息是存放在磁盘的Private Region中的,在Solaris中该分区通常是s3分区。
用命令prtvtoc可以看到,Tag=15的分区就是vmdisk的Private Region,通常就1个柱面,但其中存放了DG的所有信息,包括组成该DG的设备vmdisk,还有plex、subdisk以及volume等的划分。如果DG中有2个以上的vmdisk,则DG的配置信息会有多个备份在其他盘上。
现在,dbdg中只有1个vmdisk,该配置信息没有备份,只有想办法修复Private Region中受到损坏的数据,才有可能恢复Public Region的数据。
另一个促使我想修复Private Region的原因是因为dbdg中只有一个volume,而这一个volume就是一个文件系统,故相对来说dbdg中关于vmdisk、plex、subdisk和volume的配置信息应该简单些。否则就只有重新做dbdg了,因为事前咨询过专家,这种Disk group has no valid configuration copies的错误基本是没有希望修复了。
解决的办法:
先看看Private Region能否访问。
server2# /etc/vx/diag.d/vxprivutil scan /dev/rdsk/c3t1d0s3
diskid: 1061270136.1186.server1
group: name=dbdg id=1061270137.1189.server1
flags: private noautoimport
hostid:
version: 2.2
iosize: 512
public: slice=4 offset=0 len=70596608
private: slice=3 offset=1 len=3839
update: time: 1066899655 seqno: 0.308
headers: 0 248
configs: count=1 len=2808
logs: count=1 len=425
这里列出了该vmdisk的部分信息,说明其Private Region没有完全被破坏。
再用list选项看看该Private Region的信息。
server2# /etc/vx/diag.d/vxprivutil list /dev/rdsk/c3t1d0s3
diskid: 1061270136.1186.server1
group: name=dbdg id=1061270137.1189.server1
flags: private noautoimport
hostid:
version: 2.2
iosize: 512
public: slice=4 offset=0 len=70596608
private: slice=3 offset=1 len=3839
update: time: 1066899655 seqno: 0.308
headers: 0 248
configs: count=1 len=2808
logs: count=1 len=425
tocblks: 0
tocs: 2/3837
Defined regions:
config priv 000017-000247[000231]: copy=01 offset=000000 enabled
config priv 000249-002825[002577]: copy=01 offset=000231 enabled
log priv 002826-003250[000425]: copy=01 offset=000000 enabled
将Private Region的配置信息dump出来。
server2# /etc/vx/diag.d/vxprivutil dumpconfig /dev/rdsk/c3t1d0s3 > /disk1.out
vxvm:vxconfigdump: ERROR: Error (File block 3): Format error in configuration copy
这里出现错误提示是正常的,因为这个命令是对好的Private Region做dump,现在的Private Region有问题,该命令访问这个坏的Private Region时,肯定会发现格式不对了。
文件disk1.out的内容:
#Config copy 01
#Header nblocks=11232 blksize=128 hdrsize=512
#flags=0x400 (CHANGE)
#version: 4/9
#dgname: dbdg dgid: 1061270137.1189.server1
#config: tid=0.1235 nrvg=0 nrlink=0 nvol=1 nplex=1 nsd=1 ndm=1 nda=0
#pending: tid=0.1236 nrvg=0 nrlink=0 nvol=1 nplex=1 nsd=1 ndm=1 nda=0
#
#Block 5: flag=0 ref=49 offset=0 frag_size=67
#Block 6: flag=0 ref=55 offset=0 frag_size=64
#Block 8: flag=0 ref=57 offset=0 frag_size=94
#Block 11: flag=0 ref=58 offset=0 frag_size=69
#Block 13: flag=0 ref=55 offset=0 frag_size=112
#
#Record 49: type=0xf015 flags=0 gen_flags=0x4 size=67
#Blocks: 5
dg dbdg
comment="
putil0="
putil1="
putil2="
dgid=1061270137.1181.server1
rid=0.1025
update_tid=0.1027
nconfig=default
nlog=default
base_minor=13000
version=90
#Record 55: type=0x3014 flags=0x1 gen_flags=0x1c size=64
#Blocks: 6
dm dbdg01
comment="
putil0="
putil1="
putil2="
diskid=1061270136.1186.server1
last_da_name=c3t0d0s2
rid=0.1026
removed=off
spare=off
failing=off
update_tid=0.1234
last_da_dev=32/424
#Record 57: type=0x100111 flags=0 gen_flags=0x4 size=94
#Blocks: 8
vol oracle
use_type=fsgen
fstype="
comment="
putil0="
putil1="
putil2="
state="ACTIVE
writeback=on
writecopy=off
specify_writecopy=off
pl_num=1
start_opts="
read_pol=SELECT
minor=13000
user=oracle
group=dba
mode=0600
log_type=REGION
len=70570000
qq=328449803
log_len=0
update_tid=0.1235
rid=0.1050
detach_tid=0.0
active=off
forceminor=off
badlog=off
recover_checkpoint=0
sd_num=0
sdnum=0
kdetach=off
storage=off
layered=off
apprecover=off
recover_seqno=0
recov_id=0
primary_datavol=
guid={aeca2b56-1dd1-11b2-8b12-0003ba3392ca}
#Record 58: type=0x4012 flags=0 gen_flags=0x4 size=69
#Blocks: 11
plex oracle-01
comment="
putil0="
putil1="
putil2="
layout=CONCAT
sd_num=1
state="ACTIVE
log_sd=
update_tid=0.1235
rid=0.1052
vol_rid=0.1050
detach_tid=0.0
log=off
noerror=off
kdetach=off
stale=off
ncolumn=0
raidlog=off
guid={aeca4e4c-15d1-11b2-8312-0003b23392ca}
再用同样的命令对系统中的另外一个vmdisk(属于appdg)dump其Private Region信息。
在进行比较后发现少了以下一段:
#Record 43: type=0x13 flags=0 gen_flags=0x4 size=57
#Blocks: 12
sd appdg01-01
comment="
putil0="
putil1="
putil2="
dm_offset=0
pl_offset=0
len=70572032
update_tid=0.1039
rid=0.1038
plex_rid=0.1036
dm_rid=0.1026
minor=0
detach_tid=0.0
column=0
mkdevice=off
subvolume=off
stale=off
kdetach=off
relocate=off
看来手工增加一段,说不定有希望恢复数据。
仔细研究上面sd这一段,其中的dm_rid、plex_rid都与其相关的dm、plex的rid一致,update_tid总是比rid在最后一位上多1。
由于appdg中,也只有一个volume,再查看appdg的Private Region中dump出来的dg、dm、vol和plex信息段中的rid与sd段中rid的关系,可以尝试确定dbdg中sd段的rid值和update_tid的值。
在disk1.out文件中添加并编辑:
#Record 43: type=0x13 flags=0 gen_flags=0x4 size=57
#Blocks: 12
sd dbdg01-01
comment="
putil0="
putil1="
putil2="
dm_offset=0
pl_offset=0
len=70572032
update_tid=0.1055
rid=0.1054
plex_rid=0.1052
dm_rid=0.1026
minor=0
detach_tid=0.0
column=0
mkdevice=off
subvolume=off
stale=off
kdetach=off
relocate=off
使用命令检查并生成新的文件:
server2# cat disk1.out | vxprint -D - -ht
server2# cat disk1.out | vxprint -D - -mpvsh > config.out
重新初始化磁盘,将磁盘做成vmdisk:
server2# vxdisk -f init c3t1d0
因为c3t1d0原来就是标准的vmdisk格式,即slice 3是Private Region,slice 4是Public Region,该命令只是将c3t1d0重新初始化成vmdisk,slice 4中的数据不会受到影响。
重新生成dbdg,将c3t1d0加入dbdg:
server2# vxdg init dbdg dbdg01=c3t1d0s2
恢复dbdg的配置信息:
server2# vxmake -g dbdg -d config.out
用vxmake生成的volume,需要init:
server2# vxvol -g dbdg init clean oracle oracle-01
有希望了,看看volume能不能启动:
server2# vxvol -g dbdg start oracle
接下来,成败在此一举了:
server2# fsck /dev/vx/rdsk/dbdg/oracle
server2# mount -o logging /dev/vx/dsk/dbdg/oracle /oracle