我先给结论，再说明它在项目里解决什么问题。理解 master-eligible 节点、多数派决策、集群状态发布和故障恢复。主节点负责集群状态变更，如索引元数据、分片分配和节点加入退出，不负责承载所有数据读写。现代 Elasticsearch 通过具备主资格节点的多数派选举和集群状态发布避免网络分区两侧同时形成有效主集群。 生产通常部署三个稳定的 master-eligible 节点，跨故障域分布，并避免让它们承受过重查询、写入或长时间 GC。

核心机制我会按一次真实执行过程来讲。沿着「节点发现并加入 → Master-eligible 节点投票 → 选出唯一 Master → 发布集群状态 → 故障后重新选举并恢复分片」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 节点发现并加入 discovery.seedhosts 和 initialmasternodes 只服务发现/首次引导，错误重复引导可能形成独立集群。

实现细节只抓关键入口，不会整段背源码。Coordinator/CoordinationState：term、投票与发布。 cluster/pendingtasks：控制面积压。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

放到生产使用时，我会关注参数和验证数据。暂停 Master、断网和制造长 GC，记录选举与 Cluster State 发布时间。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「pending tasks」为主基线，记录值应满足「记录稳态基线」；同时保存 Master 选举次数、Cluster State 发布时间，使后续变化能够回到同一时间轴比较。

最后补充常见误区和使用边界。Master 与数据节点混部且堆压力高，长 GC 被其他节点视为失联，反复选举与分片重分配。隔离专用 Master、稳定堆和调整故障检测前先解决停顿根因后恢复。 重复设置 initialmasternodes 误建新集群：Master 选举次数：3 个专用 Master 跨域。 方案：更适合的场景：主要收益：代价与边界。 专用 Master 节点：中大型生产集群：控制面资源隔离：额外节点成本。 混合角色：小型非关键集群：资源利用率高：数据查询/GC 会影响选举。 Voting-only 节点：需增加投票容错但不承担 Master：提高多数派稳定性：仍需资源和拓扑规划。 选型至少带上 文档规模、分片数、字段基数、查询并发和写入速率，并用上面的量化基线验证；未知数据应明确为待测假设。