【故障案例】RAC 节点驱逐 — 心跳超时与 votedisk 故障处理全过程

本文是「每周一个 Oracle 故障案例」系列第 3 篇。RAC 节点驱逐是企业级 DBA 最怕遇到的故障之一——它意味着集群保护机制被触发，某个节点被强制隔离。

故障现象

某公司核心业务系统运行在 Oracle 19c RAC 双节点集群上。周四上午 10:15，监控告警：节点 2（rac2）被驱逐，其上运行的实例 2 宕机，所有连接被转移到节点 1。

影响：

节点 2 上的活跃连接全部断开（约 200 个）
节点 1 负载翻倍
业务有约 30 秒中断（连接切换时间）

排查过程

Step 1：查看 CRS Alert Log

RAC 故障排查的第一步永远是看 Grid Infrastructure 的日志：

Bash

1# CRS Alert Log（最重要的日志）
2
3> **本章目标**：掌握本章核心知识点
4> **前置要求**：完成前序章节学习
5> **预计时长**：60 分钟
6
7tail -500 /u01/app/grid/diag/crs/rac2/crs/trace/alert.log
8
9# 或者用 ocrcheck
10$GRID_HOME/bin/crsctl query crs activeversion

日志中发现关键信息：

YAML

12026-04-24 10:15:03.456
2CRS-1607: The Oracle High Availability Services have been started on node rac2.
3...
42026-04-24 10:14:58.123
5CRS-1606: The Oracle cluster is being reconfigured. Node rac2 is being removed.
6CSS-1013: Voting file heartbeat not renewed by 1 seconds

关键线索：Voting file heartbeat not renewed — 节点 2 无法更新 votedisk 上的心跳信号。

Step 2：检查网络心跳

RAC 有两种心跳机制：

网络心跳（Network Heartbeat）：通过私有互联网络
磁盘心跳（Disk Heartbeat）：通过 votedisk

Bash

1# 检查私网接口状态
2ifconfig eth1  # 或 bond1
3ip addr show eth1
4
5# 检查私网连通性（从 rac1 ping rac2 的私网地址）
6ping -c 10 192.168.1.2

ping 测试结果：10 个包中丢了 4 个，丢包率 40%——私网连通性有问题！

Step 3：深挖网络问题

Bash

1# 检查网卡错误统计
2ethtool -S eth1 | grep -i error
3
4# 输出：
5# rx_crc_errors: 1523
6# rx_frame_errors: 87
7# tx_errors: 0
8
9# 检查交换机端口速率协商
10ethtool eth1
11
12# 输出：
13# Speed: 100Mb/s   ← 应该是 1000Mb/s！
14# Duplex: Half     ← 应该是 Full！

根因定位：节点 2 的私网网卡与交换机端口的速率协商出了问题——从千兆全双工降级到了百兆半双工。

这导致了：

带宽骤降（1000→100 Mbps）
半双工模式下冲突增加，丢包严重
心跳包超时，集群判定节点 2 不可达
触发节点驱逐

Step 4：验证 Votedisk

Bash

1# 检查 votedisk 状态
2$GRID_HOME/bin/crsctl query css votedisk
3
4# 输出应该显示所有 votedisk 的状态

SQL

1-- 检查集群互联状态
2SELECT * FROM gv$cluster_interconnects;
3
4-- 检查实例状态
5SELECT inst_id, instance_name, status, host_name
6FROM gv$instance;

修复过程

紧急修复：修正网卡协商

Bash

1# 在 rac2 上强制千兆全双工
2ethtool -s eth1 speed 1000 duplex full autoneg off
3
4# 确认速率
5ethtool eth1 | grep -E "Speed|Duplex"
6# Speed: 1000Mb/s ✓
7# Duplex: Full ✓

重启节点 2 的集群服务

Bash

1# 启动 CRS
2$GRID_HOME/bin/crsctl start crs
3
4# 确认节点已加入集群
5$GRID_HOME/bin/crsctl stat res -t
6
7# 启动数据库实例
8srvctl start instance -d orcl -i orcl2

永久修复：网卡配置持久化

Bash

1# 编辑网卡配置文件（RHEL/CentOS）
2vi /etc/sysconfig/network-scripts/ifcfg-eth1
3
4# 添加：
5ETHTOOL_OPTS="speed 1000 duplex full autoneg off"

同时联系网络团队检查交换机端口配置。

排查流程总结

RAC 节点驱逐的网络、存储与系统排查路径 RAC 节点驱逐的网络、存储与系统排查路径

RAC 集群健康检查清单

以下检查项建议每周执行一次：

Bash

1# 1. 集群状态
2crsctl stat res -t
3crsctl check crs
4
5# 2. 节点状态
6olsnodes -n -s
7
8# 3. Votedisk 状态
9crsctl query css votedisk
10
11# 4. OCR 状态
12ocrcheck
13
14# 5. 私网连通性
15ping -c 100 <其他节点私网IP> | tail -3
16
17# 6. 网卡状态
18ethtool eth1 | grep -E "Speed|Duplex|Link"
19ethtool -S eth1 | grep error
20
21# 7. ASM 磁盘组
22asmcmd lsdg
23
24# 8. 监听器
25srvctl status listener
26lsnrctl status LISTENER_SCAN1

预防措施

措施	说明
网卡绑定（bonding）	私网使用 active-backup 模式绑定两块网卡
冗余 votedisk	至少 3 个 votedisk 分布在不同存储
网络监控	监控私网丢包率和延迟
交换机配置	关闭端口自协商，强制千兆全双工
OS Watcher	部署 Oracle OS Watcher 持续收集系统指标
定期巡检	每周运行 cluvfy（Cluster Verification Utility）

Bash

1# Cluster Verification 工具
2$GRID_HOME/bin/cluvfy comp nodecon -n rac1,rac2
3$GRID_HOME/bin/cluvfy comp ssa -n rac1,rac2

总结

时间	事件
10:14	私网速率降级，丢包增加
10:15	votedisk 心跳超时，节点 2 被驱逐
10:15	节点 1 接管，连接切换（~30s 中断）
10:25	定位到网卡协商问题
10:30	修复网卡设置，重启集群服务
10:35	节点 2 重新加入集群，业务恢复

核心教训：RAC 的可用性不仅取决于软件配置，网络和存储的稳定性同样关键。一个交换机端口协商问题就能让整个节点被驱逐。

这是「每周一个 Oracle 故障案例」系列的第 3 篇。关注公众号 DBA学习之路 获取完整系列。RAC 高可用的系统学习请看 DBA 学习之路 Day 31-40 →