上周天加班处理的
今天又有进展。周天我只是发现时间差很多,所以我就直接判断数据库可能有问题(而且他两个数据库是分别安装的,只不过后装的使用先装的数据文件,这样是有问题的。因为oracle里面对数据文件有自己的命名,这种命令其实是写在了一些配置文件中,只要把特定的配置文件从先装机上拷贝到后装机上就可以了。但是到底哪些配置文件没有研究。所以以前我的做法都是将先装好的/opt目录打包,拷贝到另一台机器上解压即可使用)。今天张俊说周一按原文档又做了一次,结果还是s2机器有问题。我登上去好好看看。
单就s2上看,数据库手工启动,测试都没有问题(这些张俊也测试过了),但是启动启动heartbeat之后,数据库启动正常,mon启动,没2分钟,heartbeat就停止了。看日志ha-log和ha-debug都没有写为什么失败。我还是采用老办法──
查看进程大法,百试不爽啊。结果从日志中发现mon启动之后,很正常,但是马上就有一个进程
root 5723 1 0 17:33 ? 00:00:00 /bin/sh /usr/lib/mon/alert.d/ha_stop.alert -s net -g net -h -t 1187688783
root 5724 5723 0 17:33 ? 00:00:00 /bin/sh /etc/init.d/heartbeat stop
|
看到两个“net”我忽然想到一个问题:
他们为了测试,只连了心跳,其中s1机器跟一台笔记本链接,因为两台服务器都没有显示器。也就是说s2机器的eth0网卡是“no link”的。而heartbeat监控oracle和网络。 这个结果让我很是吃惊,当时我写的文档非常详细,八十多台机器都按照文档装没有问题,就这一台机器有问题,而且张俊都没有解决。我相信张俊如果没有解决,那肯定是他不细心,因为能力上面我还是非常信任他的。结果我也同样犯了不细心的错误,周天是发现一个比较低级的错误,我就没有再细细的找,结果今天又发现了一个更低级的错误。这也印证了ip的真理:
所有问题的出现,都有原因引起的。所有奇怪问题的出现,肯定有一个特别低级的原因引起的。
阅读(2045) | 评论(0) | 转发(1) |