周六晚上接到客户电话说一个两节点Oracle RAC的节点1在白天机房计划性电源检修后CRS怎么都拉不起来。这套环境是Oracle 11.2.0.4操作系统RedHat 7.6共享存储走ASM平时非常稳定结果一次计划内重启就出幺蛾子。我再细问了现象节点2一直正常对外服务节点1重启后集群起不来手动执行crsctl start crs也是长时间卡住最终报超时。远程上去一翻日志发现所有线索都指向一个平时不太容易被注意的组件——gipc。对普通DBA来说gipc是个藏在集群启动链路深处的进程很多人只在crsctl stat res -t里瞄到过它却很少深究它到底管什么。这次故障排查下来我最大的感受是很多RAC节点CRS起不来的问题表象在ocssd、crsd根子却往往在gipc这一层。如果你的集群也出现过类似“某个节点重启后就是加不回来”的情况这篇实战复盘应该能帮你少走不少弯路。1. 先复盘现象再聊gipc1.1 故障现场CRS卡在哪个阶段先说说我上机后看到的第一个直观现象。执行crsctl start crs后CRS进程并不是完全没反应ohasd能拉起来但整个启动流程会卡在阶段依赖上。具体表现是crsctl stat res -t -init里gipc、gpnp、cssdagent这些资源长时间处于UNKNOWN或OFFLINE。crsctl check crs输出提示CSS daemon没有正常启动。节点2上执行crsctl status cluster -n看到的是节点1显示Offline节点2状态正常。这里有个很重要的经验CRS启动是严格按照init.ohasd - ohasd - gipcd - mdnsd/gpnpd - cssdagent/ocssd - crsd - evmd这个链路走的。上层组件必须等下层组件健康之后才真正拉起。所以当crsd资源本身没有报错但整体启动还是卡住时问题大多出在更早的gipc或者gpnp层而不是crsd本身。1.2 gipc在集群里到底扮演什么角色gipc的全称是Grid Infrastructure Process Communication翻译过来就是“集群基础设施进程间通信”。它运行在每个节点上守护进程叫gipcd主要职责是给集群上层组件提供一套统一的、基于私网的消息传递通道。可以把它理解成快递分拣中心各个集群组件CSS、CRS、EVM等之间要互发包裹gipc负责分拣、路由和传送。如果分拣中心本身瘫痪其他部门再忙也没用。gipc起不来ocssd就无法与对端节点协商心跳crsd也无法完成注册和依赖关系最后表现就是CRS整体卡死或者节点被隔离出集群。在11.2.0.2之后的版本里gipc还承担了一个重要职责就是管理HAIPHighly Available IP。CSS会为每个私网网卡自动分配169.254.x.x网段的虚拟IP这些HAIP由gipc层参与维护ASM和数据库实例也依赖它做私网通信。所以私网网卡状态异常时gipc的报错往往比数据库层的报错来得更早、更直接。2. 定位过程前后翻了三轮日志2.1 排错顺序避免用力过猛很多人一看到CRS起不来第一个念头就是“重启大法”不行就crsctl stop crs -f再不行甚至想动OCR或者重新跑root.sh。我的建议是在没看到日志之前千万别做这些破坏性操作。gipc问题大概率是网络配置或者主机名解析层面的不是集群配置损毁贸然重置反而会把故障扩大。我的排查顺序很简单从上到下先看基础网络通不通ping私网IP、检查网卡状态。看/etc/hosts里节点名解析对不对。优先翻gipcd.log这是最快定位问题的入口。再结合ocssd.log确认影响范围。最后才检查oifcfg和gpnp configuration这类集群级配置。这个顺序的核心思路是gipc是网络层与集群层之间的桥先从它最依赖的网络层下手大概率能锁定根因。2.2 gipcd.log里最扎眼的三类报错这次故障中gipcd.log几乎成了唯一突破口。日志路径在$GRID_HOME/log/节点名/gipcd.log注意要用grid用户权限去读。当时我看到的报错行大致是下面几种[GIPCD][ERROR] [gipcCommNet] unable to bind to local interface 192.168.10.10 [GIPCD][ERROR] [gipcCommNet] gipcCommNetBind failed for endpoint (addr192.168.10.10) [GIPCD][ERROR] [gipcdMain] no usable interface found for cluster interconnect看到这种日志第一反应就是gipc在本地找不到配置的私网接口。这台节点的私网IP是192.168.10.10网卡是bond0但gipcd初始化时绑定这个IP失败于是无法向上层提供IPC服务。ocssd在启动时会尝试通过gipc连接对端节点连接一直失败就反复重试最终导致集群join超时。这里有个细节值得多说一句gipcd在启动时不仅读取oifcfg里的互连定义还会去探测本机实际网络接口是否匹配。它会把hosts文件解析出的节点名、私网IP、实际网卡IP三者做比对任何一个不匹配都会导致绑定失败。所以日志里报“unable to bind”的时候基本可以断定是网络接口配置或主机名解析出了问题。2.3 ocssd.log与crsd.log如何印证顺着日志往下翻在ocssd.log里能看到更明确的失败证据[C CSSD][ERROR] clssgmPeerListener failed to connect to node2 [C CSSD][ERROR] clssgmEstablishConnection: (node2) connect failed, retryingocssd启动时需要通过gipc和节点2建立连接并把节点1自己注册进集群拓扑。如果gipc这一层起不来ocssd就一直卡在“找朋友”的阶段。再看crsd.log内容反而不多因为crsd资源根本还没来得及被正常启动很多状态是空的。眼睛不能只盯着报错的关键词也要看时间线。gipcd.log里的ERROR出现时间要和ocssd.log里的连接失败时间对齐这样才能确认因果关系是gipc先failed然后ocssd才不断重试而不是ocssd先挂了导致gipc异常。我当时在两个日志文件里对比了好几个时间点确认报错间隔完全一致这才定位到根因在第一层。3. 根因与修复重启后的网络“改名”惹的祸3.1 根因拆解一块物理网卡的“身份漂移”继续排查我登录到节点1上执行ifconfig -a发现bond0接口根本不存在实际的物理网卡也少了一张。原来的私网bond由eth1和eth2组成重启后只剩下一张eth2而系统里多出来一张叫eth3的新网卡没配IP。再翻/var/log/messages看到类似“Device eth1 does not seem to be present, delaying initialization”的报错。这就很清晰了节点1的物理网卡在重启后发生了设备名漂移。原来的eth1对应的物理网卡可能因为BIOS枚举顺序、PCI槽位变化或者驱动加载顺序的变化被系统识别成了eth3。而/etc/sysconfig/network-scripts/ifcfg-eth1还在绑定原来的设备名于是网络服务启动时找不到eth1bond0自然起不来。这里必须强调一个概念在Linux系统里网卡设备名并不保证固定。尤其RHEL 6/7时代如果没有用udev规则或biosdevname加固重启后网卡顺序可能改变。对RAC来说私网网卡是集群心跳的命脉这种漂移非常致命。3.2 恢复私网链路让bond0重新站起来修复的第一步不是去动Oracle任何配置而是先把网络恢复回来。具体我做了三步用ethtool -p eth3确认它对应的是哪块物理网卡确保不是把别的网卡改名了。实际测试时eth3对应端口就是原来eth1所在的物理网口。把ifcfg-eth1内容复制为ifcfg-eth3并把DEVICE参数改成eth3同时保留原来的HWADDRMAC地址。这一步相当于让系统重新认识这张网卡。检查ifcfg-bond0里的BONDING_MASTER和bond-slaves参数里是否引用了eth3同步改成正确的从属网卡名然后执行systemctl restart network。命令执行完ifconfig -a里很快看到bond0重新出现IP也恢复成了192.168.10.10。我马上ping了一下节点2的私网IP 192.168.10.20通了。到这里网络层面已经正常。3.3 修正主机名解析与gipc的关联网络通了不代表gipc就能立刻恢复还要确认hosts文件。很多RAC环境出问题就是因为/etc/hosts里节点名被解析到公网IP或者第一行把主机名随意放到了127.0.0.1上。gipc在建立节点连接时会依赖主机名到私网IP的映射如果解析到公网IP私网流量就可能走错路由。我检查了节点1的/etc/hosts发现之前有人加了一行“127.0.0.1 node1 node1-priv”这会让gipc有时把本机解析到loopback地址导致bind到私网IP时出现歧义。我删掉了这行多余配置确保两节点的私有主机名都对应真实的私网IP192.168.10.10 node1-priv 192.168.10.20 node2-priv这里给大家一个通用原则RAC节点上的/etc/hosts第一行不要放主机名只留127.0.0.1 localhost localhost.localdomain后面单独用私网IP映射私有主机名用公网IP映射public主机名。主机名解析一旦混乱gipc这类对网络敏感的基础组件很容易踩雷。3.4 用oifcfg校准私网互连配置网络和hosts都恢复后下一步检查Oracle层面的互连配置。在grid用户下执行oifcfg getif可以看到当前集群识别的网络接口信息。结果发现节点1上的oifcfg里还记录着bond0/192.168.10.0作为cluster_interconnect而节点2上的配置也是bond0。虽然接口名没变但为了保险起见我用oifcfg -iflist确认当前系统可见接口列表再执行了一次oifcfg setif重新校准# 先查看 oifcfg getif # 重新设置全局cluster_interconnect配置 oifcfg setif -global bond0/192.168.10.0:cluster_interconnect修改后再次执行oifcfg getif确保两台节点输出一致。这种一致性很重要因为gpnp profile和gipc初始化都会参考这些信息两边不一致会导致节点加入集群时拓扑信息对不上。关于gpnp还有个小提示如果怀疑gipc读到的信息还是旧配置可以执行gpnptool get查看profile内容。但不要轻易gpnptool delete重建那是最后手段。在本案例里等网络和oifcfg都修复后gipc重新初始化就能读到正确配置了。3.5 重启GI的过程与验证配置改完后最关键的一步是让GI重新初始化gipc。我在两个节点上依次执行了重启操作# 在节点1上执行等待它彻底停止 crsctl stop crs -f # 重新启动 crsctl start crs如果crsctl stop crs -f后进程迟迟不掉不要马上kill -9先观察几分钟。gipc或ocssd在处理中断时偶尔会有短暂延迟暴力杀进程可能导致IPC资源残留反而更难恢复。这次重启相对顺利节点1的GI完整启动后我再执行了一系列验证命令crsctl check crs输出三个关键组件全部正常。crsctl stat res -t看到gipc、gpnp、cssd、crsd、evmd全部ONLINE。crsctl status cluster -n两个节点状态都是Online。oifcfg getif配置与预期一致。最后在节点1上执行cluvfy comp net -n node1,node2验证私网互连结果通过。整个故障处理到这里才算真正闭环。4. 下次再遇到排查速查与加固方案4.1 gipc相关常见故障速查表这次处理完我把gipc相关的典型故障和排查方向整理成了一个表方便以后再遇到类似问题时快速对照故障现象可能原因首选排查路径gipcd.log报unable to bind local interface私网网卡未启动、IP丢失、bond失效ifconfig -a检查网卡/var/log/messages查网络启动报错gipc连接对端节点超时私网链路不通、防火墙拦截、MTU不一致用ping和telnet验证私网端口连通性检查iptableshosts解析导致gipc行为异常hosts文件把私有主机名解析成127.0.0.1或公网IP检查/etc/hosts确保私有主机名对应私网IPoifcfg里配置与物理网卡不匹配网卡设备名漂移、接口顺序改变用oifcfg -iflist对比实际接口重新setifgipc资源反复失败但网络正常gpnp profile损坏或信息不一致用gpnptool get查看确认两节点profile一致CRS卡在cssd无法join集群gipc握手失败找不到对端节点gipcd.log和ocssd.log时间点对齐分析这个表不能解决所有问题但能帮你把排查方向快速收敛到网络层、解析层还是集群配置层。别一上来就怀疑OCR损坏或者集群配置丢失那是最极端的情况。4.2 日常巡检和变更控制的几点建议经历过这次故障我对RAC私网这块的日常管理有了更深的认识这里分享几条建议第一对私网网卡的命名做固化。在Linux上可以通过udev规则或biosdevname把网卡设备名与PCI槽位或MAC绑定避免设备名漂移。尤其机房做过硬件维护、网卡换槽位之后一定要检查接口顺序。如果没有固化规则任何一次重启都可能引发类似问题。第二hosts文件纳入变更管理。看似最不起眼的一行配置对gipc来说就是生命线。任何涉及主机名、VIP、SCAN IP的变更都要同步检查所有节点的/etc/hosts并使用diff确认一致性。我见过太多次因为hosts文件不一致导致集群故障的案例。第三巡检时不要只盯数据库实例状态。gipc和gpnp这类底层组件平时默默无闻但一旦出问题影响就是全局的。建议定期检查crsctl stat res -t -init里gipc、gpnp、cssd的资源状态同时用oifcfg getif对比各节点输出确认私网互连配置没有被意外修改。第四重启GI前先打快照或者至少保存日志。CRS起不来时gipcd.log、ocssd.log里的内容是最宝贵的证据。有些人习惯先重启一遍看看结果重启后又正常了但下次故障很可能复发而且没有任何日志可以参考。遇到起不来的情况先把日志复制一份再说。第五别轻易走“重置集群”这条路。很多人在排查gipc问题无果后会选择crsctl delete crs或重跑root.sh这相当于把整个集群配置推倒重来丢配置的风险远大于收益。gipc问题基本都是配置和网络层面的修复路径很清晰只要耐心看日志大概率能找出根因。5. 最后说一点个人体会RAC这种架构越到深处越考验对基础组件的理解。gipc这个名字说出来很多人不熟但它在集群通信链路里的地位不亚于CSS。这次故障如果我没有先去翻gipcd.log而是直接在ocssd、crsd层面死磕可能还得走不少弯路。日志是最诚实的朋友尤其在集群启动失败这种高压力场景下一条清晰的ERROR就能把排查时间从几小时缩短到几分钟。另外处理这类问题时一定要先在网络和操作系统层面确认无误再考虑Oracle配置层面顺序反了很容易把问题扩大。希望这篇复盘能帮到正在为RAC节点“加不回来”而头疼的同行们。
Oracle RAC节点重启后CRS起不来？根因可能在gipc层
周六晚上接到客户电话说一个两节点Oracle RAC的节点1在白天机房计划性电源检修后CRS怎么都拉不起来。这套环境是Oracle 11.2.0.4操作系统RedHat 7.6共享存储走ASM平时非常稳定结果一次计划内重启就出幺蛾子。我再细问了现象节点2一直正常对外服务节点1重启后集群起不来手动执行crsctl start crs也是长时间卡住最终报超时。远程上去一翻日志发现所有线索都指向一个平时不太容易被注意的组件——gipc。对普通DBA来说gipc是个藏在集群启动链路深处的进程很多人只在crsctl stat res -t里瞄到过它却很少深究它到底管什么。这次故障排查下来我最大的感受是很多RAC节点CRS起不来的问题表象在ocssd、crsd根子却往往在gipc这一层。如果你的集群也出现过类似“某个节点重启后就是加不回来”的情况这篇实战复盘应该能帮你少走不少弯路。1. 先复盘现象再聊gipc1.1 故障现场CRS卡在哪个阶段先说说我上机后看到的第一个直观现象。执行crsctl start crs后CRS进程并不是完全没反应ohasd能拉起来但整个启动流程会卡在阶段依赖上。具体表现是crsctl stat res -t -init里gipc、gpnp、cssdagent这些资源长时间处于UNKNOWN或OFFLINE。crsctl check crs输出提示CSS daemon没有正常启动。节点2上执行crsctl status cluster -n看到的是节点1显示Offline节点2状态正常。这里有个很重要的经验CRS启动是严格按照init.ohasd - ohasd - gipcd - mdnsd/gpnpd - cssdagent/ocssd - crsd - evmd这个链路走的。上层组件必须等下层组件健康之后才真正拉起。所以当crsd资源本身没有报错但整体启动还是卡住时问题大多出在更早的gipc或者gpnp层而不是crsd本身。1.2 gipc在集群里到底扮演什么角色gipc的全称是Grid Infrastructure Process Communication翻译过来就是“集群基础设施进程间通信”。它运行在每个节点上守护进程叫gipcd主要职责是给集群上层组件提供一套统一的、基于私网的消息传递通道。可以把它理解成快递分拣中心各个集群组件CSS、CRS、EVM等之间要互发包裹gipc负责分拣、路由和传送。如果分拣中心本身瘫痪其他部门再忙也没用。gipc起不来ocssd就无法与对端节点协商心跳crsd也无法完成注册和依赖关系最后表现就是CRS整体卡死或者节点被隔离出集群。在11.2.0.2之后的版本里gipc还承担了一个重要职责就是管理HAIPHighly Available IP。CSS会为每个私网网卡自动分配169.254.x.x网段的虚拟IP这些HAIP由gipc层参与维护ASM和数据库实例也依赖它做私网通信。所以私网网卡状态异常时gipc的报错往往比数据库层的报错来得更早、更直接。2. 定位过程前后翻了三轮日志2.1 排错顺序避免用力过猛很多人一看到CRS起不来第一个念头就是“重启大法”不行就crsctl stop crs -f再不行甚至想动OCR或者重新跑root.sh。我的建议是在没看到日志之前千万别做这些破坏性操作。gipc问题大概率是网络配置或者主机名解析层面的不是集群配置损毁贸然重置反而会把故障扩大。我的排查顺序很简单从上到下先看基础网络通不通ping私网IP、检查网卡状态。看/etc/hosts里节点名解析对不对。优先翻gipcd.log这是最快定位问题的入口。再结合ocssd.log确认影响范围。最后才检查oifcfg和gpnp configuration这类集群级配置。这个顺序的核心思路是gipc是网络层与集群层之间的桥先从它最依赖的网络层下手大概率能锁定根因。2.2 gipcd.log里最扎眼的三类报错这次故障中gipcd.log几乎成了唯一突破口。日志路径在$GRID_HOME/log/节点名/gipcd.log注意要用grid用户权限去读。当时我看到的报错行大致是下面几种[GIPCD][ERROR] [gipcCommNet] unable to bind to local interface 192.168.10.10 [GIPCD][ERROR] [gipcCommNet] gipcCommNetBind failed for endpoint (addr192.168.10.10) [GIPCD][ERROR] [gipcdMain] no usable interface found for cluster interconnect看到这种日志第一反应就是gipc在本地找不到配置的私网接口。这台节点的私网IP是192.168.10.10网卡是bond0但gipcd初始化时绑定这个IP失败于是无法向上层提供IPC服务。ocssd在启动时会尝试通过gipc连接对端节点连接一直失败就反复重试最终导致集群join超时。这里有个细节值得多说一句gipcd在启动时不仅读取oifcfg里的互连定义还会去探测本机实际网络接口是否匹配。它会把hosts文件解析出的节点名、私网IP、实际网卡IP三者做比对任何一个不匹配都会导致绑定失败。所以日志里报“unable to bind”的时候基本可以断定是网络接口配置或主机名解析出了问题。2.3 ocssd.log与crsd.log如何印证顺着日志往下翻在ocssd.log里能看到更明确的失败证据[C CSSD][ERROR] clssgmPeerListener failed to connect to node2 [C CSSD][ERROR] clssgmEstablishConnection: (node2) connect failed, retryingocssd启动时需要通过gipc和节点2建立连接并把节点1自己注册进集群拓扑。如果gipc这一层起不来ocssd就一直卡在“找朋友”的阶段。再看crsd.log内容反而不多因为crsd资源根本还没来得及被正常启动很多状态是空的。眼睛不能只盯着报错的关键词也要看时间线。gipcd.log里的ERROR出现时间要和ocssd.log里的连接失败时间对齐这样才能确认因果关系是gipc先failed然后ocssd才不断重试而不是ocssd先挂了导致gipc异常。我当时在两个日志文件里对比了好几个时间点确认报错间隔完全一致这才定位到根因在第一层。3. 根因与修复重启后的网络“改名”惹的祸3.1 根因拆解一块物理网卡的“身份漂移”继续排查我登录到节点1上执行ifconfig -a发现bond0接口根本不存在实际的物理网卡也少了一张。原来的私网bond由eth1和eth2组成重启后只剩下一张eth2而系统里多出来一张叫eth3的新网卡没配IP。再翻/var/log/messages看到类似“Device eth1 does not seem to be present, delaying initialization”的报错。这就很清晰了节点1的物理网卡在重启后发生了设备名漂移。原来的eth1对应的物理网卡可能因为BIOS枚举顺序、PCI槽位变化或者驱动加载顺序的变化被系统识别成了eth3。而/etc/sysconfig/network-scripts/ifcfg-eth1还在绑定原来的设备名于是网络服务启动时找不到eth1bond0自然起不来。这里必须强调一个概念在Linux系统里网卡设备名并不保证固定。尤其RHEL 6/7时代如果没有用udev规则或biosdevname加固重启后网卡顺序可能改变。对RAC来说私网网卡是集群心跳的命脉这种漂移非常致命。3.2 恢复私网链路让bond0重新站起来修复的第一步不是去动Oracle任何配置而是先把网络恢复回来。具体我做了三步用ethtool -p eth3确认它对应的是哪块物理网卡确保不是把别的网卡改名了。实际测试时eth3对应端口就是原来eth1所在的物理网口。把ifcfg-eth1内容复制为ifcfg-eth3并把DEVICE参数改成eth3同时保留原来的HWADDRMAC地址。这一步相当于让系统重新认识这张网卡。检查ifcfg-bond0里的BONDING_MASTER和bond-slaves参数里是否引用了eth3同步改成正确的从属网卡名然后执行systemctl restart network。命令执行完ifconfig -a里很快看到bond0重新出现IP也恢复成了192.168.10.10。我马上ping了一下节点2的私网IP 192.168.10.20通了。到这里网络层面已经正常。3.3 修正主机名解析与gipc的关联网络通了不代表gipc就能立刻恢复还要确认hosts文件。很多RAC环境出问题就是因为/etc/hosts里节点名被解析到公网IP或者第一行把主机名随意放到了127.0.0.1上。gipc在建立节点连接时会依赖主机名到私网IP的映射如果解析到公网IP私网流量就可能走错路由。我检查了节点1的/etc/hosts发现之前有人加了一行“127.0.0.1 node1 node1-priv”这会让gipc有时把本机解析到loopback地址导致bind到私网IP时出现歧义。我删掉了这行多余配置确保两节点的私有主机名都对应真实的私网IP192.168.10.10 node1-priv 192.168.10.20 node2-priv这里给大家一个通用原则RAC节点上的/etc/hosts第一行不要放主机名只留127.0.0.1 localhost localhost.localdomain后面单独用私网IP映射私有主机名用公网IP映射public主机名。主机名解析一旦混乱gipc这类对网络敏感的基础组件很容易踩雷。3.4 用oifcfg校准私网互连配置网络和hosts都恢复后下一步检查Oracle层面的互连配置。在grid用户下执行oifcfg getif可以看到当前集群识别的网络接口信息。结果发现节点1上的oifcfg里还记录着bond0/192.168.10.0作为cluster_interconnect而节点2上的配置也是bond0。虽然接口名没变但为了保险起见我用oifcfg -iflist确认当前系统可见接口列表再执行了一次oifcfg setif重新校准# 先查看 oifcfg getif # 重新设置全局cluster_interconnect配置 oifcfg setif -global bond0/192.168.10.0:cluster_interconnect修改后再次执行oifcfg getif确保两台节点输出一致。这种一致性很重要因为gpnp profile和gipc初始化都会参考这些信息两边不一致会导致节点加入集群时拓扑信息对不上。关于gpnp还有个小提示如果怀疑gipc读到的信息还是旧配置可以执行gpnptool get查看profile内容。但不要轻易gpnptool delete重建那是最后手段。在本案例里等网络和oifcfg都修复后gipc重新初始化就能读到正确配置了。3.5 重启GI的过程与验证配置改完后最关键的一步是让GI重新初始化gipc。我在两个节点上依次执行了重启操作# 在节点1上执行等待它彻底停止 crsctl stop crs -f # 重新启动 crsctl start crs如果crsctl stop crs -f后进程迟迟不掉不要马上kill -9先观察几分钟。gipc或ocssd在处理中断时偶尔会有短暂延迟暴力杀进程可能导致IPC资源残留反而更难恢复。这次重启相对顺利节点1的GI完整启动后我再执行了一系列验证命令crsctl check crs输出三个关键组件全部正常。crsctl stat res -t看到gipc、gpnp、cssd、crsd、evmd全部ONLINE。crsctl status cluster -n两个节点状态都是Online。oifcfg getif配置与预期一致。最后在节点1上执行cluvfy comp net -n node1,node2验证私网互连结果通过。整个故障处理到这里才算真正闭环。4. 下次再遇到排查速查与加固方案4.1 gipc相关常见故障速查表这次处理完我把gipc相关的典型故障和排查方向整理成了一个表方便以后再遇到类似问题时快速对照故障现象可能原因首选排查路径gipcd.log报unable to bind local interface私网网卡未启动、IP丢失、bond失效ifconfig -a检查网卡/var/log/messages查网络启动报错gipc连接对端节点超时私网链路不通、防火墙拦截、MTU不一致用ping和telnet验证私网端口连通性检查iptableshosts解析导致gipc行为异常hosts文件把私有主机名解析成127.0.0.1或公网IP检查/etc/hosts确保私有主机名对应私网IPoifcfg里配置与物理网卡不匹配网卡设备名漂移、接口顺序改变用oifcfg -iflist对比实际接口重新setifgipc资源反复失败但网络正常gpnp profile损坏或信息不一致用gpnptool get查看确认两节点profile一致CRS卡在cssd无法join集群gipc握手失败找不到对端节点gipcd.log和ocssd.log时间点对齐分析这个表不能解决所有问题但能帮你把排查方向快速收敛到网络层、解析层还是集群配置层。别一上来就怀疑OCR损坏或者集群配置丢失那是最极端的情况。4.2 日常巡检和变更控制的几点建议经历过这次故障我对RAC私网这块的日常管理有了更深的认识这里分享几条建议第一对私网网卡的命名做固化。在Linux上可以通过udev规则或biosdevname把网卡设备名与PCI槽位或MAC绑定避免设备名漂移。尤其机房做过硬件维护、网卡换槽位之后一定要检查接口顺序。如果没有固化规则任何一次重启都可能引发类似问题。第二hosts文件纳入变更管理。看似最不起眼的一行配置对gipc来说就是生命线。任何涉及主机名、VIP、SCAN IP的变更都要同步检查所有节点的/etc/hosts并使用diff确认一致性。我见过太多次因为hosts文件不一致导致集群故障的案例。第三巡检时不要只盯数据库实例状态。gipc和gpnp这类底层组件平时默默无闻但一旦出问题影响就是全局的。建议定期检查crsctl stat res -t -init里gipc、gpnp、cssd的资源状态同时用oifcfg getif对比各节点输出确认私网互连配置没有被意外修改。第四重启GI前先打快照或者至少保存日志。CRS起不来时gipcd.log、ocssd.log里的内容是最宝贵的证据。有些人习惯先重启一遍看看结果重启后又正常了但下次故障很可能复发而且没有任何日志可以参考。遇到起不来的情况先把日志复制一份再说。第五别轻易走“重置集群”这条路。很多人在排查gipc问题无果后会选择crsctl delete crs或重跑root.sh这相当于把整个集群配置推倒重来丢配置的风险远大于收益。gipc问题基本都是配置和网络层面的修复路径很清晰只要耐心看日志大概率能找出根因。5. 最后说一点个人体会RAC这种架构越到深处越考验对基础组件的理解。gipc这个名字说出来很多人不熟但它在集群通信链路里的地位不亚于CSS。这次故障如果我没有先去翻gipcd.log而是直接在ocssd、crsd层面死磕可能还得走不少弯路。日志是最诚实的朋友尤其在集群启动失败这种高压力场景下一条清晰的ERROR就能把排查时间从几小时缩短到几分钟。另外处理这类问题时一定要先在网络和操作系统层面确认无误再考虑Oracle配置层面顺序反了很容易把问题扩大。希望这篇复盘能帮到正在为RAC节点“加不回来”而头疼的同行们。
