Oracle物理备库进行Failover后如何避免原主库发生脑裂？

脑裂的根本原因在于Failover后原主库未能及时隔离，必须对原主库执行强制关闭与网络隔离，严禁其进入MOUNT状态。在跨中心场景下，还需停止多路径服务并卸载ASM磁盘组，否则风险难以消除。

Failover后原主库未隔离是脑裂主因

Failover并非简单的单向切换——它本质上是一个两端状态同步的重置过程。如果原主库没有被强制下线或网络隔离，它仍会以“primary”身份持续接收写入请求。此时新主库同样提供写入服务，共享数据被两套独立的事务同时修改，块级冲突与逻辑损坏几乎不可避免。这并非配置问题，而是角色状态未同步导致的系统性故障。

必须执行原主库的强制关闭与网络隔离

Failover命令（如ALTER DATABASE FAILOVER TO standby）仅影响备库端，原主库仍处于OPEN状态，监听器照常运行。此时必须人工果断介入：

• 立即在原主库执行SHUTDOWN ABORT，切勿使用SHUTDOWN IMMEDIATE——后者会等待事务提交，相当于给写入留出窗口期
• 拔掉原主库的业务网卡，或在交换机侧直接禁用业务端口，切断所有应用连接路径
• 确认lsnrctl status已无监听器运行，ps -ef | grep pmon也查不到Oracle进程残留
• 检查/etc/hosts和tnsnames.ora，确保没有其他节点还能解析到该实例

重建前严禁启动原主库到MOUNT或OPEN状态

许多DBA在重建时习惯先执行STARTUP MOUNT再运行RMAN恢复——这个操作其实非常危险。只要原主库进入MOUNT状态，CSSD或Clusterware就可能尝试挂载OCR/Voting Disk，从而引发集群资源争抢。尤其当它仍连接共享存储时，IO Fencing失败或仲裁盘写冲突的概率会显著上升。

正确的做法是：

• 保持原主库完全关机（物理断电或shutdown -h now更为稳妥）
• 仅在RMAN恢复阶段才启动到NOMOUNT，并且必须指定DB_NAME与新主库一致
• 恢复完成后执行ALTER DATABASE CONVERT TO PHYSICAL STANDBY之前，务必确认新主库已启用LOG_ARCHIVE_DEST_n指向该节点

跨中心场景下第三投票盘延迟会放大风险

在同城双活架构中，如果原主库所在站点未彻底断电，仅做了网络隔离，其CSSD进程仍可能尝试访问远端的第三投票盘（例如NFS上的+ASM/voting_disk）。当网络延迟超过27秒（短磁盘超时）时，该节点会被驱逐；但若延迟在14到27秒之间震荡，CSSD就会反复重试写入，导致心跳状态抖动，误判概率大幅增加。

这种场景下，仅执行crsctl stop crs是不够的。必须同步停掉底层的存储多路径服务（例如systemctl stop multipathd），并卸载ASM磁盘组，彻底切断对共享存储的所有访问能力。