理解 Elasticsearch 主节点选举与法定人数要求

Elasticsearch 主节点法定人数决定集群能否安全地选举领导者、发布集群状态变更，并避免同一集群的两个隔离侧做出不同决策。

当选的主节点本身不会使搜索更快。它协调集群。当选举不稳定时，症状可能显得分散：索引创建挂起、分片分配停止、Kibana 报告变化的健康状态，以及日志重复显示关于未发现主节点的消息。

主节点的关键作用

虽然数据节点处理索引、搜索和存储数据的繁重工作，但主节点负责管理整个集群的结构和元数据。除非它也被配置为数据节点，否则它通常不参与查询或索引操作。

主节点职责

1. 集群状态管理： 主节点维护并发布集群状态——集群当前配置的蓝图，包括哪些索引存在、这些索引的映射和设置，以及每个分片的位置。
2. 节点管理： 处理节点的加入和离开，相应地更新集群状态。
3. 索引管理： 创建、删除或更新索引。
4. 分片分配： 决定主分片和副本分片应位于何处（初始分配和节点故障后的再平衡）。

如果当选的主节点失败，集群会暂停仅主节点的工作，直到另一个主节点被选举出来。现有搜索可能继续针对可用分片进行，但索引创建、映射更新和分配决策依赖于稳定的主节点协调。

理解主节点选举与投票

在分布式系统中，每当当前主节点失败或变得不可达时，就需要选举过程。自 Elasticsearch 7.0 以来，选举机制已显著简化和强化，主要通过消除复杂的 discovery.zen.minimum_master_nodes 设置并引入自我管理的投票配置。

选举过程（Elasticsearch 7.x+）

主节点选举现在由主节点候选节点自动处理，这些节点在配置中使用 node.roles: [master, data] 或仅使用 node.roles: [master] 定义。

1. 候选发现： 主节点候选节点通信以确定活跃投票成员集合。
2. 法定人数检查： 节点检查它们是否能达到法定人数——已知投票节点的大多数——以确保共识。
3. 领导者选择： 如果建立了法定人数，Elasticsearch 的协调子系统根据其内部选举规则选择主节点。
4. 投票与确认： 对提案进行投票，如果被大多数接受，新主节点接管并发布新的集群状态。

初始集群引导

首次启动全新集群时，Elasticsearch 需要知道哪些节点应参与初始投票配置。这通过 cluster.initial_master_nodes 设置处理。此设置应仅在集群初始启动时使用一次。

# elasticsearch.yml 初始设置片段
cluster.name: my-production-cluster
node.name: node-1
node.roles: [master, data]

# 列出用于初始引导的所有主节点候选节点名称
cluster.initial_master_nodes: [node-1, node-2, node-3]

提示： 集群形成后，从每个节点移除 cluster.initial_master_nodes。在后续重启中保留它可能很危险，因为此设置仅用于全新集群的首次引导。

法定人数要求与脑裂预防

法定人数要求的根本原因是保证在任何时候只能选举一个领导者，从而防止脑裂问题。

什么是脑裂？

脑裂发生在网络分区将集群分割成隔离的段，并且多个段都认为自己拥有权威主节点时。如果发生这种情况，不同侧可能接受冲突的集群状态变更，这正是法定人数旨在防止的。

法定人数规则（多数共识）

为防止脑裂，Elasticsearch 强制执行多数共识规则，要求最少数量的投票节点同意任何集群状态变更。这个最小值是法定人数，计算如下：

$$\text{法定人数} = \lfloor (\text{投票节点数} / 2) \rfloor + 1$$

通过要求严格多数，如果网络分区，只有较大的侧（拥有多数）能达到法定人数并继续运行。较小的侧无法选举主节点，将停止并等待网络连接恢复，从而避免向分区段写入数据。

投票主节点数量 (N)	所需法定人数 (N/2 + 1)
3	2
5	3
7	4

最佳实践警告： 始终部署奇数个主节点候选节点（例如，三个或五个）。部署偶数个（例如，四个）提供与前一个奇数（三个）相同的容错能力，但需要更多资源。例如，4 节点投票集群需要 3 票 (N/2+1)，意味着它只能容忍一个故障，与 3 节点集群相同，但多使用一台服务器。

配置专用主节点

对于生产环境，三个专用主节点候选节点是常见的基线。这可以将搜索和索引负载与协调工作分离。小型开发集群可以运行混合角色，但重要的集群不应让繁重的聚合或摄取峰值使当选主节点资源枯竭。

节点配置示例（专用主节点）

要将节点配置为主节点候选但不存储数据或运行摄取管道，请在 elasticsearch.yml 中使用以下角色：

# 节点 1：专用主节点
node.name: es-master-01
node.roles: [master]

# 将传输绑定到私有网络，并使用防火墙/安全组限制访问。
# network.host: 10.0.0.1

节点配置示例（专用数据节点）

相反，专用数据节点应被阻止参与主节点选举过程：

# 节点 4：专用数据节点
node.name: es-data-04
node.roles: [data]

# 如果未指定角色，Elasticsearch 会分配该版本的默认角色集。

集群发现设置

所有节点必须配置为使用 discovery.seed_hosts 设置找到相同的主节点候选节点集合。此设置列出 Elasticsearch 可以尝试联系其他节点以加入集群的网络地址。

# 集群中所有节点的通用设置
discovery.seed_hosts: ["10.0.0.1:9300", "10.0.0.2:9300", "10.0.0.3:9300"]

此列表应包含主节点候选节点（es-master-01、es-master-02、es-master-03 等）的地址。

排查选举问题

如果集群未能选举主节点，它通常会进入'红色'或'黄色'状态，并记录持久性错误。常见原因包括：

问题	描述与解决方案
网络问题	由于防火墙规则、路由问题、DNS 问题或高延迟，节点无法通信。传输端口（通常为 9300）必须在节点之间可达。HTTP（通常为 9200）用于客户端/API 访问，不是选举通道。
配置不匹配	cluster.name 不正确或 discovery.seed_hosts 未指向正确的主节点候选节点。验证所有节点使用相同的设置。
法定人数丢失	太多投票节点同时失败，例如三主节点设置中两个故障。如果缺失节点永久消失，请谨慎使用投票配置排除 API，并在确认故障模式后操作。
磁盘 I/O	主节点的磁盘 I/O 饱和，阻止其快速发布集群状态，导致超时和重复选举。

检查投票配置

您可以使用集群 API 检查当前投票配置：

GET /_cluster/state?filter_path=metadata.cluster_coordination

此输出确认哪些节点当前计入法定人数，确保您的配置符合容错目标。

最安全的生产模式是平淡无奇的：三个专用主节点候选节点位于不同的故障域，稳定的传输网络，正确的种子主机，以及仅使用一次的 cluster.initial_master_nodes。当选举失败时，抵制立即重启所有节点的冲动。阅读日志，确认哪些主节点候选节点可以看到彼此，并一次做一个受控的更改。