故障转移性能测试关键在于精准复现切换瞬间压力冲击，聚焦故障后前10秒（尤以第3–8秒峰值为准），通过毫秒级延迟发压、脉冲式连接风暴、叠加日常负载与干扰事务，并验证业务语义一致性及数据同步完整性。
故障转移性能测试的关键，不是单纯制造节点宕机，而是精准复现切换瞬间对剩余节点产生的真实压力冲击——包括连接重连洪峰、流量陡增、状态同步开销和资源争抢。重点在于让被测系统在“刚接管”那一秒就暴露瓶颈。
压测要聚焦“切换后前10秒”
主节点故障后，客户端通常会在 1–5 秒内感知失败并发起重连；新主节点在完成选举、加载元数据、恢复事务状态后，才开始承接请求。真正的压力峰值往往出现在第 3–8 秒：大量连接涌入、缓存未热、连接池重建、SQL 执行计划未优化。因此，压测脚本必须能精确控制在故障触发后的固定时间窗（如第5秒）开始发压，而非等集群“完全就绪”后再启动。
- 用 JMeter 的 JSR223 Timer 或 Gatling 的 pause() 实现毫秒级延迟启动
- 避免使用“等待服务健康检查通过”这类宽松条件，它会掩盖瞬时抖动
- 监控指标需采样粒度 ≤ 1 秒，重点关注 CPU 就绪队列、连接建立耗时、首字节响应时间（TTFB）
构造真实重连行为，而非静态并发用户
真实故障转移中，并发不是均匀到达的，而是呈脉冲式爆发：客户端 SDK 自动重试 + 负载均衡器探测失败 + 应用层连接池重建，三者叠加形成“连接风暴”。静态设置 1000 并发用户无法模拟这种模式。
- 用 连接数突增 + 短生命周期 模拟：例如每秒新建 200 个连接，每个连接只执行 1 次查询即断开
- 在客户端启用 指数退避重试（如初始 100ms，上限 2s），更贴近 Spring Cloud LoadBalancer 或 PgBouncer 行为
- 禁用连接池预热或最大空闲连接限制，强制每次请求都新建连接
注入配套负载，防止“虚假达标”
只测切换瞬间的写入压力是片面的。实际生产中，故障转移常与业务高峰叠加——比如支付主库宕机恰逢晚八点下单峰值。若压测仅关注切换本身，可能漏掉资源竞争引发的连锁反应。
- 在触发故障前，先让集群承载 60%–70% 的日常稳定负载（如持续 5 分钟 TPS=500）
- 故障转移动作发生后，立即叠加瞬时读写混合压力（如 300 写 + 700 读/秒）
- 特别加入长事务（如 UPDATE 大表 WHERE 无索引条件）作为“干扰项”，观察是否引发锁等待雪崩
验证成功不能只看“不报错”
系统返回 HTTP 200 或数据库 execute 成功，不代表故障转移性能合格。真正需要验证的是业务语义层面的可用性与一致性。
- 检查切换后 30 秒内，是否有 重复写入（如订单号重复生成）、丢失写入（如消息未落库）、脏读（从旧主残留连接读到已回滚数据）
- 比对主从/新老主节点的 WAL 位点、binlog file & position、或 Patroni 的 xlog_location，确认数据同步无跳变
- 记录并分析 最大单次响应延迟 和 99分位延迟突增幅度，而非仅看平均值
