oracle rac故障演练必须覆盖节点硬关机、私网中断、voting disk不可写三类真实中断场景，分别测试实例重启、脑裂防护与仲裁机制，并需严格验证ocr/voting disk备份、crs状态、taf配置及监控部署。
故障演练必须覆盖这三类真实中断场景
Oracle RAC不是“装完就稳”，真正的高可用能力只在故障中验证。生产环境演练不能只停一个实例，必须模拟三类破坏性更强、更贴近真实故障的场景：节点硬关机（断电/kill -9 crsd）、私网中断（拔private网线或iptables封禁10.10.10.0/24）、Voting Disk不可写（umount ASM磁盘组或chown root对应磁盘）。这三类分别触发集群不同层级的响应机制：前者测试实例级自动重启，后者直击脑裂防护底线。
演练前必须确认的四个检查点
跳过这些检查，演练可能变成事故：
-
OCR和Voting Disk有最新备份（用ocrconfig -showbackup和crsctl query css votedisk验证） - 所有节点
crsctl check cluster -all返回CRS-4537: Cluster Ready Services is online - 应用连接串启用
TAF（tnsnames.ora 中含(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETRIES=180)(DELAY=5))） - 监控脚本已部署：持续轮询
select instance_name, status from gv$instance和crsctl stat res -t
私网中断后观察什么才说明RAC没脑裂
拔掉 private 网线后，不能只看“服务还在”，要盯住三个关键信号：
- 存活节点上执行
crsctl stat res -t | grep "STATE"，应显示ONLINE且无OFFLINE或UNKNOWN状态资源 - 查看
/var/log/oracle/crsd/crsd.log，确认出现CRS-1603: Node <name> is evicted</name>而非CRS-1656: Node <name> is partitioned</name>（后者是脑裂征兆） - 用
olsnodes -s -t检查集群成员表，输出应只剩一个节点名，且时间戳更新正常
如果看到两个节点都声称自己是“唯一合法成员”，说明 Voting Disk 冗余不足或心跳路径未隔离，必须立刻整改。
演练后必须回滚的配置变更
很多DBA忘了收尾，导致下次升级失败：
- 临时修改的
/etc/hosts（如为测试加的 fake VIP）必须删除 - 用
crsctl stop crs停过的节点，需用crsctl start crs启动，并等crsctl check cluster稳定返回 ONLINE - 若曾手动
chown或chmod过 ASM 磁盘设备，必须恢复原始属主：chown grid:asmadmin /dev/oracleasm/disks/* - 检查
srvctl config database -d <db_name></db_name>输出，确认所有实例状态与实际一致，避免残留 offline 实例注册项
最常被忽略的是 Voting Disk 权限——演练中模拟不可写时改过权限，回滚不彻底会导致下次集群启动失败，且错误日志里只报“CSSD cannot start”，根本看不出是权限问题。
