怎样设计Oracle RAC生产环境故障演练

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对应磁盘）。这三类分别触发集群不同层级的响应机制：前者测试实例级自动重启，后者直击脑裂防护底线。

演练前必须确认的四个检查点

跳过这些检查，演练可能变成事故：

1. OCR 和 Voting Disk 有最新备份（用 ocrconfig -showbackup 和 crsctl query css votedisk 验证）
2. 所有节点 crsctl check cluster -all 返回 CRS-4537: Cluster Ready Services is online
3. 应用连接串启用 TAF（tnsnames.ora 中含 (FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETRIES=180)(DELAY=5))）
4. 监控脚本已部署：持续轮询 select instance_name, status from gv$instance 和 crsctl stat res -t

私网中断后观察什么才说明RAC没脑裂

拔掉 private 网线后，不能只看“服务还在”，要盯住三个关键信号：

1. 存活节点上执行 crsctl stat res -t | grep "STATE"，应显示 ONLINE 且无 OFFLINE 或 UNKNOWN 状态资源
2. 查看 /var/log/oracle/crsd/crsd.log，确认出现 CRS-1603: Node <name> is evicted 而非 CRS-1656: Node <name> is partitioned（后者是脑裂征兆）
3. 用 olsnodes -s -t 检查集群成员表，输出应只剩一个节点名，且时间戳更新正常

如果看到两个节点都声称自己是“唯一合法成员”，说明 Voting Disk 冗余不足或心跳路径未隔离，必须立刻整改。

演练后必须回滚的配置变更

很多DBA忘了收尾，导致下次升级失败：

1. 临时修改的 /etc/hosts（如为测试加的 fake VIP）必须删除
2. 用 crsctl stop crs 停过的节点，需用 crsctl start crs 启动，并等 crsctl check cluster 稳定返回 ONLINE
3. 若曾手动 chown 或 chmod 过 ASM 磁盘设备，必须恢复原始属主：chown grid:asmadmin /dev/oracleasm/disks/*
4. 检查 srvctl config database -d <db_name> 输出，确认所有实例状态与实际一致，避免残留 offline 实例注册项

最常被忽略的是 Voting Disk 权限——演练中模拟不可写时改过权限，回滚不彻底会导致下次集群启动失败，且错误日志里只报“CSSD cannot start”，根本看不出是权限问题。