我搭建的一个db2 DPF环境,在数据库没有stop的情况下,直接被客户重启了服务器,重启完后就发现instance无法启动,这个问题我花了将近两天时间才搞定,甚至都把第二台服务器的系统重装了一遍,现在问题完全解决了,我自己也有了一些认识,记录于此。
首先,当我试图启动instance的时候,发现下面的报错,这些错误只在第二台服务器上的节点报错
SQL6048N A communication error occurred during START or STOP DATABASE MANAGER processing
这个时候我检查过网络,以及NFS 发现都是正常的,检查NFS只是在第二台服务器上
su - db2inst1
并且进行了一些文件读写的操作,都是正常的,但是在这里输入db2命令的时候则需要等待很长时间,然后就会报一个错误,什么什么系统错误之类的,遗憾没有留下当时的错误信息。
这里我折腾了很久,在第二台服务器上也创建一个instance,尝试重装db2软件,还有去设置db2set的变量等等
都不行,后来觉得重装第二台服务器的系统,结果发现重装完系统后instance也不能启动,这个时候我好像发现在这台服务器上的/db2home文件夹的属组都是root的,后来改成db2inst1的了,这次启动instance成功,但后来发现当我再次重启两台服务器后,instance还是启动不了,这个时候整个问题的定位算是找到了,即问题出在NFS上面。
在吃过一顿晚饭后,算是大餐吧,脑子里面不停的在转,我需要找到db2 DPF官方文档之类的资料,以前在部署的时候找到过一篇ibm developerworks上面的文章,可是这几天这个网站处于维护当中。
我参考过 sourceforge上面的Setting Up an NFS Server,地址:
发现我的配置好像也没有什么问题,更关键的是同样是我部署的其他环境的DPF数据库都是正常的,无论我怎么重启数据库。
这个时候我又想起了看看Linux系统的日志,
dmesg
结果,果然看到了我想要的信息,在dmesg显示内容的最底部一直在有如下信息报出来:
lockd: cannot monitor 192.168.1.200
呵呵,那就照着这个继续往下搜索,然后我就找到了一个很有用的命令,
rpcinfo -p hostname2
这里如果显示的结果如果有nlockmgr信息 则说明nfs工作正常,而我的这个环境中运行这个命令时只有:
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 729 status
100024 1 tcp 732 status
知道是这个地方的问题后,我就更改了我nfs mount的语句,从
mount 192.168.1.100:/db2home /db2home
更改成
mount -t nfs 192.168.1.100:/db2home /db2home
并且同时将nfs服务器端重启了一下
service nfs restart
结果就正常了,db2 instance 也能正常启动,但当我重启两台服务器后我还是得手动的restart nfs后再进行nfs mount
直到最终我将nfs mount写进/etc/fstab后,所有的问题都解决了,随便我以什么顺序重启服务器,db2的instance都能正常启动,rpcinfo -p hostname2的输出也显示正常。
/etc/fstab的内容如下:
hostname1:/db2home /db2home nfs rw,timeo=300,retrans=5,hard,intr,bg,suid
当然第一台服务器上的/etc/exports也被我改成用hostname来将文件系统share 出去
自从这一次故障的解决后,让我对nfs的东西也有了更深一步的了解,同时对db2 DPF环境也有了更深入的了解。解决问题的过程会让人感觉很郁闷,很想捶自己,问题解决之后忽然开阔,原来如此,呵呵!
阅读(5336) | 评论(0) | 转发(1) |