最干净的验证方式是用 sentinel get-master-addr-by-name 手动查主节点地址，不依赖客户端逻辑，只看哨兵当前认定的主节点；需绕开客户端缓存和哨兵响应延迟，主动 kill 主节点后等 10 秒再查，确认故障转移及旧主降级为从节点。
能直接测，但必须绕开客户端缓存和哨兵响应延迟这两个坑。
用 sentinel get-master-addr-by-name 手动查主节点地址
这是最干净的验证方式，不依赖任何客户端逻辑，只看哨兵当前认定的主节点是谁。
- 连任意一个哨兵节点（比如
redis-cli -p 26379），执行：sentinel get-master-addr-by-name mymaster
- 返回类似
127.0.0.1和6379就说明当前主节点是 6379；故障转移后应变成6380或6381 - 注意：这个命令返回的是“哨兵视角下的主节点”，不是 Redis 实例自己报的 role。它可能滞后几秒，别一查没变就认为失败
主动 kill 主节点进程后等待 5–10 秒再查
主观下线（SDOWN）默认超时是 down-after-milliseconds（通常设为 5000），客观下线（ODOWN）和选举还需要额外时间。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先确认配置里
sentinel monitor mymaster 127.0.0.1 6379 2的 quorum 是 2（即至少 2 个哨兵同意才触发） - 执行
kill -9 $(pgrep -f "redis-server.*6379")干掉主节点 - 等满 10 秒再运行
sentinel get-master-addr-by-name，避免查到中间态 - 如果返回新端口，再用
redis-cli -p 新端口 info replication确认它的 role 确实是master
Java 客户端用 JedisSentinelPool 时别漏掉重试逻辑
很多测试代码在故障转移期间抛 JedisConnectionException 就直接退出了，其实连接池本身会自动刷新主节点，但需要你容忍短暂失败。
- 示例中那个无限循环写入的测试，
sentinelPool.getResource()在故障转移中可能连续几次失败，这是正常现象 - 关键不是“是否报错”，而是错误持续多久后恢复——一般 5–15 秒内应恢复正常写入
- 不要在 catch 块里加
System.exit(1)，否则测不到自动恢复效果 - 可以加个计数器，记录连续失败次数，超过 20 次再报警，而不是第一次就中断
故障转移后旧主节点重启，会自动降级为从节点
这是容易被忽略的闭环验证点：很多人只测“主挂了谁顶上”，却没验证“老主回来后会不会抢主”。
- 等新主稳定运行后，重启原主节点（如
redis-server redis-7000.conf） - 过几秒连上去执行
info replication，role 应该是slave，且master_host指向新主 - 如果它还是
master，说明配置里漏了replicaof或哨兵没成功下发配置，得检查sentinel failover-timeout是否太短
真正卡住的地方往往不是“切不切换”，而是“切完客户端连不上”或“旧主重启后状态混乱”。盯住 sentinel get-master-addr-by-name 输出和各节点的 info replication，比看日志更直接。
