master-name必须全局唯一，是哨兵识别集群的唯一标识；重复会导致后加载配置覆盖前一个；建议用环境+业务前缀命名，如prod-user-redis。
哨兵配置里 sentinel monitor 的 master-name 必须全局唯一
一个哨兵进程可以监控多个主从集群，但前提是每个集群的 master-name 不同。这不是可选项，是哨兵内部识别集群的唯一标识——它会用这个名字做键去存状态、发命令、查故障。如果两个 sentinel monitor 行用了相同的 master-name，后加载的会覆盖前一个，导致只监控最后一个。
- 实际配置中，
master-name建议带环境+业务前缀，比如prod-user-redis、staging-order-redis，别用myMaster这种泛化名 - 同一套哨兵进程里，不能靠改
ip:port来“区分”集群；哨兵不校验地址是否重复，只认master-name - 重启哨兵时，所有
sentinel monitor行都会重载，所以配置文件里重复名的问题会在启动时静默生效，不容易立刻发现
哨兵发现主节点失败：检查 sentinel resolve-hostnames 和 DNS 可达性
当哨兵配置了多个集群，且其中某些主节点用域名（如 redis-master.user.svc.cluster.local）而非 IP 时，容易出现部分集群始终显示 master-link-status:down。根本原因常是哨兵没开域名解析，或容器/宿主机 DNS 配置不一致。
- 默认
sentinel resolve-hostnames no，此时若配置中写了域名，哨兵会直接报Unable to resolve master name错误并跳过该行 - 必须显式设为
yes，且确保哨兵进程运行环境能nslookup或dig通对应域名 - Kubernetes 场景下尤其注意：哨兵 Pod 的
/etc/resolv.conf要和目标 Redis Service 所在命名空间 DNS 策略兼容，否则即使开了resolve-hostnames也查不到
sentinel auth-pass 和 requirepass 不匹配会导致部分集群无法切换
多集群复用哨兵时，各主从集群可能设了不同密码。哨兵必须为每个 master-name 单独配密码，否则在故障转移阶段，哨兵尝试向新主节点发 CONFIG REWRITE 或 SLAVEOF 时会因认证失败卡住，日志里反复出现 Failed to AUTH during FAILOVER。
- 每行
sentinel monitor后面跟的密码参数，只作用于对应master-name的主节点，不继承、不共享 - 如果某个集群主节点没设密码（
requirepass为空），对应sentinel auth-pass行必须留空，不能删掉整行，也不能填任意字符串 - 密码含特殊字符（如
@、/）要 URL 编码，哨兵不会自动处理，否则解析失败后该集群完全不可控
哨兵日志里频繁刷 +sdown 但不触发故障转移？先看 quorum 和 sentinel known-slave
多个集群共用一套哨兵，最容易被忽略的是 quorum 参数的实际作用域——它不是全局阈值，而是每个 master-name 独立计算的。如果某集群只有 2 个哨兵在线，而它的 quorum 设成了 3，那永远达不到多数派，自然不 failover。
-
quorum是“多少个哨兵同意才算主观下线”，不是“总哨兵数”。例如 5 个哨兵进程，监控 3 套集群，每套都应设quorum 3（即 ≥3 个哨兵投票才行动） - 哨兵启动后会主动向主节点执行
SENTINEL slaves <master-name></master-name>拉取从节点列表。如果某集群从节点没正确返回（比如防火墙挡了端口、从节点未开启slave-announce-ip），哨兵就认为该集群“信息不全”，拒绝发起选举 - 用
redis-cli -p 26379 SENTINEL slaves <master-name></master-name>手动查一次，看返回的从节点 IP/PORT 是否真实可达，比盯日志更快定位问题
多集群复用哨兵本身不难，难点在于每个 master-name 对应的状态是隔离维护的，但配置错误、网络割裂、权限不一致这些“局部问题”，很容易被当成“全局异常”去排查。盯着单个 master-name 查状态、查日志、查连通性，比笼统看哨兵进程更有效。
