怎样解决Oracle RAC环境下因MTU不一致导致的节点挂起

必须全集群统一私网网卡MTU值并重启所有节点，否则CSSD等底层进程仍沿用旧MTU参数导致ORA-27550或ORA-27303；查所有节点ASM alert.log中ORA-27550、ORA-27303及MTU数值对比，确认后永久修改并重启集群。

oracle rac节点挂起（如cssd无法启动、asm报ora-27550或ora-27303）若由mtu不一致引发，**必须全集群统一私网网卡mtu值，并重启所有节点**——临时ifconfig或ip link set修改后不重启，rac底层进程（如css、gmon、lms）仍会沿用旧mtu握手参数，问题不会消失。

查alert日志确认是MTU不匹配而非其他网络故障

直接看ASM或数据库实例的alert.log，重点搜以下错误：

• ORA-27550: Target ID protocol check failed —— 典型MTU协商失败
• ORA-27303: Remote port MTU does not match local MTU. [local: 1500, remote: 9000] —— 明确指出两端MTU值
• IPC Send timeout + lmon/lmd trace中反复出现超时 —— 常伴随MTU不一致的通信卡顿

注意：不要只查一个节点。必须在所有节点上分别检查grid用户的ASM alert日志（路径类似$ORACLE_BASE/diag/asm/+asm*/trace/alert_+ASM*.log），因为节点间MTU差异是双向的，错误可能只显现在“接收方”日志里。

验证并统一所有节点私网网卡MTU值

先确认哪张网卡是私网（interconnect），通常不是eth0，而是eth1、enp0s8或明确标注为private的接口。执行：

ip link show <iface> | grep mtu

常见问题场景：

• 节点1显示mtu 9000，节点2仍是mtu 1500 → 必须统一为9000（推荐）或都回退到1500
• 交换机端口未开启Jumbo Frame支持 → 即使OS设了9000，实际包仍被丢弃，需同步配置交换机
• 使用bonding或teamd聚合口 → 必须在slave接口和master接口上都设置MTU，且顺序不能错（先设slave，再设master）

永久生效（以RHEL/CentOS为例）：

echo "MTU=9000" >> /etc/sysconfig/network-scripts/ifcfg-<iface>

然后systemctl restart network，但仅此不够——见下一条。

为什么改完MTU还必须重启节点？

RAC的底层通信栈（CSS、CRS、ASM）在进程启动时硬编码读取当时网卡的MTU值，后续运行中不会动态重载。即使你用ip link set dev eth1 mtu 9000在线改了，crsd.bin、cssdmonitor等进程仍按旧值建链，导致：

• 心跳包被截断或丢弃，CSSD反复尝试重连后超时退出
• ASM实例启动时校验远端MTU失败，直接报ORA-27550并终止
• 集群资源状态卡在STARTING或INTERMEDIATE，crsctl stat res -t -init可见ora.cssd1长期OFFLINE

MOS文档Doc ID 947223.1明确说明：“After correct MTU issue, a node reboot is required to bring up CRS stack and ASM instance”。滚动重启不可行，必须停掉整个集群再逐节点启动。

容易被忽略的关键点

MTU不一致问题常被误判为“网络不通”，但ping通不代表RAC通信正常——因为ICMP默认小包（

• 用ping -s 8972 -M do <peer_private_ip>（8972 = 9000 - 28字节IP+ICMP头），-M do禁止分片，失败即说明链路不支持该MTU
• 检查交换机端口是否启用Jumbo Frame（如Cisco: system jumbomtu 9000；HPE Aruba: jumbo）
• AIX系统需额外检查no -o ipqmaxlen和no -o rfc1323等TCP参数，MTU变更后这些也可能需调优

最稳妥的做法：所有节点停机 → 统一修改网卡MTU配置 → 启动交换机Jumbo Frame → 开机启动集群。别省那几分钟重启时间，否则问题会反复出现在alert日志里，直到你看到cssd真正进入ONLINE状态。