最近有朋友和小
y
反馈：
创新互联公司长期为成百上千家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为石嘴山企业提供专业的网站建设、网站设计，石嘴山网站改版等技术服务。拥有10年丰富建站经验和众多成功案例,为您定制开发。
他们的一台
IBM
的
X86
服务器（现在属于联想）出现硬件损坏，维护人员通过管理口收集诊断日志给厂商时，服务器上运行的好好的一套
ORACLE 11.2
的
RAC
数据库，
突然有一个节点重启了
..
这是是什么情况
?
听到这里，小
y
基本上猜到了原因，类似的问题，以前分析和处理过几次，分析过程也不复杂，
但是没想到，类似的故障现在居然还在发生
.
因此有必要把这个
风险提示出来
!
这里，小
y
为大家分享一个过去处理的案例
,
文章最后会给出
X86
服务器与
RAC
结合的具体的风险提示，希望大家早了解，早预防，避免踩坑，伤人伤己。
周五，晚上十一点，电话响了，是一位服务商的电话，看来出大事了，一下来了精神;
“小y,一套linux上的11.2.0.3 2节点的RAC， 节点2数据库今天下午自己重启了一次，后来自己起来了。 几个小时前，又挂了，到现在还没起来！ 两个节点私网IP互相ping了一下,可以ping通！ 你赶紧远程连上来处理下吧” |
BTW：
是的，大家没看错，是服务商而不是最终客户的电话。
小y所在的公司不仅直接面向客户提供数据库专家服务，也为其他服务商、软件开发商提供三线支持，不过小y最近业绩压力大的晚上睡不着觉，还请各位兄弟多多帮忙推荐和介绍啊。
时间紧急，远程连入后，发现节点
2
确实挂掉了，那就直接
startup
启动数据库看看
照理来说，startup命令下去后，这里很快就可以看到SGA分配并启动到mount的信息，
但命令下去已经一分钟了，还没任何输出，确实不妙。
最终，startup命令在敲入后长时间依然无响应，大概10分钟后后报ORA-03113错误后退出。
如下图所示：
看来，数据库启动过程中遇到了异常，需要继续分析alert日志。
截取altert日志关键信息，如下图所示：
可以看到：
由于节点
2
的
Lmon
进程通过
ipc
与节点
1
的
LMON
进程通讯超时，简单来说，两个节点的
RAC
无法通讯，因此无法加入集群。因此需要进一步检查两个节点的私网通讯是否正常。
之前他们提到两个节点的私网
IP
是可以
ping
通的，我估计他们是
ping
错
IP
了。
因为，从
11.2.0.2
（含）开始，
ORACLE
私网通讯不再直接采用“我们在私网网卡上所配置的地址（例如
192.168
这样的地址）”，而是采用
GRID
启动后，
ORACLE
在私网网卡上绑定的
169.254
这个网段的地址。确认了一下，他们果然
ping
的是
192.168
这个
IP
，这个
IP
能
PING
通是不够的
…
发出下列命令获得，两个节点私网通讯采用的
IP
地址如下所示:
也就是说，
RAC
两个节点用于私网通讯的真实地址是：
节点
1
采用的私网通讯地址是
169.254.220.75
，而不是
192.168.x.x
节点
2
采用的私网通讯地址是
169.254.106.133
，而不是
192.168.x.x
也就是说，
GRID
启动前后的
IP
，如下所示：
|
Node1
|
Node2
|
备注
|
Bond0
|
192.168.1.1
|
192.168.1.2
|
GRID
启动前、启动后都存在的
IP |
Bond0:1
|
169.254.220.75
|
169.254.106.133
|
GRID
启动后才存在的
IP RAC
和
ASM
通讯使用 |
从上图可以看到：
两个节点之间互相
ping
不通
169.254
这个实际的私网通讯地址！这就是为什么节点
2
的数据库实例加不到集群的原因！
到这里，我们不妨用一张表表格小结一下：
其中
bond0
是私网网卡，
192.168
是手工配置的，
169.254
这个
IP
是
GRID
起来后绑上去的:
|
Node1
|
Node2
|
|
Bond0
|
192.168.1.1
|
192.168.1.2
|
可以互相
ping
通
|
Bond0:1
|
169.254.220.75
|
169.254.106.133
|
互相
ping
不通
|
这是什么情况呢？
其实很简单，别着急，问题原因就在后面，什么时候往下翻，由你决定…
……
……
……
……
……
……
……
……
……
……
……
……
……
……
……
……
那是什么原因导致两个地址不通呢？
我们进一步检查两个节点的路由情况，发现了异常。如下所示
检查，发现节点
1
上的私网路由丢失，导致两个节点之间的私网无法正常通讯，继而无法正常加入集群。
而节点
2
上是存在
169.254
这个路由的！
在节点
1
#route add -net 169.254.0.0 netmask 255.255.0.0 dev bond1
在节点
1
上实施该解决方案后，节点
2
数据库实例启动正常，问题得到解决。
到这里，有同学说，
可以不可以把两个节点的
GRID
全部停掉，全部重启来恢复呢
?
答案是
yes !
|
因为重启
GRID
，会重新在
bond0
绑
169.254
这个
IP
，同时添加
169.254.0.0
这个路由
2016-06-02 23:05:47.457:
[crsd(10403)]CRS-2772:Server 'node2' has been assigned to pool 'ora.RACDB'.
2016-06-03 19:36:48.517:
[/oracle/app/11.2.0.3/grid/bin/orarootagent.bin(8641)]CRS-5018:(:CLSN00037:)
1)
19:36:25,
节点
1 USB0
网卡被分配
169.254.95.120
这个
IP
2)
19:36:48,
节点
1 orarootagent
进程发现
USB0
上分配的
169.254 IP
与
RAC
集群通讯的
IP
冲突后删除
169.254
的路由
，导致两个节点
RAC
无法通讯
3)
19:41:24,
节点
2
报
IPC
通讯超时，被驱逐出集群
4)
由于节点
1
的
169.254
的路由丢失，导致节点
2
无法与节点
1
通讯，一直无法加入集群
5)
手工对节点
1
增加
169.254
的路由后，问题解决
不难看出来，这个行为是正常的行为！
我们以“
Removed unused HAIProute: 169.254.95.0
”作为搜索关键字，在
METALINK
上查找，
MOS
上的下面文章也介绍了这个行为，推测得到验证。
Oracle RAC H/A Failure Causes Oracle Linux Node Eviction On Server With IBM Integrated Management Module (IMM) (文档 ID 1629814.1) |
在部署了
ORACLE11.2.0.2
或以上的版本中
由于集群的
ASM
和
DB
使用
169.254.x.x
作为集群私网通讯的
IP
【
GRID
启动后在私网网卡绑定
169.254.x.x
这个
IP
并添加
169.254.0.0
的路由】
目前已知的情况中，
IBM X86
服务器装完操作系统后，存在
USB0
这样一块网卡，这个网卡是用来和
IMM
通讯的，
IMM
是服务器的管理口，通过
USB
网络的
LAN
进行硬件管理。
当
USB0
网卡被激活时，将分配
169.265.95.120
（
118
）这个
IP
，将导致
RAC
集群路由被破坏，继而导致
DB/ASM
无法通讯而重启
/
节点驱逐的故障
,
#cat /var/log/messages*|grep dhclient |grep "bound to 169.254"
如有，则进入预防环节
2
）
发出下列命令，检查系统是否当前存在非
RAC
私有网卡被分配
169.254
这个网段的
IP
# ifconfig -a .. usb0
Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
# vi
# /sbin/ifdown usb0 # /sbin/ifup usb0 # /sbin/ifconfig usb0 |
本文转载于中亦安图
本文标题：这么用X86，小心ORACLE+RAC中招--技术人生系列第四十一期-我和数据中心的故事
分享URL：http://cdkjz.cn/article/gejdii.html
