故障转移时间需分层测量：检测延迟、决策延迟、执行延迟和业务恢复时间（RTO），并采用可控故障注入、多源日志监控与时间戳记录，同时规避心跳超时、fencing未完成、健康检查拖慢及应用冷启动等误差陷阱。
测试故障转移时间，关键在于精准模拟真实故障、精确测量切换全过程，并排除干扰因素。不能只看VIP漂移完成，而要覆盖从故障发生到服务恢复可用的完整链路。
明确测试范围与测量起点终点
故障转移时间不是单一指标，需按层级定义：
-
检测延迟：从节点实际宕机（如 kill -9 进程）到集群管理器（如 Pacemaker/Corosync）标记该节点为
offline的耗时 - 决策延迟：集群仲裁完成、确认可执行切换的时间（含脑裂防护检查、fencing 执行）
- 执行延迟：VIP 漂移、存储挂载、服务启动、端口监听就绪的总耗时
- 业务恢复时间（RTO）：客户端首次成功发起请求并收到有效响应的时间（最贴近业务感知）
使用可控故障注入方法
避免依赖“自然故障”，采用可重复、可定时的注入方式：
- 对 Keepalived：用
systemctl stop keepalived或kill -USR2触发主节点退出，比直接关机更干净 - 对 Pacemaker 集群：运行
pcs cluster stop --all或pcs resource disable <resource>模拟服务崩溃 - 对数据库（如 MySQL+MHA）：手动 kill mysqld 进程，或关闭网络接口
ip link set eth0 down - 记录精确时间戳：在触发前执行
date +%s.%N，在客户端验证成功后再次执行，差值即为 RTO
监控与日志协同验证
单靠人工计时易出错，应结合多源数据交叉确认：
- 查 Corosync 日志：
grep "state transition" /var/log/cluster/corosync.log，定位状态变更时刻 - 查 Pacemaker 执行日志：
grep "transition" /var/log/pacemaker.log，确认资源迁移步骤耗时 - 抓包验证 VIP 切换：
tcpdump -i any host <VIP>，观察 ARP 广播和 TCP SYN 是否在备节点发出 - 用 curl 或 telnet 轮询服务端口：
while ! curl -sf http://VIP:80/health; do sleep 0.1; done; date
规避常见误差陷阱
很多实测结果偏大，往往源于未控制变量：
- 心跳超时参数未调优：默认
token3秒在云环境易误判，建议设为 5–8 秒并同步调整fail_timeout - 未等待 fencing 完成：强制关机类操作若未返回成功，后续资源不会启动，需检查 fence_xvm 或云厂商 API 调用日志
- 健康检查脚本拖慢流程：Keepalived 的
check script若含远程调用或重试逻辑，会显著延长检测周期，应简化为本地快速判断 - 忽略应用层冷启动：Java 应用重启可能需 5–10 秒加载类，这部分属于 RTO 组成，但不属于基础设施切换时间，需分开统计
