- 论坛徽章:
- 0
|
AIX操作系统卷组故障维护
故障描述:
4.20日早晨,发现日报没有正常发送,登录数据库备机查看原因,查看系统的log命令:
errpt |more
没有发现什么异常,不过发现有如下错误:
- F3931284 0410055009 I H ent2 ETHERNET NETWORK RECOVERY MODE
- F3931284 0410055009 I H ent0 ETHERNET NETWORK RECOVERY MODE
- 173C787F 0410053709 I S topsvcs Possible malfunction on local adapter
- 173C787F 0410053709 I S topsvcs Possible malfunction on local adapter
- EC0BCCD4 0410053709 T H ent2 ETHERNET DOWN
- EC0BCCD4 0410053709 T H ent0 ETHERNET DOWN
复制代码 这个时间正好是同事更换以太网交换机的时间
查看数据库同步脚本log:环境: 两台小机,一个存储阵列, 两台机器是hacmp的
有三个卷组,dbvg, statvg, backvg
主机卷组 dbvg
备机卷组:statvg
backvg两机都可以访问,用于备份的
问题描述: 现在备机只要是执行和卷组,pv相关的命令 就挂在那 ,没有反应
我通过进程信息,可以判断是卷组锁定了backvg,
我执行过的操作,再备机上: chvg -u backvg , 已经3个小时了, 还是没有结果,挂载那
然后又在备机上执行 exportvg backvg 又很长时间了,一个多小时,还是挂在那,
请问如何解决这个问题,解锁backvg,我在主机varyonvg backvg时 ,提示:- # varyonvg backvg
- 0516-013 varyonvg: The volume group cannot be varied on because
- there are no good copies of the descriptor area.
- Command: failed stdout: yes stderr: no
- Before command completion, additional instructions may appear below.
- 0516-024 lqueryvg: Unable to open physical volume.
- Either PV was not configured or could not be opened. Run
- diagnostics.
- 0516-024 lqueryvg: Unable to open physical volume.
- Either PV was not configured or could not be opened. Run
- diagnostics.
- 0516-1140 importvg: Unable to read the volume group descriptor area
- on specified physical volume.
复制代码 问题产生的原因:因为backvg卷组是共享卷组(不是并发卷组),在每日的04:00-05:40这段时间
是数据库用backvg备份,而在每次使用卷组的时候都要更改卷组的vgda,vgsa中的
时间戳,而在这段时间里同事更换了交换机,导致两个小机的卷组的VGDA不一致
从而会出现这个错误
解决方法:
首要目的:让备机释放掉对pv,卷组的管理进程,以达到我可以从新管理备机的卷组信息
由于一些原因,我强行kill掉相关LVM命令,导致这些进程都被系统接管,根本无法再kill掉,
即使用kill -9,也是不可以
我当时在想有两个方法可以解决此种情况
1.有一些特殊的方法可以kill掉这些进程
2.重新启动机器让其释放所有资源
咨询了很多人,又google半天,也没有找到可以kill那些进程的方法
最后决定重启机器
因为我的环境是两台小机做了hacmp,为了避免出万一,决定23号凌晨去机房维护,出什么问题也好就近解决
主要是担心网卡down了,远程连接不上
当到了机房,就在外边的维护室(机房太冷了!!能不进去就不进去啊),
我的hacmp配置为有优先级的cascading模式,按优先级来接管资源。优先级高的节点恢复后将回拉资源
而我现在打算reboot备机,所以不会影响主机(我咨询过经验丰富的IBM工程师,在此感谢)
操作步骤:
备机:
执行如下命令:
# reboot
然后就等,按经验,也就5分钟左右,结果等啊等啊,等了20几分钟还没有起来,心想幸好来机房了,进机房连上显示器
没有反映,观察硬件也没有什么错误,于是按重启键,等了一会,系统起来了,简单看看了,发现backvg卷组没问题,可以
varyon,lspv,lslv都没什么问题,不过主机不能varyon这个卷组了,我又发现statvg卷组有问题
当执行lsvg -l statvg ,有问号,但是这个卷组varyon后,mount上的文件系统,用着也没有问题,为了避免隐患,我还是
简单修正下,
这个原因一般是因为ODM库中的VGDA和PV上的VGDA不一致,只要简单的exportvg来解决就可以
exportvg statvg
importvg -y statvg hdisk6 或者 smit importvg
执行后问题解决!!
第二个问题就是把backvg卷组让主机也可以访问
在主机上
清空主机上ODM库中的backvg信息
#exportvg backvg
然后执行
在备机
- # ls -l /dev/backvg
- crw-rw---- 1 root system 53, 0 Nov 24 22:58 /dev/backvg
复制代码 在主机- #smit importvg
- [Entry Fields]
- VOLUME GROUP name [backvg]
- * PHYSICAL VOLUME name [hdisk6] ---backvg里的任何一个 +
- Volume Group MAJOR NUMBER [53]
复制代码 这个53相当于卷组的唯一标识;要没有他,两边机器就不能保证访问相同的卷组backvg这个 +#
结果ok!!
最后重新启动下hacmp软件
#smit clstart
两边看看errpt看是否有错,都没有,于是对主库做一次全备
这次故障是有惊无险,解决的还是蛮顺利的
其实为这次我准备了好几套备用方案
1.重新启动系统,如可以能识别最好---结果真识别了
2. 如果不能varyon,那就强制varyon
#varyonvg -f backvg
如果可以varyon,那最好,如果不行,那就恢复backvg,既recreatevg
3. 如果recreatevg还不能解决,那只有删除了重新创建backvg,当然里面的数据也就没了- #smit mkvg
- #smit mklv
- #smit mkjfs
复制代码 注意
pvid存在三个地方
ODM库中- # lspv
- hdisk0 00c64e4bd07d52a8 rootvg active
- hdisk1 00c64e4bd0e61501 rootvg active
- hdisk2 00c64e4bbdd3e449 dbvg
- hdisk3 00c64e4bbdd3e75f dbvg
- hdisk4 00c64e4bbdd91029 statvg active
- hdisk5 00c64e4bbdd91370 statvg active
- hdisk6 00c64e4bbddabdb3 backvg
- hdisk7 00c64e4bbddac0e8 backvg
- #
复制代码 存在VGDA中- # lqueryvg -Atp hdisk6
- Max LVs: 256
- PP Size: 27
- Free PPs: 5
- LV count: 2
- PV count: 2
- Total VGDAs: 3
- Conc Allowed: 0
- MAX PPs per PV 32768
- MAX PVs: 1024
- Quorum Setting 1
- Auto Varyon ?: 0
- Conc Autovaryo 0
- Varied on Conc 0
- Logical: 00c64e4b00004c000000011dbddadf95.1 loglv02 1
- 00c64e4b00004c000000011dbddadf95.2 fslv07 1
- Physical: 00c64e4bbddabdb3 2 0
- 00c64e4bbddac0e8 1 0
- Total PPs: 2206
- LTG size: 128
- HOT SPARE: 0
- AUTO SYNC: 0
- VG PERMISSION: 0
- SNAPSHOT VG: 0
- IS_PRIMARY VG: 0
- PSNFSTPP: 7168
- VARYON MODE: 0
- VG Type: 2
- Max PPs: 32768
复制代码 存在pv头
# lquerypv -H /dev/hdisk6
00c64e4bbddabdb30000000000000000
|
|