从你的描述和错误信息来看，两个问题其实是关联的，核心原因是主机名解析失败，导致Jedis无法正确连接到Redis主节点。下面一步步分析并给出解决方案：

先理解第二个错误的本质 #

你在主服务器上执行./redis-cli -h redis-1 -p 26379时收到：

Could not connect to Redis at redis-1:26379: nodename nor servname provided, or not known

这说明你的机器无法把redis-1这个主机名解析成对应的IP地址。无论是redis-cli还是Jedis，都需要能正确解析目标主机的名字才能建立连接。

为什么会触发"All sentinels down"错误？ #

你的Jedis代码确实连接到了localhost:26379的哨兵，但这里的关键是：
当Jedis从哨兵获取主节点mymaster的地址时，哨兵返回的是redis-1:6379（从你尝试连接的命令能推断出来）。而你的应用机器（运行Jedis的机器）无法解析redis-1这个主机名，导致Jedis无法连接到主节点，进而抛出"所有哨兵都已下线"的错误（这是Jedis的一个误判，实际是主节点地址不可达）。

解决方案 #

方案1：配置主机名解析（最快见效） #

在运行Jedis应用的机器上，添加主机名到IP的映射：

• Linux/macOS：编辑/etc/hosts文件，添加一行：

  主节点的实际公网/内网IP  redis-1
  

• Windows：编辑C:\Windows\System32\drivers\etc\hosts文件（需要管理员权限），添加同样的映射。

添加后，测试是否能解析：

ping redis-1

如果能ping通，再重新运行你的Jedis代码，应该就能正常连接了。

方案2：修改Redis Sentinel配置，返回IP而非主机名 #

如果不想依赖主机名映射，可以修改哨兵的配置，让它向客户端返回主节点的IP地址：

1. 找到哨兵的配置文件sentinel.conf
2. 添加或修改以下配置项：

   sentinel resolve-hostnames no
   sentinel announce-ip 主节点的实际IP
   

3. 重启Redis Sentinel服务
4. 登录到哨兵所在机器，执行以下命令确认返回的是IP：

   ./redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
   

方案3：直接用IP配置哨兵和Jedis #

另一种更直接的方式是，在配置哨兵监控主节点时，直接使用主节点的IP而非主机名：

1. 修改哨兵的sentinel.conf，把监控命令改成：

   sentinel monitor mymaster 主节点IP 6379 2
   

2. 重启哨兵服务
3. 这样哨兵向Jedis返回的主节点地址就是IP，无需解析主机名。

额外排查步骤 #

1. 确认哨兵正常监控主节点：在哨兵所在机器执行

   ./redis-cli -p 26379 sentinel masters
   

   查看输出中mymaster的状态，确认ip字段是可访问的地址。
2. 测试应用机器到主节点的连通性：

   ./redis-cli -h 主节点IP -p 6379 ping
   

   如果返回PONG，说明网络是通的，问题确实出在主机名解析上。

内容的提问来源于stack exchange，提问作者Manas Saxena