Redis Sentinel DNS解析问题排查与解决方案

问题现象

在使用Redis Sentinel构建高可用集群时，发现一个异常现象：当Sentinel实例启动后，主节点上的Sentinel会很快将新启动的从节点Sentinel标记为下线状态(sdown)。同时，从节点上的Sentinel实例会变得无响应，无法通过redis-cli连接。

环境配置

该环境采用三节点Redis集群架构：

• VM1：Redis主节点 + Sentinel
• VM2：Redis从节点 + Sentinel
• VM3：Redis从节点 + Sentinel

所有节点均运行在RHEL 8.6系统上，通过podman容器化部署。

问题排查过程

初步分析

1. 日志分析：主节点Sentinel日志显示，它能够短暂识别从节点的Sentinel，但随后就将其标记为下线状态。

2. 时间同步检查：确认所有节点时间同步正常，排除了时钟漂移导致的问题。

3. 网络连通性：Redis主从复制工作正常，说明基础网络通信没有问题。

深入调查

通过获取Sentinel进程的堆栈跟踪，发现关键线索：

1. 堆栈跟踪显示：Sentinel在尝试解析主机名时卡在DNS查询阶段，最终导致内存访问错误。

2. DNS解析测试：发现虽然UDP方式的DNS查询正常，但TCP方式的DNS查询失败。

解决方案验证

经过多次测试，确认以下配置变更可解决问题：

1. 禁用主机名解析：在sentinel配置中设置：

   resolve-hostnames no
   announce-hostnames no
   

2. 使用IP地址：将所有节点配置改为直接使用IP地址而非主机名。

根本原因

问题的根本原因是本地DNS服务器配置不当：

• DNS服务器仅响应UDP查询，不响应TCP查询
• Redis Sentinel在某些情况下会使用TCP方式进行DNS解析
• 这种部分失败的DNS解析导致Sentinel间通信异常

最佳实践建议

1. DNS服务器配置：

   • 确保DNS服务器同时支持UDP和TCP查询
   • 配置合理的超时时间和重试机制

2. Sentinel配置建议：

   • 在生产环境中优先使用IP地址
   • 如需使用主机名，确保DNS解析完全可靠
   • 监控Sentinel的tilt模式触发情况

3. 故障排查技巧：

   • 使用dig命令测试TCP和UDP两种DNS查询方式
   • 检查系统resolv.conf配置
   • 监控DNS查询的响应时间和成功率

总结

这个案例展示了基础设施配置对分布式系统稳定性的重要影响。即使Redis Sentinel本身运行正常，底层DNS服务的异常也可能导致集群管理功能失效。在部署关键业务系统时，必须确保所有基础服务的完整性和可靠性。