先把最紧张的画面放前面凌晨两点监控大屏上节点2的心跳线直接拉平业务侧已经开始出现连接超时的告警。你一边安抚业务方一边打开CRS日志确认节点2是彻底宕了还是只是被驱逐出集群。这时候最忌讳的就是慌因为生产环境RAC节点恢复这件事操作顺序错了、命令敲多了、或者漏了哪一步清理轻则节点加不回来重则把整个集群拖下水。这篇就是把我处理过的Oracle 19c RAC节点2恢复过程按“故障判断 - 恢复前准备 - 节点重建 - 注册实例 - 验证收尾”这条线完整写出来每一步都附上为什么这么做、不这么做会有什么后果希望能帮你在遇到同样场景时少踩几个坑。1. 故障复盘节点2为什么会掉以及恢复前你必须想清楚的事1.1 节点2故障的常见诱因节点2从RAC集群中“消失”表面上看是crsctl status resource -t里node2相关的资源全部变成OFFLINE或UNKNOWN但背后的原因五花八门。我经手的案例里排在前几位的是这么几类私网网卡或心跳线故障RAC集群节点之间靠私有网络维持心跳一旦私网通信中断超过misscount阈值默认30秒左右具体还要看CSS misscount配置节点就会被集群“投票”驱逐。这类故障在物理机上特别常见网卡松动、交换机端口down、光模块老化都可能导致。存储链路异常OCR和Voting Disk放在ASM共享盘上节点2如果突然丢失了共享存储的访问路径比如光纤交换机zone配置被改、多路径软件异常CSS进程会立刻判死节点直接被踢。内存或CPU资源耗尽节点2上的数据库实例出现内存泄漏、或者某个失控的SQL把CPU打满导致CSSD进程无法及时响应心跳被其他节点判定为“无响应”而驱逐。人为操作失误有人误执行了crsctl stop cluster -n node2、防火墙规则变更没同步、或者内核参数被改动后没重启这些都是我在客户现场见过的真实事故。另外一个容易被忽略的点就是补丁和配置漂移。两个节点的GIGrid Infrastructure版本不一致、/etc/hosts解析不一致、ssh互信失效日积月累就会埋雷之后的某次节点重启就成了引爆点。1.2 恢复前的关键决策在线恢复还是离线重建节点2掉线后先别急着敲命令。我建议你先花几分钟想清楚一个问题节点2是“还能抢救”还是“必须重来”判断依据有三点系统层面还能不能访问如果还能ssh上去crsctl check crs还能返回结果那可能只是集群层面的资源被踢底层操作系统没问题。这种情况优先尝试在线恢复。GI软件是否完整如果$GRID_HOME下的文件损坏、关键日志目录被写满、或者/etc/oracle等配置文件被误删那在线修复的成本可能比重新配置还高不如直接走“清理 - 重建”的路径。时间窗口是否允许有些场景业务等不起你需要在10分钟内把节点2拉回集群。这时候最稳妥的反而是一个干净的离线重建流程因为在线修复时你会不断试探可能越试越乱。注意这里说的“重建”是指重新执行GI配置不是重装操作系统。除非节点2的操作系统本身也崩了否则你不需要动系统盘更不需要重装Oracle软件。2. 恢复前置准备把现场照片收集齐再动手2.1 日志收集与故障定位先搞清楚它为什么挂我个人习惯是在动手恢复之前先把“现场证据”固定下来。这一步既是帮你定位根因也是给你自己留一条后路万一恢复过程中又出了新问题你可以回到这些日志里找线索。需要收集的日志清单如下日志类型路径作用集群告警日志$GRID_BASE/diag/crs/node2/crs/trace/alert.log记录集群资源状态变化CSSD日志$GRID_BASE/diag/crs/node2/crs/trace/cssd.log查看节点驱逐原因CRSD日志$GRID_BASE/diag/crs/node2/crs/trace/crsd.log查看资源反复重启记录OCSSD日志$GRID_BASE/diag/crs/node2/crs/trace/ocssd.log查看心跳与投票细节系统日志/var/log/messages或journalctl -u查看内核报错、网络异常ASM实例告警日志$ORACLE_BASE/diag/asm/asm/node2/alert.log确认ASM实例状态日志里最需要关注的信息是节点驱逐的具体原因。在cssd.log里搜eviction、kill、misscount这些关键词通常能看到类似“CLSHELL_EVT_OCR_DISCONNECT”或者“Network interface failure”这样的描述。如果是网络问题日志里会直接标出是哪个网卡、哪个接口出了问题。2.2 集群与OCR状态评估确认大局没崩在节点2离线期间节点1是单枪匹马扛着整个集群的。你要先确认节点1上的集群状态是健康的才能放心去操作节点2。需要检查的状态和命令如下# 在节点1上执行 crsctl check cluster -n node1 crsctl check crs -n node1 crsctl status resource -t正常情况下crsctl check cluster应该返回CRS-4537: Cluster Ready Services is onlineCluster Synchronization Services is onlineCluster Resource Services is online。如果节点1的CSS或CRS资源也有异常那你得先把节点1稳定住——节点1都自身难保了就别急着碰节点2。还要确认OCR的自动备份是否正常。OCR的自动备份默认每4小时做一次保留最近7份备份位置在$GRID_BASE/cdata/集群名/下。如果你发现最近一次备份时间很接近故障时间那说明集群在故障前还处于相对健康的状态。这也能让你在恢复后做ocrconfig -restore时有的放矢。实操心得恢复前顺带在节点2上执行一次cluvfy comp ocr -n all虽然节点2现在没法通过集群检查但这个命令能帮你提前暴露OCR配置的底层问题免得恢复过程中反复报节点2没有OCR访问权限。3. 节点2重新加入集群的完整操作流程3.1 第一步把节点2的残留进程全部清干净这一步是整个恢复过程中最容易出岔子的环节。你可能会觉得“节点2的集群都挂了还有什么可清的”实际上节点2上很可能残留着一堆僵死的进程ora_*.pid、crsd.bin、cssdagent等这些进程不杀掉后续重建GI配置时会因为“端口被占用”“文件被锁定”而失败。具体的清理步骤是这样的# 在节点2上执行 # 1. 杀干净所有Oracle相关进程 ps -ef | grep -E crs|cssd|evmd|oracle|asm | grep -v grep | awk {print $2} | xargs kill -9 # 2. 清理Oracle相关的临时文件和目录 rm -rf /var/tmp/.oracle rm -rf /tmp/.oracle rm -rf /etc/oracle rm -rf /var/tmp/.oracle rm -f /etc/oraInst.loc rm -f /etc/oratab这里有个细节值得展开说。很多人会有疑问oraInst.loc和oratab删了会不会影响后续恢复其实不会。这些文件是安装和配置过程中动态生成的root.sh执行时会重新创建。反而如果你不删旧文件里的路径可能指向错误的位置导致恢复后的配置路径错乱。另外很多从Windows转过来的DBA会有个习惯性动作去“注册表”里清理Oracle的残留。这里明确说一下Linux系统下没有注册表这个概念Oracle在Linux下的配置全部以文件形式存在。咱们操作的是RAC节点不是单机Windows千万别拿卸载单机Oracle的思路套过来。重要提示清理/etc/oracle目录之前如果你之前自定义过crsconfig_params之类的参数文件记得先备份一份到本地。虽然默认情况下这个目录下没什么不可再生的东西但备份一份总是稳妥的。3.2 第二步复制GI软件并重新配置集群栈节点2上的GI软件目录$GRID_HOME有可能完好无损也有可能已经损坏。稳妥起见我建议直接从节点1把$GRID_HOME整体复制到节点2。这种方式比单独修复损坏文件更省心因为可以保证两个节点的GI软件完全一致版本、补丁、权限完全对齐。复制命令示例# 在节点1上执行 cd /u01/app/19.0.0/grid tar -cf - --exclude./log --exclude./diag . | ssh node2 cd /u01/app/19.0.0/grid tar -xf -复制完成后要确保节点2上GI目录的属主和权限正确。正常应该是root:oinstall目录权限为775。如果权限不对后面root.sh执行时会出现各种奇怪的错误。接下来是配置节点2的GI集群栈。这里有两种路径取决于你用的是命令行方式还是图形化方式。生产环境我推荐命令行方式更可控也更方便留存记录。# 在节点1上执行以grid用户 cd $GRID_HOME/addnode ./addnode.sh -silent CLUSTER_NEW_NODES{node2}addnode.sh内部会把节点2的信息写进集群配置并生成节点2上所需要的配置脚本。执行完成以后会提示你“Please run the following script on node2 as root: /u01/app/19.0.0/grid/root.sh”。这里一定要留意root.sh是必须在节点2上以root身份执行的而且执行过程中不能打断。它会完成OCR/Voting Disk的注册、初始化CSS、配置网络资源等一系列关键动作。执行时间一般在一到两分钟执行完毕后末尾会显示类似CRS-2672: Attempting to start ora.cssd on node2的字样看到这个基本说明GI已经在起来了。# 在节点2上执行 /u01/app/19.0.0/grid/root.sh3.3 第三步处理OCR与表决盘的一致性当节点2执行完root.sh后你可能会发现集群并没有立刻把节点2接纳进来。这通常是因为节点2的OCR缓存和集群当前的OCR版本不一致——节点2在过去一段时间内处于离线状态它在本地缓存的OCR信息已经过期。这时候有两种处理方式如果节点2刚刚执行完root.sh但crsctl status resource -t里节点2的资源还是OFFLINE先别急着手动crsctl start resource。正确的做法是等待集群自动重新同步通常60秒内会完成。你可以用crsctl check cluster -n node2观察状态变化。如果等待超过5分钟还是无法同步那就要考虑OCR是否需要强制同步。先检查节点2上ocrcheck的输出如果提示PROT-1: Failed to initialize或者OCR location不正确说明节点2的OCR配置有问题。此时用ocrconfig -repair修复OCR位置再重启节点2上的CRS。Voting Disk表决盘方面注意确认节点2能够正常读写。节点2的ASM实例起来以后可以执行crsctl query css votedisk查看表决盘状态。正常情况下应该返回类似“1. ONLINE ... /dev/mapper/asm_voting_disk”的信息。如果显示OFFLINE或者带有INVALID字样说明节点2访问共享存储存在问题这时候得优先排查多路径配置和ASM磁盘组的权限。实操心得多数节点2加不回来的案例根子都是存储访问或网络配通的问题而不是集群配置本身的问题。所以恢复过程中一旦卡住先查存储、再查网络最后再回头查集群配置。3.4 第四步给数据库实例“让位”注册节点2的GI栈起来了集群也认了这个节点接下来就是让数据库实例在节点2上恢复正常服务。这一步很多人会忽略一个细节数据库实例和GI是两套体系GI负责集群资源管理数据库实例是跑在GI之上的一个资源。节点2重新加入集群后数据库实例资源不会自动创建你需要手动去注册。# 在节点1上执行以oracle用户 srvctl add instance -db orcl -instance orcl2 -node node2这里的orcl是数据库名orcl2是实例名node2是目标节点。如果你不确定数据库名和实例名的写法可以执行lsnrctl status或者查看/etc/oratab确认。注册完成后启动实例srvctl start instance -db orcl -instance orcl2如果实例能正常启动再执行srvctl status database -d orcl这时候你应该看到每个实例都显示Online并且标注了各自的节点。如果是这样恭喜你核心恢复工作已经完成。3.5 第五步验证负载均衡、故障切换与资源配置数据库实例起来了不代表节点2已经“满血复活”。生产环境的验收标准应该更高一些至少要覆盖以下这些点负载均衡验证从应用侧发起连接确认连接能在节点1和节点2之间均匀分布。可以用lsnrctl services查看两个节点的服务注册情况确认orcl2实例的服务已经在监听器里注册。故障切换验证在非业务高峰期可以做一个轻量的故障切换测试比如在节点2上执行crsctl stop instance -db orcl -instance orcl2 -force观察连接是否快速切换到节点1然后再启动实例验证恢复。资源状态核查用crsctl stat res -t查看所有资源在节点2上的状态包括ASM实例、监听器、SCAN VIP、ONS等确保全部ONLINE。集群日志检查在节点2上检查$GRID_BASE/diag/crs/node2/crs/trace/alert.log确认没有CRS-0184之类的错误。验证过程中如果发现某个资源始终OFFLINE不要急着手动强制启动先看crsd.log里这个资源启动失败的原因。很多情况下是资源依赖的底层服务没起来比如监听器依赖的VIP还没绑到网卡上。4. 生产环境避坑实录这些问题我踩过4.1 典型问题速查表我在处理多套19c RAC的节点恢复时遇到过一些非常典型的问题这里整理成速查表方便你对照排查问题现象根本原因解决思路root.sh执行卡在Adding daemon to inittab/etc/inittab文件损坏或系统不是以systemd方式启动检查init进程类型19c在systemd环境下依赖systemd服务修复systemd状态节点2加入集群后ASM实例无法启动ASM磁盘组权限或磁盘发现路径不一致检查asm_diskstring参数确认多路径设备在节点2上可读crsctl check cluster -n node2提示CRS-4535CSS资源无法启动通常是私网通信问题检查/etc/hosts、网卡状态、防火墙规则OCR检查报PROT-1节点2的OCR缓存和集群OCR不一致手动更新OCR配置或执行ocrconfig -repair实例注册后无法启动提示ORA-29701集群无法识别该实例的配置用srvctl remove instance删除后重新add instance节点2上监听器起不来VIP资源未绑定或listener.ora配置错误先手动crsctl start resource ora.vip再启动监听4.2 恢复后最容易被忽略的“保养”项节点2回到集群之后我强烈建议你不要立刻就走人。有几个“保养”项虽然不影响当前运行但会影响下次故障的恢复时长检查/etc/oratab和/etc/hosts的备份把正确的节点2配置存成快照下次再出问题可以直接对照。确认SSH互信配置节点之间做ssh node2 date、ssh node1 date确认互免密钥仍然有效。很多后续维护操作比如cluvfy依赖互信。重打心跳网卡的绑定配置如果节点2用的网卡是bond或者team模式确认恢复后bonding配置没有变避免私网再次瞬断。同步时间配置19c RAC对集群节点间的时间偏差很敏感确认chrony或NTP在节点2上是同步状态偏差最好控制在1秒以内。注意有些生产环境为了省事节点恢复后不做负载均衡验证就直接交回业务。如果应用侧配置了TAFTransparent Application Failover或者FANFast Application Notification那节点恢复后确实会平滑接管但如果应用侧没有这些机制连接一旦建立后不会自动漂移需要业务侧手动重连一次才能把流量分导到节点2上。4.3 关于“污染”与“干净”的边界感最后分享一个我认为区分资深DBA和普通DBA的细节恢复节点时尽量“只做加法不做减法”。我在客户现场见过太多人为了图省事直接在节点2上重新执行OUI去添加节点结果把本来还能用的$ORACLE_HOME路径、监听配置、tnsnames.ora全给覆盖了。其实在19c时代恢复一个节点2最忌讳的就是“大动干戈”。只要底层操作系统没崩共享存储还能读写就走“复制GI软件 - addnode - root.sh - 注册实例”这条最小化路径。多敲一条命令就多一分引入外部问题的风险。如果你发现节点2的操作系统本身已经无法启动或者/u01文件系统损坏到无法挂载那这已经不是“恢复节点”的范畴而是“重建节点”。这时候你需要重装操作系统、重新配置多路径、重新创建dba组和grid用户、再走一遍addnode流程。那种场景下我建议你额外备份一份/etc/oraInventory默认在/u01/app/oraInventory它是Oracle识别已安装软件的关键丢了它会非常被动。5. 最后的几点经验之谈写到这里整个节点2恢复的流程基本就闭环了。从故障判断、日志收集、残留清理、GI重建到实例注册和验证每一步我都踩过不少坑。如果只能总结成几句话带给大家我的体会是第一恢复节点2的前提是节点1足够稳。所有操作的核心原则就是“别为了救一个节点把整个集群搭进去”。恢复过程中你做的每一步都应该先问自己这一步会不会影响节点1会不会影响全局。第二先快照后操作。不管是在线恢复还是离线重建操作之前花5分钟备份一下/etc下的关键配置hosts、passwd、profile再拍一个$GRID_HOME/crs/install下的配置文件快照。万一恢复失败你能有据可查、有路可退。第三恢复完不等于结束。多花10分钟把RAC集群的健康状态彻底查一遍用cluvfy comp clu -n all、cluvfy comp asm -n all做一次全面体检。我见过太多人节点拉起来就急着切业务结果第二天发现VIP起不来、服务注册不完整又是一次“二次事故”。第四也是最实在的一条平时就把巡检日志留好。生产环境oralce19c rac节点恢复这件事最怕的就是毫无依据地“盲操作”。如果你平时有定期归档节点日志的习惯哪怕只是每周存一次crsctl status resource -t的输出关键时刻都比临时去翻日志快得多。别等到出了事故才想起来“现场”有多重要。希望这篇整理能帮你在真遇到节点2掉线的时候少慌几秒少踩几个坑。手边有环境的话建议在测试库上完整演练一遍恢复流程把命令和日志特征都记熟了。真到生产环境出事那天你会发现心里有底和没底操作起来完全是两种状态。