Redis 6.2如何处理哨兵模式下的主机名解析_启用sentinel-resolve-hostnames-Redis-PHP中文网

redis 6.2 默认不解析主机名，必须显式配置 sentinel resolve-hostnames yes，否则在 docker/k8s 等 dns 环境中，哨兵将主机名（如 redis-master）误作 ip 导致连接失败、监控失效、故障转移瘫痪。

redis 6.2如何处理哨兵模式下的主机名解析_启用sentinel-resolve-hostnames

Redis 6.2 默认不解析主机名，必须显式启用 sentinel resolve-hostnames yes，否则在 Docker、K8s 或任何依赖 DNS 的环境中，哨兵会把 redis-master 这类主机名当成非法 IP 直接连接失败。

为什么 `sentinel resolve-hostnames` 在 Redis 6.2 中不是可选而是必需

Redis 6.2 的哨兵默认值仍是 no（即使文档里没强调，源码和实际行为都确认这一点）。这意味着：

哨兵读到 sentinel monitor mymaster redis-master 6379 2 时，不会查 DNS，而是直接调用 inet_aton("redis-master") → 返回 0 → 解析失败
启动日志里会出现明确错误：Error resolving hostname 'redis-master'
后续所有监控、主观下线判断、故障转移全部卡住，因为根本连不上主节点
这个行为在物理机配固定 IP 时“碰巧”能过，但在容器编排环境里 100% 失败

如何正确配置 `sentinel resolve-hostnames`（含生效验证）

它必须出现在 sentinel.conf 中，并且要在 sentinel monitor 之前或之后均可，但不能被 CONFIG REWRITE 覆盖掉 —— 因为哨兵重写配置时默认不保留该指令（除非你手动加了）。

正确写法示例：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

port 26379
bind 0.0.0.0
sentinel resolve-hostnames yes   # ← 必须这一行
sentinel monitor mymaster redis-master 6379 2
sentinel down-after-milliseconds mymaster 30000

验证是否生效：

启动后执行 redis-cli -p 26379 sentinel get-master-addr-by-name mymaster，返回 IP 而非报错
查看哨兵日志，确认没有 Error resolving hostname 类错误
手动触发一次 SENTINEL failover mymaster，观察是否能成功解析新主节点的主机名（比如 redis-slave-1）

`sentinel resolve-hostnames yes` 的副作用与边界条件

开启后不是“一劳永逸”，它只解决 DNS 解析环节，其他依赖仍需对齐：

Docker Compose 中必须保证哨兵容器和 Redis 容器在同一个自定义网络（network_mode: bridge 不行，得用 networks: [redis-net]）
Kubernetes 中，Service 名称必须能被 Pod 内 DNS 正确解析（即 redis-master.redis.svc.cluster.local 能通），哨兵不自动补全域名后缀
如果主机名解析结果是 IPv6 地址，而 Redis 实例只监听 IPv4，仍会连接失败 —— 此时需要配合 bind 或 replica-announce-ip 控制暴露地址族
sentinel announce-hostnames yes 是另一个开关，仅影响哨兵对外广播自己地址的方式，和解析无关，别混淆

最常被忽略的一点：Redis 6.2 的哨兵在首次解析成功后，会缓存 DNS 结果，但不会定期刷新。如果后端服务 IP 变了（比如 K8s Pod 重建），哨兵不会自动感知，直到下次故障转移或重启 —— 这时候光开 resolve-hostnames 不够，还得靠合理的 down-after-milliseconds 和健康探测兜底。