linux高可用集群可靠性的核心是及时故障检测、干净资源切换和杜绝脑裂；常见corosync启动失败因配置校验不通过或通信不通，需检查bindnetaddr、时间同步、防火墙端口；资源unmanaged需手动恢复管控，failed多因启动脚本错误；两节点必须配置qdevice防脑裂；亚健康状态下的决策鲁棒性才是最大挑战。
Linux 高可用集群不是装几个软件就能跑起来的，核心在于故障检测是否及时、资源切换是否干净、脑裂是否被杜绝——这三件事没理清，服务反而比单机更不可靠。
pacemaker + corosync 启动失败，日志里反复出现 corosync[xxxx]: [MAIN ] Corosync Cluster Engine exited with status 8
这是最常见的“启动即退出”问题，根本原因通常是 corosync 配置未通过校验或底层通信不通。pacemaker 依赖 corosync 正常运行，它一挂，整个集群就停摆。
- 先检查
/etc/corosync/corosync.conf是否能被corosync-cfgtool -s解析成功；常见错误是totem.interface.bindnetaddr写成了具体 IP 而非网段（比如填192.168.1.10而不是192.168.1.0） - 确认所有节点时间同步：
chronyc tracking输出的 offset 应小于 50ms，否则 corosync 拒绝加入集群 - 防火墙必须放行
udp/5404-5405（corosync 默认端口），用ss -uln | grep ':540'验证端口是否真在监听
crm configure 命令添加资源后，pcs status 显示 unmanaged 或 failed
资源状态异常不等于配置写错了，而是 pacemaker 尚未尝试启动它，或启动后立刻崩溃。关键看 pcs resource debug-start <resource-id></resource-id> 的实时输出。
-
unmanaged表示该资源被手动禁用（pcs resource unmanage <id></id>），需执行pcs resource manage <id></id>恢复自动管控 -
failed多因启动脚本返回非零码，比如systemd类资源依赖的 service 文件不存在，或ocf:heartbeat:IPaddr2的ip参数格式错误（应为192.168.1.100/24，不能漏掉掩码） - 避免直接改
crm configure的 raw 文本，用pcs resource update <id> param=value</id>更安全，否则语法错会导致整个 CIB 提交失败
两个节点都声称自己是 master，VIP 在两边同时响应（脑裂）
这不是配置遗漏，而是仲裁机制失效的典型表现。corosync 默认只做通信心跳，不判断“谁该活”，必须显式配置 qdevice 或至少一个 quorum device。
- 两节点集群必须启用
qdevice（如基于 qnetd 的仲裁服务器），否则默认two_node: 1实际上是危险模式：只要网络抖动，两边都会认为对方失联而抢资源 - 检查
pcs quorum status，若显示Quorum: No，说明当前没有法定票数，所有资源会被强制停止 - 不要用 ping 节点作为仲裁手段（
ocf:pacemaker:ping），它无法区分网络分区和真实宕机，极易引发误切
真正难的不是加机器、配资源，是让集群在丢包、时钟漂移、磁盘卡顿这些“亚健康”状态下依然拒绝错误决策。很多线上事故，都发生在 corosync 心跳延迟刚超阈值但还没断连的那几秒里——那里没日志，也没告警，只有沉默的 VIP 漂移。
