双Elasticsearch主节点集群单节点宕机后无法运行问题求助

这种双节点ES集群的坑我之前踩过好几次，先给你拆解下问题根源：Elasticsearch的master节点选举依赖法定人数（quorum），公式是 (候选master节点数/2)+1。你这是两个候选master节点，所以quorum是2——也就是说必须至少2个候选节点在线才能选出可用的master。当其中一个节点挂了，剩下的1个节点达不到quorum要求，哪怕它本身是候选master，也会进入no master的阻塞状态，同时它还会一直尝试连接宕机节点，就出现了你看到的连接拒绝错误。

下面是不用新增专用master节点的具体解决方案，分ES版本来说：

针对Elasticsearch 6.x及更早版本 #

1. 修改集群配置
   找到存活节点的elasticsearch.yml配置文件，修改或添加以下参数：

   discovery.zen.minimum_master_nodes: 1
   

   这个参数就是控制选举master所需的最小候选节点数量，改成1后，单节点就能满足quorum要求，自动成为可用的master节点。

2. 重启Elasticsearch服务
   执行重启命令（根据你的系统服务管理方式调整）：

   sudo systemctl restart elasticsearch
   

3. 额外优化（可选）
   为了减少存活节点对宕机节点的频繁连接报错，可以调整心跳超时参数：

   discovery.zen.fd.ping_timeout: 30s
   discovery.zen.fd.ping_retries: 3
   

   延长超时时间，降低重试次数，减少日志里的错误信息。

针对Elasticsearch 7.x及更高版本 #

新版本ES已经废弃了旧的Zen发现机制，改用了新的集群协调器，参数有所变化：

1. 修改集群配置
   编辑elasticsearch.yml，确保以下配置正确：

   # 初始化时指定所有候选master节点的名称
   discovery.cluster.initial_master_nodes: ["你的节点1名称", "你的节点2名称"]
   # 设置法定投票数为1，允许单节点成为master
   discovery.quorum.vote.count: 1
   # 确保只有候选master节点参与投票（可选）
   cluster.election.ignore_non_master_votes: true
   

2. 重启Elasticsearch服务
   同样执行重启命令：

   sudo systemctl restart elasticsearch
   

3. 优化连接重试（可选）
   调整故障检测的间隔时间，减少不必要的连接尝试：

   cluster.fault_detection.follower_check.interval: 30s
   

后续注意事项 #

• 当故障节点恢复后，它会自动重新加入集群，Elasticsearch会自动同步数据，无需手动干预。
• 长期运行双节点集群的话，保持minimum_master_nodes（或discovery.quorum.vote.count）为1是安全的——当两个节点都在线时，集群会正常选举master，不会有问题；当一个节点挂了，另一个能立刻接管。

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