RAC管理这个系列写到第三篇前两篇我们聊了安装前的基础准备和整体架构这期把集群软件里最容易被忽视、但又最不能出事的一个组件单独拎出来讲——CSS全称 Cluster Synchronization Services集群同步服务。它是 Oracle RAC 集群软件的核心之一负责维护节点成员关系、监控集群心跳并在脑裂split-brain发生时执行仲裁。简单说CSS 就是那个决定“节点该不该活着、集群还成不成”的组件。网上聊 Oracle RAC 集群原理的帖子不少但提到 CSS 大多是一句话带过“负责心跳和脑裂检测”。真正到了运维现场你会发现 CSS 相关的进程、日志、参数和故障案例在 RAC 问题里占比一点都不低。这篇文章的目标读者是正在维护 RAC 集群的 DBA 和运维工程师也适合刚入门想搞懂 RAC 原理的朋友。我把这些年和 CSS 打交道攒下来的内容整理成一套“看得懂、查得到、能操作”的经验帖少讲虚的多给实战。1. CSS到底管什么成员资格、心跳与仲裁1.1 一个“拉闸保安”的日常成员资格与重构RAC 环境里每个节点上有一个ocssd.bin进程名字不起眼干的却是集群里最核心的管理工作确定集群中有哪些节点、每个节点被分配什么节点号、节点加入或离开时如何重组集群。它周期性地和各节点交换心跳信息再根据心跳结果维护一张“成员名单”。我习惯把一个集群比作一个家庭群CSS 就是群管理员每个节点是群成员。成员每隔几秒发一条“我还活着”的消息管理员收不到某个成员的消息并不会马上踢人而是等一段时间确认对方确实失联才执行“全体重新确认名单”的操作。这个流程在 Oracle 里叫 reconfiguration也就是节点成员关系重构。reconfiguration 期间集群会做一系列保护动作暂停部分 I/O、重新计算资源归属、锁也会短暂冻结。所以你会看到数据库告警日志里出现IPC Send timeout、IPC Receive timeout之类的报错背后的真正事件往往就是 CSS 在做重组。这也是为什么 CSS 状态异常会直接影响会话和 ASM 实例——它是整个集群的底层地基上层所有组件都依赖它。1.2 两类心跳为什么谁都缺不了CSS 的存活判断依赖两类心跳网络心跳和磁盘心跳。网络心跳走的是私有网络cluster interconnect也就是 RAC 专门为集群内部通信配置的私网。每个节点周期性发送心跳包默认配置下如果超过 misscount 时间默认 30 秒没有收到某个节点的心跳并且磁盘心跳也同时判定该节点不可用CSS 就会启动驱逐eviction流程最极端的手段是直接把那个节点重启。网络心跳丢失的典型场景是私网交换机故障、网卡故障、或者私网被异常流量打爆。磁盘心跳通过 voting disk表决盘实现。每个节点持续向表决盘写入并读取心跳信息。这里要强调磁盘心跳不是为了检测存储是否损坏而是用于在网络心跳异常时做仲裁——判断集群里还剩哪些节点可以安全继续工作防止出现两个“小集群”同时操作共享数据的情况也就是脑裂防护。仲裁的核心思路是多数派。voting disk 一般配置为奇数个比如 3 个或 5 个存活的一方必须能访问大多数表决盘才有资格继续运行。换成生活场景就是公司里出了严重分歧股东们投票票多的一方留下票少的一方被请出去投出去的票就相当于表决盘上的记录。所以 RAC 安装完成后voting disk 的数量、路径和冗余状态一直是我重点检查的项它一旦出问题修复成本比数据库 crash 还高。2. CSS日常监控命令、进程和日志2.1 状态检查三板斧进程、服务、表决盘我每次登录集群节点看 CSS 健康状态基本固定三招查进程、查服务、查表决盘。第一招确认相关进程都在。11.2 以后的版本CSS 不再只有一个ocssd.bin还有两个配套的守护进程cssdagent和cssdmonitor它们负责监控 ocssd 是否活着、要不要触发重启这个机制从 OCFS 时代的 watchdog 一路演化过来目的是防止 CSS 进程意外挂掉却没人管。执行ps -ef | grep cssd正常情况下应该能看到以下几类进程而不是孤零零一个 ocssd。第二招用crsctl check css看服务状态。这是最直接的方式命令返回结果大致是这样$ crsctl check css CRS-4529: Cluster Synchronization Services are online如果 CSS 有问题会返回 offline 或者 communication failure 之类的提示具体报错编号因版本而异。想看得更细可以用crsctl stat res -t -init | grep cssd把ora.cssd这组资源的整体状态拉出来能看到它是不是处于 ONLINE、是否被某个节点 block、以及依赖资源的状态。连crsctl check cluster一起看可以确认 CRS、CSS、EVM 三件套是否全部在线。第三招查表决盘。crsctl query css votedisk这个命令用来确认 voting disk 的在线情况输出大概是这样的格式## STATE File Universal Id File Name Disk group -- ----- ----------------- --------- ---------- 1. ONLINE 5af12f34... /dev/sdb1 (VOTEDSK) Located 1 voting disk(s).如果你的表决盘放在 ASM 磁盘组里File Name 那一列会显示成DATA这种磁盘组名。重点看 STATE 是不是 ONLINE只要出现 OFFLINE不管数据库当前跑得多欢都是个定时炸弹得尽快恢复或者剔除。2.2 日志阅读的几个实用套路CSS 的日志路径不复杂默认在$GRID_HOME/log/节点名/cssd/目录下最主要的是ocssd.log另外还有cssdagent.log和cssdmonitor.log。遇到问题先翻这三个文件比什么工具都靠谱。日志格式不同版本略有差异但大体能看懂2025-01-04 12:00:00.000: [CSSD][12345] node 1 (node1) is considered alive 2025-01-04 12:00:05.000: [CSSD][12345] node 2 (node2) missed 10 network heartbeats 2025-01-04 12:00:20.000: [CSSD][12345] reconfiguration started 2025-01-04 12:00:22.000: [CSSD][12345] reconfiguration completed, node 2 evicted这些关键字非常值得关注。出现reconfiguration说明集群在做成员关系重组如果频繁出现肯定是网络不稳定或者节点在反复进组出现missed ... heartbeats是网络心跳丢失的计数提示出现evict那就已经是驱逐动作了。平时监控就可以盯这几个词。日志默认级别一般够用但遇到疑难问题可以打开调试日志。命令是crsctl debug log cssd CSSD,2数字越大越详细生产系统上临时开个 2 或者 3 就够了不要开到很高否则日志量爆炸。排查完记得调回默认级别crsctl debug log cssd CSSD,0注意这个命令在部分版本上组件名可能是ocssd而不是cssd不同大版本有差异建议先crsctl debug log cssd CSSD,2试一下报错就换ocssd试。日志调整后重点关注的是生成文件大小和写入速度方便判断问题窗口能覆盖多久。3. CSS故障场景从症状到处置3.1 高频故障速查表CSS 相关的故障我在生产环境里遇到最多的是下面这几类。先说结论再讲过程。症状可能原因优先检查项处理思路ocssd 进程反复重启或无法启动voting disk 不可用、权限错误、主机环境异常crsctl query css votedisk、cssdagent.log先恢复表决盘访问再启动集群节点被自动重启网络心跳超时触发驱逐ocssd.log里的 missout/evict 记录检查私网链路、交换机配置、网卡错误计数crsctl check css返回异常ocssd 未正常启动进程列表、/var/log/messages按启动顺序拉起 CRS必要时重启 CSS日志里频繁出现 reconfiguration私网闪断、网卡主备切换、交换机 STP私网链路质量、网卡绑定配置稳定私网确认 HAIP 状态必要时调优voting disk 显示 OFFLINE存储链路故障、磁盘组被误删crsctl query css votedisk恢复存储路径重新添加表决盘每种情况展开都是一段故事但最快定位的入口永远是日志和表决盘状态。很多运维同学遇到节点重启第一反应去看数据库告警其实数据库层面的报错往往是结果不是原因。CSS 相关故障先看 CSS 自己的记录再看系统日志。3.2 一个脑裂案例的复盘说一个我实际处理过的案例。两节点 RAC某天半夜机房做网络设备变更私网交换机闪断了大约 40 秒。当天刚好有大批量数据同步在跑私网流量本来就高心跳包被延迟得厉害。40 秒已经超过默认 misscount 30 秒的容忍窗口CSS 判定节点 2 失联直接把节点 2 重启驱逐了。现场的现象是节点 2 的 CRS 资源全部 offline数据库实例随之关闭应用侧大量ORA-12545、IPC Send timeout报错。排查过程并不复杂顺序是先登录存活的节点 1跑crsctl check cluster看到 CRS 正常但 css 日志里有一堆 missed heartbeats明确指向节点 2。翻ocssd.log确认事件时间线先是私网收发延迟接着 misscount 到期最后 reconfiguration 完成节点 2 被驱逐。检查节点 2 的系统日志看到内核触发了重启动作确认是 CSS 驱动驱逐而不是硬件故障。网络恢复后节点 2 重新启动CRS 自动拉起 ASM 和数据库实例集群状态恢复。复盘的时候发现三个值得反思的点。第一私网只有单交换机单链路如果当时能配置双网卡绑定或者至少两条独立链路这个故障大概率可以避免。第二心跳流量和业务流量混在同一张私网里大流量同步任务会严重挤占心跳带宽。第三最初有人提议把 misscount 调大到 60 秒理由是给网络切换留时间这个想法看着合理但代价是脑裂窗口扩大如果节点真的失联应用等 60 秒才被释放体验更差而且仲裁期间的不确定性更高。所以后来我们做了两件事私网改用双链路绑定并且把集群内部流量和备份同步流量做了分离监控系统增加对ocssd.log关键字evict和reconfiguration的实时告警心跳一异常先报警不用等节点被重启再被动响应。3.3 表决盘故障与“清除不用的磁盘组”“oracle rac crs 清除不用的磁盘组”这个操作也和 CSS 直接相关因为表决盘很可能就住在某个 ASM 磁盘组里。如果你想把某个 ASM 磁盘组下线或删除但里面寄存着 voting disk直接DROP DISKGROUP是行不通的要么被拒绝要么删完之后集群下次启动找不到表决盘整集群起不来这是非常经典的翻车场景。正确的流程应该是这样的先看现状crsctl query css votedisk确认目标磁盘组里有没有表决盘。如果有把表决盘迁移出去或者新加一个表决盘例如crsctl add css votedisk NEW_GRP然后crsctl delete css votedisk OLD_GRP确保最终表决盘数量仍然是奇数个。再确认 OCR 不在目标磁盘组上ocrcheck看输出ocrconfig -showbackup看备份位置。之后才轮到 ASM 侧DROP DISKGROUP OLD_GRP INCLUDING CONTENTS。整个过程最关键的就是第一步。很多人习惯性认为“磁盘组删不掉肯定是 ASM 的问题”回头查了一圈才发现是 CSS 里面还挂着表决盘的引用。另外提醒一点表决盘尽量保持奇数个2 个和 4 个的配置都容易让仲裁出现平票的尴尬局面生产中我见到的主流配置是 3 个兼顾冗余和仲裁效率。4. 维护操作中的CSS注意事项4.1 停机顺序和启动顺序到底有多讲究维护窗口绕不开的一个问题怎么停集群才安全。顺序错误轻则资源状态混乱重则 OCR 记录异常。正常顺序是先把应用停掉然后停数据库实例再停 ASM 实例最后停 Clusterware。停 Clusterware 有两种常用方式。单节点维护在当前节点执行crsctl stop crs只停本机。整集群维护在任意一个节点执行crsctl stop cluster -all它会依次把所有节点上的 CRS 都停掉。这里有个重要原则能正常停就不要加-f。-f是强制停止会跳过部分优雅关闭动作数据库实例和资源可能来不及干净下线重启之后要做恢复的概率会大很多。启动的先后逻辑是反过来先crsctl start crs或者crsctl start cluster -all让 CSS 在线CRS 再接管资源最后依赖 CRS 拉起 ASM 和数据库。CSS 是最底层的依赖它没起来之前其它资源基本都在等待状态。特别说一下千万别为了“图快”直接kill -9掉 ocssd 进程。CSS 被异常杀死后cssdmonitor 会立刻介入很可能触发节点重启机制等于亲手把自己的节点赶出集群。我见过有新手在排障时对着进程列表把 ocssd 杀了结果节点当场重启这属于典型的“设计时防脑裂”机制在工作。4.2 CSS核心参数能不动就不动CSS 相关的参数里出镜率最高的是 misscount、disktimeout还有 reboottime 这类超时参数。Oracle 的默认值是在大多数硬件和网络环境下验证过的结果日常运维我强烈建议保持默认。misscount 默认 30 秒表示网络心跳连续丢失达到这个时长就触发驱逐。有人觉得 30 秒太短想调成 60 秒给网络切换留时间这个想法我刚才说过听着合理实际是把风险转移到应用侧。调大 misscount 意味着节点真正失联后集群要多等 30 秒才做仲裁数据库会话在此期间全部挂起和存储相关的锁也会受影响业务端感受到的“卡死”时间更长。disktimeout 同样不建议乱动它是磁盘心跳的超时阈值。如果存储侧本身有切换机制比如多路径软件做链路切换只要切换时间在可接受范围内一定要确保切换期间磁盘心跳不超时否则存储还在切CSS 已经把节点踢了。真遇到必须调整的场景比如硬件固件问题导致网络中断时间超过默认阈值、短期无法升级硬件调整前要做完整的变更方案记录原来的值通过crsctl set css misscount 60这种命令修改并且知道部分参数在修改后可能需要重启 CRS 才能完全生效。变更窗口内观察对象不只是节点状态还有 ocssd.log 里是否出现新的 reconfiguration一旦异常立即回退。4.3 时间同步和虚拟化环境是CSS的暗坑CSS 对时间一致性非常敏感。集群里节点之间时间差过大心跳判断和锁管理都会出问题。节点时间跳变常见于虚拟化环境做了快照恢复或宿主机负载异常表现在 CSS 上就是节点突然被判定失联。所以 RAC 环境一定要把 NTP 或 chrony 时间同步配置好并且监控时间偏移不要只依赖系统默认的时间同步策略。虚拟化环境还有一个容易被忽略的问题CPU steal 和磁盘 I/O 延迟。当宿主机资源紧张虚拟机里的 CSS 进程调度被延迟磁盘心跳写入也可能变慢就会造成“节点还活着但心跳迟到了”的假象进而触发驱逐。云上自建 RAC 或者虚拟化环境跑 RAC尤其要注意给足 CPU 资源不要超卖太狠存储也要选延迟稳定的类型。另外防火墙规则也可能影响 CSS。私网之间的通信走特定端口如果防火墙策略过滤了心跳流量节点间通信会被静默丢包现象同样是心跳超时。这类问题最坑的地方在于网络看起来“通”Ping 也能通但 UDP 心跳包被丢了排查时一定要关注私网端口的连通性而不能只看 ICMP。最后说点个人体会。我接手 RAC 维护这些年遇到过不少“莫名其妙”的集群问题十有八九追到最后都落在 CSS 上。所以我现在做任何集群层面的变更前都会先看一眼三个东西crsctl check css是否在线、votedisk 有没有 OFFLINE、ocssd.log里最近有没有 reconfiguration 字样。这比事后翻半天日志高效得多。另外提醒一句CSS 相关的参数能不改尽量不改默认值就是 Oracle 在新硬件和新版本下权衡过的结果。如果你非改不可一定要先做变更评审并且准备好回退步骤——在这上面翻车的案例我见过太多了。