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 在新硬件和新版本下权衡过的结果。如果你非改不可，一定要先做变更评审，并且准备好回退步骤——在这上面翻车的案例，我见过太多了。
