我来帮你排查这个Elasticsearch集群组建失败的问题——从你给出的集群健康信息来看，当前只有单个节点在集群中，而且没有数据节点，这说明另外两台服务器的节点根本没成功加入集群。结合你的配置和操作步骤，我整理了几个最可能的原因和对应的排查方案：

1. Elasticsearch版本与配置项不兼容（最可能的核心问题） #

如果你使用的是Elasticsearch 7.0及以上版本，discovery.zen.*系列的旧配置已经被完全弃用了！这些配置在新版本中不会生效，导致每个节点都无法发现其他节点，只能各自形成独立的单节点集群。

你需要把旧配置替换为新版本的对应项：

• 将discovery.zen.ping.unicast.hosts替换为：

  discovery.seed_hosts: ["xxx.xxx.xxx.102", "xxx.xxx.xxx.251", "xxx.xxx.xxx.34"]
  

• 将discovery.zen.minimum_master_nodes替换为：

  cluster.initial_master_nodes: ["node1", "node2", "node3"]
  

  （这里填写节点的node.name或者IP都可以，推荐用节点名称，更直观）

修改完所有节点的配置后，重启Elasticsearch服务，再重新执行curl -XGET http://xxx.xxx.xxx.102:9200/_cluster/health?pretty查看集群状态。

2. 服务器间网络连通性未真正打通 #

虽然你已经通过firewall-cmd开放了9200和9300端口，但需要确认节点之间的TCP连接是否真的能建立：

• 在每个节点上执行测试命令，比如测试连接server-2的9300端口：

  nc -zv xxx.xxx.xxx.251 9300
  

  或者：

  telnet xxx.xxx.xxx.251 9300
  

• 如果连接失败，要检查是否有其他防火墙规则（比如云服务商的安全组、硬件防火墙）限制了端口，或者服务器之间的路由存在问题。

3. SELinux限制了Elasticsearch的网络通信（Linux服务器常见坑） #

如果你的服务器开启了SELinux，即使系统防火墙开放了端口，SELinux可能仍然会阻止Elasticsearch的节点间通信。可以先临时关闭SELinux测试：

setenforce 0

如果关闭后节点能成功加入集群，那么需要配置SELinux规则允许Elasticsearch的网络操作（生产环境不建议永久关闭SELinux），比如：

semanage port -a -t http_port_t -p tcp 9200
semanage port -a -t http_port_t -p tcp 9300

4. 节点数据/日志目录权限不正确 #

Elasticsearch进程需要对path.data和path.logs目录拥有读写权限，如果权限不对，节点可能无法正常启动或者加入集群：

• 检查目录权限：

  ls -ld /var/lib/elasticsearch /var/log/elasticsearch
  

• 如果所有者不是elasticsearch用户，执行以下命令修正：

  chown -R elasticsearch:elasticsearch /var/lib/elasticsearch /var/log/elasticsearch
  

5. 查看节点日志获取精准线索 #

如果以上排查都没解决问题，直接查看Elasticsearch的日志文件（路径是/var/log/elasticsearch/cluster-mode.log），里面会记录节点尝试加入集群的详细错误信息——比如无法解析主机、版本不匹配、权限不足等，这些日志能帮你快速定位到具体问题。

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