Elasticsearch 集群选主和脑裂如何处理？

先说结论

主节点负责集群状态变更，如索引元数据、分片分配和节点加入退出，不负责承载所有数据读写。现代 Elasticsearch 通过具备主资格节点的多数派选举和集群状态发布避免网络分区两侧同时形成有效主集群。

生产通常部署三个稳定的 master-eligible 节点，跨故障域分布，并避免让它们承受过重查询、写入或长时间 GC。

候选节点需要获得法定多数支持，集群状态更新也需可靠发布和确认。失去多数派的一侧不能继续进行需要主节点的变更，这是用部分可用性换取一致决策。

主节点维护 cluster state：节点列表、索引 mapping/settings、分片分配、路由表和任务状态。数据节点执行写入、搜索和 merge；协调节点接收请求并扇出/归并；ingest 节点可负责预处理。角色可以混合，但生产大集群常把稳定主节点与高查询/高写入负载隔离。

主节点不承载所有业务请求，并不意味着它可以无限小。集群 state 很大、索引数量过多、频繁创建删除索引和大量分片会让状态发布、选举和 heap 压力显著增加。

假设 3 个 master-eligible 节点在网络分区后分成 2+1：2 节点一侧拥有多数，可以继续选主；1 节点一侧没有多数，不能形成有效主集群。若配置不当允许两侧都自认为主，双方可能发布互相冲突的分配与元数据，恢复时很难合并，这就是脑裂风险。

因此生产通常使用奇数个独立主资格节点并跨故障域，至少保证任意一个故障仍有多数。节点数不是越多越好，更多选举成员也会增加通信和状态发布成本。

初始选举需要明确集群名称、节点发现和 bootstrap 配置。初始 master 列表只用于第一次形成集群；集群已建立后，重复修改 bootstrap 或 cluster name 可能把重启节点误组装成一个新集群。升级和重启采用滚动策略，先确认剩余主节点有多数和稳定状态，再处理下一台。

关注 master election 次数、cluster state publication 延迟、pending tasks、节点连接、GC pause、网络丢包和 CPU。主节点频繁 GC 会被其他节点视为失联，触发不必要的选举；大量索引创建和模板更新也会排队阻塞状态变更。

排查时保存主节点日志、线程转储和集群状态快照，不要在故障中反复重启所有节点，这可能把短暂网络问题放大成全群不可用。

首次组建集群的 bootstrap 配置只用于初始启动，集群形成后不应重复配置成新集群。监控主节点 GC、集群状态队列、网络延迟和频繁选举，节点重启采用滚动方式。

协调节点不等于主节点，任何接收请求的节点都可能协调查询。照搬旧版本 minimum_master_nodes 配置到现代版本并不正确，应以所用版本官方机制为准。

从多数派容错看，两个节点失去任意一个就无法形成多数，且网络分区难以兼顾可用性；通常使用三个独立主资格节点容忍一个故障。

需要足够多数派和故障域隔离，但过多会增加选举通信、集群状态发布和运维复杂度。三个主资格节点是很多中型集群的常见起点，不是所有规模的固定答案。

现代多数派选举旨在防止双主，但长延迟、丢包和频繁节点失联会导致选举抖动、请求失败和状态发布延迟。应修复网络和资源问题，而不是只延长超时。

索引、分片和 mapping 都会进入 cluster state，状态越大，发布和序列化越慢，主节点 heap 和 CPU 压力越高。时间序列应使用 rollover、数据流和合理保留。