首页 > 其他 > 详细

记一次因网卡心跳故障引发RAC节点重启故障分析

时间:2014-07-14 11:26:38      阅读:610      评论:0      收藏:0      [点我收藏+]

数据库与CRS版本:10.2.0.4

down机过程分析

序号

节点

时间

动作

日志源

1

Jul 4 22:48:15

XXdb2 kernel: NETDEV WATCHDOG: eth1: transmit timed out

bnx2: fw sync timeout, reset code = 1020015

OS

2

Jul 4 22:48:29

--

Jul 4 22:49

CRS-1612:node XXdb1 (1) at 50% heartbeat fatal, eviction in 29.118 seconds

]CRS-1610:node XXdb1 (1) at 90% heartbeat fatal, eviction in 5.128 seconds

CRS

3

Jul 4 22:54:14

XXdb2 syslogd 1.4.1: restart

OS

4

Jul 4 22:54:14

XXdb2 ifup: Device eth1 has different MAC address than expected, ignoring.

XXdb2 network: Bringing up interface eth1:  failed

OS

5

Jul  5 01:22:27 -- Jul  5 01:58:49

XXdb2 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.5659

OS

6

Jul 5 01:59:30

XXdb2 shutdown: shutting down for system reboot

OS

7

Jul 5 03:00:08

CRS-1605:CSSD voting file is online: /dev/raw/raw18. Details in /home/oracle/product/10.2.0/crs/log/XXdb2/cssd/ocssd.log

CRS

8

Jul 4 23:00:00

CRS-1612:node XXdb2 (2) at 50% heartbeat fatal, eviction in 29.144 seconds

CRS

9

Jul  4 23:04:55

XXdb1 syslogd 1.4.1: restart

OS

从上面日志来看,整个故障过程如下:

(1) 第二节点操作系统发现eth1(心跳网卡)网络超时,随后第二节点数据库连接第一节点超时,超时4次之后,第二节点数据库强制重启操作系统

(2) 第二节点重启后, eth1起不来,导致CRS等待资源启动中,而也无法启动,CRS日志中的/tmp/crsctl.5659中记录是在等待内部心跳网卡的启动

(3) 第二节点被重启后,第一节点连接第二节点心跳超时,第一节点强制重启操作系统

(4) 问题的源头源于第二节点的心跳网络出现故障所致,并且第二节点因为eth1网卡的运行mac地址与实际mac地址不相符而导致重启服务器后eth1网卡启不来


本文作者:踩点,从事”系统架构、操作系统、存储设备、数据库、中间件、应用程序“六个层面系统性的性能优化工作

欢迎加入 系统性能优化专业群 ,共同探讨性能优化技术。群号:258187244


记一次因网卡心跳故障引发RAC节点重启故障分析,布布扣,bubuko.com

记一次因网卡心跳故障引发RAC节点重启故障分析

原文:http://blog.csdn.net/ljunjie82/article/details/37742293

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!