解决DiskGroup不可用问题的尝试

发布于 2022-10-15 08:59:11 字数 10702 浏览 29 评论 0

解决DiskGroup不可用问题的尝试

问题的出现:
服务器是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
                                               <vol>   <plex>
有希望了,看看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,爽啊!我想许多绝境中重生的人都会有这种感觉吧。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

眉黛浅 2022-10-22 08:59:11

顶个慢慢看

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文