怎么在Linux利用Redis-Sentinel配置哨兵模式主从自愈-linux运维-PHP中文网

Redis-Sentinel 启动后不识别主从关系是因为它只监控已存在的主从拓扑，不会自动建立；需确保从节点执行 SLAVEOF、主节点允许远程连接、Sentinel 配置中的 IP 和 auth-pass 与主节点一致。

怎么在linux利用redis-sentinel配置哨兵模式主从自愈

为什么 Redis-Sentinel 启动后不识别主从关系

Sentinel 不会自动发现或建立主从关系，它只监控已存在的主从拓扑。如果你刚部署一主一从但 Sentinel 一直显示 +sdown 或 +odown，大概率是主从没真正连上——比如从节点没执行 SLAVEOF，或配置了 slave-announce-ip 却填错了地址。

实操建议：

先在从节点手动执行 SLAVEOF ，再用 INFO replication 确认 role:slave 且 master_link_status:up
主节点必须开启 bind（或注释掉）并允许远程连接，检查 protected-mode no 和 requirepass 是否与 Sentinel 配置中的 auth-pass 一致
Sentinel 配置里 sentinel monitor mymaster 2 的 IP 必须是主节点真实可被 Sentinel 进程访问的地址（不能写 127.0.0.1）

sentinel.conf 中哪些参数改错会导致 failover 失败

最常见的失效点不是监控逻辑，而是权限和超时配置不匹配。Sentinel 在故障转移时需要向新主发送 CONFIG REWRITE、重置从节点的 SLAVEOF，这些操作失败，failover 就卡在 +failover-end 之后无下文。

关键参数检查清单：

sentinel auth-pass mymaster ：必须和主节点的 requirepass 完全一致，大小写敏感
sentinel down-after-milliseconds mymaster 5000：太短（如 1000）易误判；太长（如 30000）导致恢复延迟，建议 3~5 秒
sentinel failover-timeout mymaster 180000：这个值必须大于从节点同步 RDB 的耗时，否则 failover 中途放弃
如果主节点启用了 rename-command CONFIG ""，Sentinel 会彻底失能——必须放开 CONFIG 或改用 rename-command CONFIG "config123" 并在 Sentinel 配置中加 sentinel config-epoch mymaster 0（不推荐，绕过更麻烦）

如何验证 Sentinel 是否真能自动切换主从

别只看日志里有没有 +switch-master，要确认客户端是否真的连上了新主。很多测试停掉旧主后，Sentinel 日志看似成功，但应用仍往旧地址写入，因为没刷新连接池里的 host/port。

Linuxdo Application

为 Linux.do 注册撰写高通过率、去 AI 化的中文小作文。进行自适应调查以了解申请人的真实背景，...

下载

安全验证步骤：

用 redis-cli -p 26379 连任意 Sentinel，执行 SENTINEL get-master-addr-by-name mymaster，确认返回的是新主 IP+端口
停掉当前主节点（kill -9 $(pidof redis-server)），等待 30 秒，再查一次地址，应已变更
在从节点执行 INFO replication，确认其 master_host 指向新主，且 master_link_status 是 up
用 redis-cli -h -p INFO server | grep redis_version 验证新主身份，避免误切到中间状态的从节点

多个 Sentinel 实例之间为什么无法达成投票共识

Sentinel 依赖 quorum（法定票数）触发 failover，但这个“票数”不是实例总数，而是配置中 sentinel monitor 最后一个参数，且所有 Sentinel 必须能互相通信 + 认证一致。常见表现是日志反复刷 +vote-for-leader ... 0000000000000000000000000000000000000000 1，却始终不推进。

排查要点：

确保所有 Sentinel 都用相同的名字监控同一主节点：sentinel monitor mymaster 10.0.1.10 6379 2 中的 2 表示至少 2 个 Sentinel 同意才触发，若你只启了 2 个实例，这个值必须 ≤2；若启了 3 个，建议设为 2
检查各 Sentinel 的 sentinel announce-ip 和 sentinel announce-port：不填则自动用本机 bind 地址，跨 Docker 或 NAT 时极易填成容器内网 IP，导致彼此 ping 不通
防火墙必须放行 Sentinel 默认端口 26379 的 TCP 入站和出站，用 telnet 26379 实测连通性

哨兵模式真正难的不是配通，而是让每个组件在故障边界下仍按预期交换身份、权限和网络信号。尤其当混用 Docker、云厂商安全组、自定义 bind 地址时，sentinel announce-ip 和 sentinel auth-pass 这两个字段，90% 的线上问题都栽在这儿。