1. 当集群节点“罢工”故障诊断与应急处理兄弟们今天咱们来聊一个DBA最不想遇到但又必须熟练掌握的场景Oracle 19c RAC集群节点彻底“趴窝”了怎么办想象一下半夜被电话叫醒监控告警一片红某个节点怎么也连不上业务在单节点上苦苦支撑压力巨大。这种时候慌是没用的咱们得有一套清晰的“抢救”流程。节点故障的原因五花八门可能是硬件层面的比如服务器主板、内存、电源挂了或者存储链路出了问题也可能是软件层面的比如操作系统内核崩溃、关键的系统文件被误删甚至是集群软件Grid Infrastructure, GI本身损坏。我遇到过最棘手的一次是机房空调漏水导致服务器短路节点直接物理性“阵亡”。无论原因如何我们的目标都是一致的尽快、安全地将故障节点从集群中剥离并在修复后让它重新“归队”恢复集群的高可用架构。在动手之前最关键的一步是精准诊断。你不能看到一个节点没响应就直接开删万一只是网络闪断呢这里分享几个我常用的诊断命令帮你快速定位问题层级网络与操作系统层首先从正常的节点比如orcl02尝试ping和ssh故障节点orcl01。如果连ping都不通那基本是硬件或网络问题。如果能ssh上去可以检查操作系统日志/var/log/messages、系统负载和关键进程。集群状态层在正常节点上以grid用户身份运行crsctl stat res -t。这个命令会列出所有集群资源的状态。重点关注故障节点上的资源如ora.orcl.db、ora.LISTENER.lsnr、ora.orcl01.vip是OFFLINE、UNKNOWN还是FAILED。同时查看集群告警日志tail -100f $ORACLE_BASE/diag/crs/正常节点名/crs/trace/alert.log里面往往有资源失败的具体原因。存储层对于RAC来说共享存储是生命线。使用asmcmd lsdg和asmcmd lsdisk检查ASM磁盘组和磁盘的可访问性。如果故障节点是因为存储多路径软件如multipath或AFDASM Filter Driver配置丢失导致无法访问共享磁盘那问题就出在这里。通过以上检查你基本能判断出故障是暂时的、可恢复的还是永久性的、需要重装系统。如果确认主机需要重装操作系统或者集群软件损坏到无法修复那么我们就需要进入下一阶段清理故障节点的“残留信息”。这就像给一个坏掉的零件做手术必须先把旧的组织清理干净才能安装新的。很多新手DBA在这一步容易手软清理不彻底导致后面重新加节点时各种报错所以接下来的步骤咱们得仔细看。2. 手术前的准备新节点系统与环境的标准化配置假设故障节点orcl01的主机已经重装完全新的操作系统比如CentOS 7.9现在它是一台“干净”的服务器。我们的任务就是把它配置得和集群中健康的节点orcl02一模一样为重新加入集群做好准备。这一步是基础基础打不牢后面全是坑。首先网络配置是重中之重。hosts文件必须和集群其他节点严格一致。我建议直接从orcl02节点拷贝过来避免手动输入出错。这里不仅是主机名和IPVIP虚拟IP和SCAN IP也一个都不能少。# 在 orcl02 上执行 scp /etc/hosts rootorcl01:/etc/拷贝后务必在orcl01上ping一下所有的主机名和VIP确保解析正确。接下来是存储配置。如果你的集群使用AFD来管理ASM磁盘那么通常不需要配置udev规则。但多路径软件multipath的配置必须一致。同样从orcl02拷贝配置文件并重启服务scp /etc/multipath.conf rootorcl01:/etc/ systemctl restart multipathd multipath -ll执行multipath -ll后对比两个节点看到的磁盘数量、WWN ID和路径状态是否一致。如果磁盘数量对不上后面安装GI时会直接报错。操作系统参数和依赖包是另一个容易出问题的地方。内核参数/etc/sysctl.conf、用户资源限制/etc/security/limits.conf、时间同步配置chrony.conf这些我都习惯直接从正常节点“克隆”过来省心又保险。# 拷贝内核参数并生效 scp /etc/sysctl.conf rootorcl01:/etc/ sysctl -p # 拷贝资源限制 scp /etc/security/limits.conf rootorcl01:/etc/security/ # 拷贝时间同步配置并启动服务 scp /etc/chrony.conf rootorcl01:/etc/ systemctl enable --now chronyd chronyc sources -v时间同步在RAC里极其重要几秒钟的偏差都可能导致节点被驱逐。务必确保两个节点的时间源一致且同步状态良好。依赖包的安装是个体力活。原始文章里列了一长串yum install命令。在实际生产环境中我强烈建议你为这些依赖包创建一个本地YUM仓库或者使用操作系统安装镜像。直接使用yum groupinstall安装“Compatibility Libraries”和“Development Tools”组再补充少量Oracle特定的包如cvuqdisk效率会高很多。别忘了关闭防火墙和SELinux这对新手来说是最常见的“拦路虎”systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i s/^SELINUX.*/SELINUXdisabled/ /etc/selinux/config最后别忘了创建用户和目录。oracle和grid用户的UID、GID以及所属的组oinstall,dba,asmadmin等必须和另一个节点完全一致目录的权限775和属主grid:oinstall也要仔细检查。一个快速验证的方法是在orcl02上执行id oracle和id grid把输出的UID/GID记下来在orcl01上创建用户时用-u和-g参数指定。环境变量文件.bash_profile也可以从orcl02拷贝过来稍作修改主要是ORACLE_SID要改成ASM1和orcl1。3. 彻底“清创”从集群中安全移除故障节点信息好了现在新的orcl01服务器已经准备就绪但集群的“大脑”orcl02节点上的OCR和表决盘还记录着旧orcl01的信息。我们必须像外科医生一样把这些“坏死组织”清理干净才能进行“器官移植”重新加入节点。这一步操作全部在存活的健康节点orcl02上执行。首先处理数据库实例和服务。如果故障节点上原来运行着数据库实例比如orcl1并且这个实例被某个服务Service所使用我们需要先把服务从这个故障实例上移走。这是为了确保业务连续性让服务只跑在健康的orcl2实例上。# 查看服务配置 srvctl config service -d orcl -s orclsrv # 修改服务移除对故障实例的偏好设置强制只运行在orcl2上 srvctl modify service -d orcl -s orclsrv -modifyconfig -preferred orcl2 -f srvctl status service -d orcl -s orclsrv接下来使用DBCA数据库配置助手删除故障节点上的实例信息。这里有图形界面和静默-silent两种方式。生产环境我更喜欢用静默模式写进脚本里更可靠。这个操作会删除该实例对应的重做日志线程thread、UNDO表空间等资源。dbca -silent -deleteInstance \ -nodeName orcl01 \ -gdbName orcl \ -instanceName orcl1 \ -sysDBAUserName sys \ -sysDBAPassword YourSysPassword执行完后用crsctl stat res -t确认ora.orcl1.inst资源已经消失。然后清理集群软件层面的信息。这一步是顺序的不能乱。先删VIP资源再删除节点本身。删除VIP是为了释放IP地址资源。# 切换到root用户并设置GI家目录 export ORACLE_HOME/oracle/app/19.0/grid cd $ORACLE_HOME/bin # 停止并删除故障节点的VIP ./srvctl stop vip -i orcl01-vip ./srvctl remove vip -i orcl01-vip -f接着删除节点本身。这里有个关键点先用olsnodes命令查看节点状态。如果状态是pinned需要先执行crsctl unpin css -n orcl01解除固定否则无法删除。./olsnodes -s -t # 查看状态 ./olsnodes -n -l # 查看编号和详细信息 # 如果状态是 unpinned则直接删除如果是 pinned先执行下一行 # crsctl unpin css -n orcl01 crsctl delete node -n orcl01删除节点后再次执行olsnodes -n -l应该就只看到orcl02一个节点了。最后更新软件清单Inventory。这是很多人会遗漏的一步导致后续加节点时提示“节点已存在”。我们需要分别在oracle用户和grid用户下从本地的oraInventory中移除故障节点的信息。# 1. 更新RDBMS软件清单 (以oracle用户执行) su - oracle cd $ORACLE_HOME/oui/bin ./runInstaller -updateNodeList ORACLE_HOME$ORACLE_HOME CLUSTER_NODES{orcl02} # 2. 更新GI软件清单 (以grid用户执行) su - grid cd $ORACLE_HOME/oui/bin ./runInstaller -updateNodeList ORACLE_HOME$ORACLE_HOME CLUSTER_NODES{orcl02} CRSTRUE -silent完成以上所有步骤后故障节点orcl01就从集群的配置和软件清单中被彻底移除了。现在我们可以放心地把那台已经重装配置好的新服务器当作一个全新的节点加入进来。4. 让节点“归队”重新加入集群的详细操作指南清理工作完成后我们就可以开始“迎新”了。整个过程就像是给集群安装一个新节点只不过很多基础软件GI和RDBMS不需要重新安装而是从现有节点“克隆”过来。核心原则是先在GI层面加入再在DB层面加入。第一步预检查。这是Oracle提供的一个非常好的工具能提前发现配置不一致的地方。在orcl02节点上以grid用户运行集群验证工具CVUsu - grid cluvfy comp peer -refnode orcl02 -n orcl01 # 比较两个节点的配置差异 cluvfy stage -pre nodeadd -n orcl01 # 执行加节点前的专项检查如果检查报告有错误比如内核参数不一致、包缺失必须按照提示在orcl01上修复。如果有警告可以评估是否影响不大。为了加速有时我们会设置一个环境变量忽略某些非致命检查export IGNORE_PREADDNODE_CHECKSY但这个要谨慎使用确保你清楚忽略的是什么。第二步GI软件层面添加节点。这是最关键的一步会把集群软件GI从orcl02推送到orcl01上。进入GI家目录的addnode目录执行脚本。su - grid export IGNORE_PREADDNODE_CHECKSY cd $ORACLE_HOME/addnode ./addnode.sh -silent -ignorePrereq \ CLUSTER_NEW_NODES{orcl01} \ CLUSTER_NEW_VIRTUAL_HOSTNAMES{orcl01-vip}脚本运行过程中会在新节点orcl01上自动安装GI软件。最后它会提示你在两个节点上分别以root身份执行脚本。一定要按顺序执行先在orcl01上执行orainstRoot.sh然后在orcl01上执行root.sh。root.sh脚本运行时间较长会配置集群服务期间要密切关注输出看是否有错误。成功后再到orcl02上执行root.sh如果有提示的话。第三步DB软件层面添加节点。GI加成功后数据库软件也需要“克隆”过去。这个过程和GI加节点类似但切换到了oracle用户。su - oracle export IGNORE_PREADDNODE_CHECKSY cd $ORACLE_HOME/addnode ./addnode.sh -silent -ignorePrereq \ CLUSTER_NEW_NODES{orcl01} \ CLUSTER_NEW_VIRTUAL_HOSTNAMES{orcl01-vip}同样按照提示在orcl01上以root执行脚本。完成后orcl01节点上就有了完整的数据库软件。第四步添加数据库实例。现在我们要在orcl01上创建数据库实例orcl1让它加入到orcl数据库中。再次使用DBCA的静默模式。dbca -silent -addInstance \ -nodeName orcl01 \ -gdbName orcl \ -instanceName orcl1 \ -sysDBAUserName sys \ -sysDBAPassword YourSysPassword这个命令会创建实例所需的spfile、密码文件并启用对应的重做日志线程thread 1和UNDO表空间。第五步重新配置高可用服务。实例起来后我们需要把之前移走的服务再加回来实现负载均衡或故障切换。srvctl modify service -d orcl -s orclsrv \ -modifyconfig -preferred orcl2 -available orcl1 srvctl status service -d orcl -s orclsrv现在orclsrv服务就可以在orcl1和orcl2两个实例上运行了。5. 胜利后的检阅全面验证集群与数据库状态所有操作完成后千万别以为就万事大吉了。必须进行一次全面的“体检”确保集群和数据库都处于完全健康的状态。这就像给一台刚修好的精密仪器做全功能测试。首先检查集群资源状态。在两个节点上分别以grid和root用户运行一些核心命令。# 检查集群就绪服务状态 crsctl check crs # 查看所有资源详细状态确保没有OFFLINE或FAILED的资源 crsctl stat res -t # 检查表决盘状态 crsctl query css votedisk # 检查ASM磁盘组 asmcmd lsdg重点关注新加入的orcl01节点上的资源ora.orcl1.inst实例、ora.LISTENER.lsnr监听、ora.orcl01.vipVIP、ora.net1.network网络等状态都应该是ONLINE。同时要仔细查看集群告警日志过滤ERROR和WARNING信息。日志位置在$ORACLE_BASE/diag/crs/节点名/crs/trace/alert.log。其次检查数据库实例和功能。连接到数据库运行一些查询来验证。-- 连接到任一实例查询所有实例状态 select inst_id, instance_number, instance_name, status, version, thread# from gv$instance; -- 这个查询应该返回两行两个实例状态都应为 OPEN-- 检查会话分布看连接是否均衡 select inst_id, machine, count(*) from gv$session where username is not null group by inst_id, machine; -- 可以简单判断业务连接是否开始流向新节点-- 检查重做日志线程是否正常 select thread#, group#, bytes/1024/1024 as size_mb, status, archived from gv$log order by thread#, group#; -- 确认 thread 1 的日志组状态是 CURRENT 或 INACTIVE不是 UNUSED同样也要检查数据库的告警日志$ORACLE_BASE/diag/rdbms/orcl/orcl1/trace/alert_orcl1.log看看实例启动过程中有没有报错。最后进行简单的功能测试。创建一个测试表插入数据然后从另一个实例查询确保缓存融合Cache Fusion工作正常。-- 在实例1 (orcl1) 上执行 create table test_rac as select * from dual; insert into test_rac values (Hello from orcl1); commit; -- 切换到实例2 (orcl2) 上执行 select * from test_rac; -- 应该能查询到刚插入的数据如果环境配置了Data Guard还需要检查DG状态是否正常。运行select * from V$DATAGUARD_STATS;和select destination, status, error from V$ARCHIVE_DEST_STATUS where status ! VALID;来验证日志传输和应用是否有异常。踩过几次坑之后我养成了一个习惯在完成这类重大变更后除了技术验证还会写一份简单的操作回顾报告记录下操作步骤、遇到的问题和解决方法。这份报告不仅是给领导的交代更是给自己积累的宝贵经验下次再遇到类似情况心里就更有底了。整个恢复过程从诊断到验证核心就是胆大心细步步为营。每个命令执行前都想清楚它的影响每个步骤完成后都立刻验证结果。只要按照这个流程走即使面对节点故障这种紧急情况你也能有条不紊地搞定它。