解决DiskGroup不可用问题的尝试

alex_linux

问题的出现：
服务器是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
天啦，数据居然被我恢复了。立马启动VCS，hagrp -switch，再来一次switch，爽啊！我想许多绝境中重生的人都会有这种感觉吧。
vxprivutil 真的很好用。
其实，再4。0之前，每次对volume的修改都应该先对private进行备份。
这样，你可以通过它来恢复一个不小心remove的volume.
但，4。0有了一个新功能 cbr。 vxvm 会自动的备份5份新的private在/etc/vx/cbr/bk。
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/42994/showart_1218557.html