演练要的是数据
切换演练的目的不是看它能不能切，而是把切换耗时、客户端重连行为、从库重指向与数据差异量化下来。演练应在业务低峰进行，事前定好成功标准（切换耗时、写入失败量、恢复时间），事后留下时间线，否则演练只是制造了一次告警。
基本信息
| 演练方式 | 手动 SENTINEL FAILOVER、终止主库进程、阻塞主库主线程 |
|---|---|
| 观察点 | 哨兵日志、事件订阅、应用指标、客户端连接池 |
| 记录项 | 切换耗时、失败写量、数据差异、恢复步骤 |
| 前置条件 | 拓扑正常、从库延迟正常、配置已备份 |
演练步骤
- 事前：备份 sentinel.conf 与各实例配置文件，通知相关方进入维护窗口，确认法定票数可用
- 触发：在任意哨兵上执行 SENTINEL FAILOVER 主库名，或直接终止主库进程模拟真实宕机
- 观察：订阅 +sdown、+odown、+try-failover、+switch-master、+failover-end 并记录墙上时间
- 校验：应用侧确认写入恢复，核对新旧主的数据差异，确认其余从库已指向新主
- 收尾：原主以从库身份归队，核对配置与日志，更新演练记录与问题清单
演练示例
演练示例
redis-cli -p 26379 SENTINEL FAILOVER mymaster # 维护窗口内主动触发
redis-cli -p 26379 SENTINEL CKQUORUM mymaster # 切换前确认票数可达
kill -9 $(pgrep -f 'redis-server.*6379') # 或模拟主库进程崩溃
redis-cli -p 6379 DEBUG SLEEP 30 # 阻塞主库主线程，触发下线判定
grep -E 'sdown|odown|failover|switch-master' /var/log/redis/sentinel.log | tail -30
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster # 确认新主地址
redis-cli -p 26379 SENTINEL MASTERS | grep -E 'mymaster' # 核对哨兵视图演练检查项
| 检查项 | 目的 | 合格判定 |
|---|---|---|
| 下线判定耗时 | 从故障发生到客观下线的时间 | 与 down-after 及票数设置相符 |
| 切换总耗时 | 从客观下线到新主可写 | 满足业务恢复目标 |
| 客户端恢复 | 应用是否自动切到新主 | 连接池无长期半死连接 |
| 数据差异 | 未同步写的丢失量 | 在业务可接受范围内 |
| 从库重指向 | 其余从库是否指向新主 | 没有残留旧主地址 |
| 原主归队 | 恢复后是否被改为从库 | 无需人工干预，且无双主 |
Redis 7.0 起 DEBUG 属于受保护命令，需要在配置中显式开启才能使用。生产演练更接近真实的做法是直接停止实例进程，或切断哨兵到主库的网络路径。
用防火墙丢弃哨兵与主库之间的流量可以模拟网络分区，比杀进程更能暴露判定延迟与脑裂问题：分区期间主库可能继续接受写入，恢复后要检查这部分数据是否被新主覆盖。演练结束记得清理规则。
演练结束恢复原主时，应按从库身份启动或由哨兵重新配置，不要在两边都让实例自认为是主库，否则会形成双主并产生难以合并的分叉数据。