首页 > 代码库 > 记一次因网卡心跳故障引发RAC节点重启故障分析
记一次因网卡心跳故障引发RAC节点重启故障分析
数据库与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