必须用 sentinel set 命令实时修改 quorum 才生效，因 redis sentinel 启动后仅加载一次 sentinel.conf，运行时不重读该配置，且不支持 config rewrite 或 sighup 重载。
不能只改配置文件，必须用 SENTINEL SET 命令实时生效，否则修改无效。
为什么改了 sentinel.conf 里的 quorum 却不生效
哨兵进程启动后，quorum 值会从配置文件加载一次，但后续运行中它只认内存里的值。即使你编辑了 sentinel.conf 并重载 systemd 或发 SIGHUP，Redis Sentinel 默认不会重新解析该文件里的 quorum 配置——这是和普通 Redis server 的关键区别。
常见误操作是改完配置就以为万事大吉，结果主节点宕机时发现日志里只有 +sdown master mymaster，始终没有 +odown，故障转移卡死。
- 哨兵不支持通过
CONFIG REWRITE持久化运行时修改 - 修改
sentinel.conf后不重启进程，新值完全不加载 - 重启进程虽能读取新配置，但在容器或 systemd 管理场景下容易漏掉滚动重启顺序，导致部分哨兵用旧值、部分用新值，引发投票分裂
正确做法：用 SENTINEL SET 实时修改并验证
所有哨兵节点必须逐个执行命令，且需确保目标主节点名（如 mymaster）拼写完全一致。命令格式为：
redis-cli -p 26379 SENTINEL SET mymaster quorum 2
执行后不会返回任何输出，需立即验证是否生效：
- 查当前配置：
redis-cli -p 26379 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster（不直接显示 quorum，仅确认连接正常） - 查哨兵对主节点的内部状态：
redis-cli -p 26379 SENTINEL MASTER mymaster | grep quorum，输出类似quorum:2 - 确认其他哨兵是否同步看到该主节点：
redis-cli -p 26379 SENTINEL SENTINELS mymaster，检查列表长度是否等于你部署的哨兵总数
quorum 修改前必须核对的三个前提
动态调高 quorum 是安全的，但若设得过大或与实际在线节点数冲突，会直接导致无法触发故障转移。务必在执行 SENTINEL SET 前确认：
- 当前在线哨兵数 ≥ 新
quorum值（用redis-cli -p 26379 sentinel masters查num-sentinels字段） - 新
quorum值符合多数派原则：推荐设为⌊N/2⌋ + 1，其中 N 是你期望参与投票的哨兵总数（例如 3 个哨兵 → 设为 2；5 个 → 设为 3） - 所有哨兵与主节点网络可达，且
down-after-milliseconds参数未被意外调得过短（否则可能因瞬时抖动提前触发 sdown）
真正容易被忽略的是：修改完一个哨兵后，必须立刻验证它的 quorum 是否已更新，而不是等所有哨兵都改完再统一查——因为哨兵之间不自动同步这个参数，每个节点都是独立判断的。一旦某个节点没改成功，它在投票时就会按旧值参与，破坏多数派一致性。
