能生效，但每行master-name必须全局唯一，重复则后配置静默覆盖前配置；quorum为per-master独立计算；auth-pass需按master-name单独配置且顺序须在monitor行之后。
sentinel monitor 多行配置是否生效？
能生效，但前提是每行的 master-name 必须全局唯一。Redis 哨兵启动时会逐行解析 sentinel.conf，遇到重复的 master-name 时，后加载的配置会直接覆盖前一个——不是报错，而是静默覆盖，导致前面那个集群彻底失去监控。
常见错误现象：redis-sentinel 启动后只看到一个 master 被识别，日志里也只输出一条 +monitor，其他 monitor 行完全没反应。
- 检查
sentinel.conf中所有sentinel monitor行的第三个字段（即master-name），确认无重复 - 命名建议带环境和业务标识，例如
prod-order-redis、staging-user-cache，避免用泛化名如mymaster复用 - 修改配置后必须重启哨兵进程，热重载不支持新增
monitor行
多个 master-name 共享一套哨兵时密码怎么配？
每个 master-name 必须单独配密码，用 sentinel auth-pass <master-name> <password>，不能靠全局配置或复用同一行。
如果漏配某一个 master-name 的密码，故障转移阶段哨兵尝试向新主节点发 CONFIG REWRITE 或 SLAVEOF 时会卡住，日志反复出现 Failed to AUTH during FAILOVER，最终切换失败或超时。
- 密码含
@、/、:等字符必须 URL 编码，例如pass@123→pass%40123 -
sentinel auth-pass行必须写在对应sentinel monitor行之后，顺序错乱可能导致解析失败 - 不同集群用不同密码是常态，不要为了省事统一设成同一个值
quorum 参数是全局的还是 per-master 的？
quorum 是每个 master-name 独立计算的，不是整个哨兵集群的全局阈值。
比如你有两套集群：prod-a-redis 配了 quorum 2，prod-b-redis 配了 quorum 3，那么前者需要至少 2 个哨兵达成一致才触发故障转移，后者则要 3 个——哪怕你总共只部署了 3 台哨兵，它们对两个集群的投票也是分开计票的。
- 这个设计意味着：增加哨兵节点数不会自动提升所有集群的容错能力，每个
master-name的quorum值需按实际哨兵数量重新评估 - 若某集群长期只有 1 台哨兵在工作（比如网络分区），而
quorum设为 2，那它永远无法触发自动故障转移 - 生产环境建议
quorum设为哨兵总数的「过半」，且不低于 2
从节点恢复后为何没自动重新加入主从复制？
哨兵本身不负责管理从节点的连接重建，它只管主节点故障转移；从节点能否自动重连，取决于它自身的配置和网络可达性。
典型原因包括：从节点配置里没写 slaveof 或写错了地址端口；主节点启用了密码但从节点的 masterauth 没配或配错；主节点 requirepass 和从节点 masterauth 不一致；防火墙或网络策略阻断了从节点到新主节点的连接。
- 确保从节点
redis.conf中slaveof指向的是当前主节点地址（故障转移后可能已变） - 从节点的
masterauth必须与新主节点的requirepass完全一致，大小写和特殊字符都不能差 - 检查从节点日志是否有
Connection refused或NOAUTH类错误，这是最直接的线索
master-name 的唯一性和 auth-pass 的绑定粒度——它们不是“写一次就全局生效”的配置，而是每个监控目标各自独立的一套契约。 
