FSFO Observer误判脑裂的典型现象是主库在线、SQL可执行、监听正常，但备库被强制接管，根本原因是Observer存活判定过度依赖心跳响应时间，未区分网络抖动或I/O延迟等瞬态异常，需调优misscount、NET_TIMEOUT、REOPEN参数并确保Observer独立部署与进程守护。
FSFO Observer 误判脑裂的典型现象
主库明明在线、SQL 可执行、监听正常，但备库突然接管，observer.log 里却写着 “Primary database is not responding”，紧接着主库实例被强制 shutdown —— 这不是真宕机，是 FSFO 的误杀。根本原因在于 Observer 对主库“存活”的判定逻辑过于依赖心跳包响应时间，而没区分网络抖动、CSSD 调度延迟或 voting disk I/O 卡顿这类瞬态异常。
关键参数必须调优：misscount 和 NetworkTimeout
默认 misscount=30（单位秒）在高负载下极脆弱。CPU 调度延迟 + swap + voting disk 延迟只要叠加超 30 秒，Observer 就会发 member kill。必须同步调整两个地方：
-
crsctl get css misscount查当前值；若为 30，用crsctl set css misscount 45提升容错窗口（需双节点同时执行，且重启 CSSD） -
log_archive_dest_2中的NET_TIMEOUT=30必须 ≥misscount，否则主库先降级为最高性能模式，Observer 更容易失联 - 别只改
NET_TIMEOUT：同步检查REOPEN=300是否过小，频繁重连会加重网络压力
Observer 自身稳定性比配置更重要
Observer 进程一旦挂掉或卡住，FSFO 就退化成手动 Failover。它不是后台服务，没有 systemd 管理，必须用 nohup dgmgrl / "START OBSERVER" & 启动，并加守护脚本：
- 每 5 分钟用
ps -ef | grep observer检查进程是否存在 - 用
tail -n 20 observer.log | grep -i "lost connection\|timeout"抓早期预警信号 - 绝对不要把 Observer 跑在主库或备库服务器上——它们出问题时 Observer 很可能一起死
拔网线测试前必须验证三件事
模拟故障前不验证，等于拿生产环境练手：
- 确认
crsctl query css votedisk输出全是/dev/mapper/xxx，不是/dev/sdb1或+OCR；否则多路径失效时投票盘不可见，直接触发脑裂 - 运行
mpathconf --show，确保active paths≥2；拔一根光纤后，该值必须实时下降，否则 multipathd 未生效，Observer 会误判链路完好 - 在主库执行
top -p $(pgrep ocssd)，观察%CPU是否持续 TIME+ 每秒增长是否
真正危险的从来不是配置写错，而是把 misscount 调大后就以为万事大吉——如果 ocssd 进程本身因 swap 或 CPU 饥饿无法及时回包，再长的 timeout 也救不了。
