Elasticsearch三节点集群两节点同时宕机剩余单节点无法服务配置咨询

Elasticsearch 主节点选举严格遵循多数派（Quorum）机制，3个master eligible节点组成的集群，选举成功必须获得至少2张节点投票，单节点无法凑够法定票数，自然会抛出master not discovered or elected yet报错，集群整体进入不可用状态。
你当前采用的「主数据中心2节点+异地灾备1节点」的部署架构本身存在设计缺陷：master多数派节点落在了同一个故障域，一旦主数据中心整体故障，剩余灾备节点永远无法达成选举条件，这和默认设计机制无关，是部署架构违反了ES分布式选举的基本前提。

该方案仅适用于主数据中心2个节点确认完全宕机、短时间无法恢复，需要临时拉起灾备节点承接读流量的应急场景，禁止作为常态配置运行，否则会触发脑裂、数据不一致等不可逆问题。
操作步骤：

• 停止灾备节点的Elasticsearch进程
• 修改灾备节点的elasticsearch.yml配置文件，调整以下参数：

# 初始主节点列表仅保留当前灾备节点自身标识
cluster.initial_master_nodes: ["当前灾备节点的node.name配置值"]
# 节点发现列表仅保留本机地址，不再尝试连接主数据中心节点
discovery.seed_hosts: ["127.0.0.1"]

• 重启灾备节点，等待节点启动完成后，调用集群配置接口将集群全局设置为只读状态，阻断所有写入请求，避免后续主节点恢复时出现数据冲突：

PUT /_cluster/settings
{
  "persistent": {
    "cluster.blocks.read_only": true
  }
}

• 配置完成后，该单节点即可正常响应所有索引查询请求，写入请求会被集群直接拒绝，满足只读对外服务的需求。

风险提示：执行该操作后，必须确保主数据中心的2个故障节点在恢复前不会和当前灾备节点网络连通，否则两个分区会各自选举出主节点形成脑裂，数据会出现双向写入冲突，无法自动合并修复。待主数据中心节点修复需要重新组建集群时，必须先将灾备节点的配置还原为原集群配置，解除只读状态后再将主数据中心节点加入集群，完成数据同步后再恢复对外服务。

靠故障后临时改配置的方式无法满足高可用容灾要求，建议从架构层面调整彻底规避该问题：

• 故障域打散部署：将3个master eligible节点分散部署在3个独立故障域，例如主数据中心2个可用区各部署1个、灾备数据中心部署1个，任意单个数据中心/可用区整体故障时，剩余2个节点都能凑够选举多数派，集群无需任何调整即可正常提供读写服务。
• 跨集群复制（CCR）架构：不要将灾备节点和主集群节点组建为同一个集群，主数据中心部署独立的3节点高可用集群，灾备数据中心部署独立的小规模集群，通过ES原生CCR能力将主集群数据实时同步到灾备集群。该架构下主数据中心整体故障时，灾备集群本身是独立运行的可用集群，直接切流即可承接服务，完全不存在选举多数派的问题，平时灾备集群也可以分担读流量。

不要在集群正常运行时将法定选举节点数阈值调低为1，该配置下一旦出现跨数据中心网络分区，两个区域的节点会各自选举主节点形成脑裂，数据一致性完全无法保障。

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