linux服务集群主从自动切换依赖心跳探测、故障判定、资源接管三类协同机制：心跳需双向检测且参数适配网络环境；故障判定须引入仲裁防脑裂；资源接管要求原子性、 fencing隔离及配置同步；典型组合包括keepalived、pacemaker+corosync、redis sentinel等。
Linux服务集群实现主从节点自动切换，核心是让备用节点在主节点失效时，能快速、可靠地接管服务资源（如IP、端口、数据路径、应用进程等），整个过程无需人工干预。这依赖于三类协同机制：心跳探测、故障判定、资源接管。
心跳探测与状态同步
主备节点之间必须持续交换存活信号，这是自动切换的前提。常用方式包括：
- 使用专用心跳网络（如独立网卡直连）跑UDP心跳包，延迟低、干扰少
- 基于现有业务网走VRRP协议（Keepalived默认方式），轻量且兼容性好
- 通过集群通信层（如Corosync）建立多播/单播通道，同时承载状态同步与仲裁
关键不是“有没有心跳”，而是心跳参数要贴合实际环境：超时时间（deadtime）需大于网络抖动周期，但又不能过长；检测间隔（keepalive）建议设为1–2秒；启用双向检测（即主备互相ping），避免单向链路故障导致误切。
故障判定与防脑裂
单纯靠心跳丢失就切换，容易因网络分区引发“双主”。必须引入仲裁或多数派决策：
- Pacemaker + Corosync 集群要求法定票数（quorum），节点数为奇数或配qdevice仲裁设备
- Keepalived 可配合脚本检查本地服务状态（如
curl -f http://127.0.0.1:8080/health），只有心跳断+服务不可用才触发切换 - Redis Sentinel 采用投票机制，至少半数+1个哨兵达成一致才执行failover
不设仲裁的双节点集群，强烈建议部署独立的确认监视器（如DM集群的dmmonitor、Pacemaker的qnetd），避免网络闪断造成脑裂。
资源接管与服务恢复
切换动作本身要原子、可逆、幂等：
- VIP漂移：通过
ip addr add/del或Keepalived内置VRRP完成，确保客户端无感知重连 - 存储接管：若共享存储（如iSCSI/GFS2），需先 fencing（隔离原主节点，如SSH关机、IPMI断电），再激活文件系统或启动服务
- 应用服务拉起：Pacemaker通过resource agent（如systemd、LSB脚本）启停服务，并校验端口监听、进程存在、响应健康接口
- 配置同步：主节点故障前应已通过rsync、etcd或GitOps机制将配置推送到备节点，避免切换后配置陈旧
典型组合示例如下：
- Web服务：Keepalived（VIP + Nginx健康检查）
- 数据库服务：Pacemaker管理PostgreSQL资源 + Corosync通信 + STONITH fencing
- 缓存服务：Redis Sentinel三节点部署，自动选举新master并通知客户端
- 存储服务：Multipath（链路级） + Pacemaker（节点级） + LVM/GFS2（文件系统级）
切换完成后，还需考虑自动回切策略（auto_failback）是否开启——生产环境通常禁用，防止频繁震荡；仅当明确主节点已彻底修复且需人工确认后，才手动触发回切。
不复杂但容易忽略
