哨兵节点启用密码认证但未提供密码导致SENTINEL master报NOAUTH错误；需在sentinel.conf中配置sentinel auth-pass，并手动auth；注意端口、master-name一致性及flags等字段含义。
SENTINEL master 返回空或报错 NOAUTH Authentication required
说明哨兵节点启用了密码认证，但连接时没提供密码。Redis 哨兵默认不继承主从节点的 requirepass，它自己的认证需单独配置在哨兵配置文件中（sentinel.conf）的 sentinel auth-pass 指令里，但客户端连哨兵时仍要手动鉴权。
- 先用
redis-cli -p 26379连哨兵端口（默认 26379），再执行auth - 如果哨兵没设密码，但提示该错误，检查是否误连了普通 Redis 实例（端口 6379）而非哨兵（26379）
-
SENTINEL master中的master-name必须和sentinel monitor配置项里的名字完全一致，区分大小写且不能有空格
SENTINEL master 输出字段含义不明确，尤其 flags 和 role-reported
flags 是逗号分隔的状态标记，常见值有 master、s_down（哨兵主观下线）、o_down（客观下线）、fail（故障转移失败）。它反映的是哨兵视角下的当前判断，不是真实网络状态。
-
role-reported来自该节点自己上报的角色（可能已过期），而role-reported-is-master才表示它声称自己是主节点 - 真正可信的是
num-slaves（在线从节点数）和quorum（达成客观下线所需的哨兵数），这两个值异常往往预示故障转移卡住 - 若
flags含s_down但num-slaves正常，大概率是某台哨兵网络分区，别急着重启，先查日志里+sdown和-sdown是否成对出现
用 redis-cli 调用 SENTINEL master 时返回结果被截断或格式混乱
这是 redis-cli 默认以“行协议”输出导致的——它把多行响应压成一行显示，字段边界难分辨。这不是数据丢失，只是展示问题。
- 加
--raw参数：运行redis-cli -p 26379 --raw SENTINEL master mymaster，获得原始 RESP 格式，字段清晰可读 - 更推荐用
--csv：输出 CSV 行，方便 grep 或导入表格，例如redis-cli -p 26379 --csv SENTINEL master mymaster | tr ',' '\n'可逐行查看字段 - 避免在脚本中直接解析无格式输出；若需程序化处理，请用支持 RESP 解析的客户端库（如 Python 的
redis-py），别靠字符串切分
为什么 SENTINEL master 显示主节点正常，但从节点却连不上主？
因为 SENTINEL master 只反映哨兵的元数据视图，不探测真实 TCP 连通性或 Redis 协议可用性。主节点可能进程存活但卡死、端口被防火墙拦截、或 bind 配置未监听外部地址。
- 先确认
ip和port字段值是否为从节点能访问的真实地址（比如别是127.0.0.1） - 在从节点机器上手动 telnet
ip port，看端口是否通；再用redis-cli -h测试协议层响应-p ping - 注意
SENTINEL master不更新last-ok-ping-reply字段时长超过down-after-milliseconds，就可能触发误判，检查哨兵日志里是否有+tilt（倾斜模式）警告
哨兵状态不是快照，而是带延迟和投票机制的动态共识。最常被忽略的是：你看到的 SENTINEL master 结果，永远比实际集群状态慢几百毫秒，且依赖至少半数哨兵在线才能保证准确性。
