最稳的心跳检测工具是corosync + pacemaker组合：corosync负责底层多播/单播心跳通信，pacemaker负责资源管理与故障策略，需严格时间同步、正确绑定网卡、配置约束关系并排查应用层绑定地址等问题。
心跳检测用什么工具最稳？优先选 corosync + pacemaker
单靠自写脚本或 ping 检测做双机热备，几乎必然在脑裂（split-brain）时出问题。真实生产环境必须用专业集群栈：corosync 负责底层通信与心跳（支持多播/单播/UDP/TCP），pacemaker 负责资源管理与故障策略。别碰 heartbeat（已废弃多年），也别用 keepalived 做通用服务热备——它只适合 VIP + LVS/NGINX 这类有限场景。
常见错误现象：
- 两台机器都抢 VIP，业务中断且无法自动恢复
- 心跳延迟高时，pacemaker 误判节点死亡，触发无谓切换
- 配置了多网卡但没指定 bindnetaddr，corosync 绑错接口，心跳不通
- 确保两台机器时间严格同步（
chronyd或ntpd，误差 >1s 可能导致 corosync 拒绝加入集群） - 禁用防火墙或放行 corosync 默认端口：
5404/udp（多播）、5405/udp（单播）、2224/tcp（pacemakerd） - corosync.conf 中必须显式设置
bindnetaddr（如192.168.10.0）和ringnumber: 0，避免跨网段绑定失败
怎么让服务真正自动切换？关键在 primitive 和 colocation 约束
光把服务注册成资源还不够，不加约束的话，pacemaker 可能把它和 IP 地址分到不同节点上，结果 VIP 在 A 机、数据库在 B 机——服务根本连不上。必须用约束强制绑定关系。
使用场景举例：主从 PostgreSQL + VIP。
错误配置：pcs resource create pgsql systemd:postgresql-14 —— 这只是把服务加进集群，没定义依赖和位置规则。
- 先创建 VIP 资源：
pcs resource create vip ocf:heartbeat:IPaddr2 ip=192.168.10.100 cidr_netmask=24 nic=eth0 op monitor interval=30s - 再创建 PostgreSQL 资源：
pcs resource create pgsql systemd:postgresql-14 op monitor interval=60s - 强制 VIP 和 pgsql 必须在同一节点：
pcs constraint colocation add vip with pgsql INFINITY - 强制 pgsql 启动前 VIP 必须就绪：
pcs constraint order vip then pgsql - 禁止 pgsql 在同一节点重启超过 2 次/30 分钟（防反复崩溃打满日志）：
pcs resource meta pgsql failure-timeout=30s migration-threshold=2
pcs status 显示 OFFLINE 却没报错？查 corosync-quorumtool 和日志路径
集群状态看似正常，但资源一直起不来，pcs status 只显示 OFFLINE，没有具体错误码——这是典型“健康检查通过但资源启动失败”的表现，问题不在 corosync 通信层，而在 pacemaker 执行层。
排查顺序不能乱：
- 先看 quorum 是否成立：
corosync-quorumtool -s，输出中Quorate: Yes才算集群在线；若为No，说明节点数不足法定票数（默认 2 节点需配置two_node: 1） - 再查 pacemaker 日志：
journalctl -u pacemaker --since "1 hour ago" | grep -i "error\|warn"，重点关注资源代理（RA）返回的 exit code - 手动模拟资源启动：
pcs resource debug-start pgsql，会输出完整执行过程，暴露权限、路径、配置文件缺失等细节问题 - 确认资源代理是否可用：
crm_resource --list-agents ocf:heartbeat，确保IPaddr2和你的数据库 RA 已安装
切换后服务连不上？检查 iptables、SELinux 和应用绑定地址
故障切换成功，VIP 也飘过去了，但客户端连不上服务——十有八九是应用层没配合。这不是集群配置问题，而是服务自身行为没对齐。
常见错误现象：
- PostgreSQL 切换后监听 127.0.0.1，不响应 VIP 请求
- Nginx 启动后只 bind localhost:80，新 VIP 流量被丢弃
- SELinux 拦截了非标准端口或网络访问（尤其 CentOS/RHEL）
- PostgreSQL 必须设
listen_addresses = '*,127.0.0.1'（不是'localhost'），并确认pg_hba.conf允许来自 VIP 网段的连接 - Nginx 需明确
listen 192.168.10.100:80或listen *:80，避免仅监听127.0.0.1:80 - 临时关 SELinux 测试：
setenforce 0；若恢复访问，说明需加策略：ausearch -m avc -ts recent | audit2why - 检查 iptables：
iptables -L INPUT -n | grep REJECT，默认策略为 DROP 时，务必放行 VIP 所在网段和集群通信端口
双机热备最难的从来不是配通，而是让所有环节——从内核参数、网络栈、安全模块到应用配置——都接受“IP 和服务可能随时换机器”这个前提。漏掉任意一层，切换就会静默失败。
