Elasticsearch 的 master 节点和 data 节点有什么区别？
一句话回答
Master 节点管集群——负责元数据维护、索引创建删除、分片分配和主节点选举；Data 节点管数据——负责文档的存储、索引写入和查询执行。生产环境中两者必须分离部署，否则数据节点的高负载会拖垮集群管理，导致脑裂甚至集群不可用。
核心职责对比
| 维度 | Master 节点 | Data 节点 |
|---|---|---|
| 核心任务 | 集群状态维护、元数据管理 | 文档存储、查询执行 |
| 是否存用户数据 | 否，仅存集群元信息（mapping、settings） | 是，以分片形式存储索引数据 |
| CPU 消耗 | 低（管理任务轻量） | 高（查询/索引密集） |
| 内存消耗 | 低（元数据体量小） | 高（依赖文件系统缓存） |
| 磁盘 I/O | 极低 | 高（读写分片数据） |
| 配置方式 | node.roles: [master] | node.roles: [data]（7.x 后可细分为 data_content/data_hot/data_cold/data_frozen） |
Master 节点详解
Master 节点是集群的协调中心，具体职责：
- 集群状态管理：维护全局 ClusterState，包括索引元数据、分片路由表、节点列表等。任何索引操作（创建/删除/映射变更）都由 master 节点发起状态变更，再广播给所有节点。
- 分片分配：决定每个分片分配到哪个数据节点，平衡负载并在节点故障时触发分片迁移。
- 主节点选举：集群启动或当前 master 失联时，候选 master 节点通过投票选出新 master。选举要求获得 N/2+1 票（N 为候选节点数），因此推荐部署 3 个专用 master 节点形成多数派。
生产配置示例：
node.roles: [master] cluster.initial_master_nodes: ['master-1', 'master-2', 'master-3']
cluster.initial_master_nodes 只在集群首次启动时使用，用于引导选举。集群形成后，新节点加入不需要再配置此参数。
Data 节点详解
Data 节点承载实际的数据读写压力：
- 文档索引：接收写入请求，将文档存入对应分片的 Lucene 段。
- 查询执行：在本地分片上执行搜索、聚合操作，返回结果给协调节点。
- 副本同步：维护主分片的副本分片，保证数据冗余和查询吞吐量。
ES 7.x 之后，Data 角色进一步细分为：
| 子角色 | 用途 |
|---|---|
data_content | 存储常访问的内容索引 |
data_hot | 存储时序类热点数据，需 SSD |
data_warm | 存储访问频率降低的时序数据 |
data_cold | 存储很少访问的冷数据，可用 HDD |
data_frozen | 存储极少访问的归档数据 |
这种分层存储架构是冷热分离策略的基础，可以大幅降低存储成本。
为什么生产环境必须分离
混合角色（node.roles: [master, data]）在小规模测试中可用，但在生产环境会带来严重问题：
- 性能干扰：Data 节点处理重查询时 CPU 飙升，master 的集群协调任务被阻塞，导致心跳超时、选举延迟，甚至触发误判的故障转移。
- 脑裂风险：如果 master 角色所在节点因数据负载过高而假死，其他节点可能发起重新选举。若网络分区导致旧 master 仍认为自己在任，就会出现双 master——即脑裂。ES 7.x 后已移除
discovery.zen.minimum_master_nodes参数，改由集群自动管理多数派，但这依赖于 master 节点能够及时响应。 - 故障域重叠：Data 节点磁盘满或 OOM 时，同时担任的 master 角色也会崩溃，集群失去管理能力，数据分片无法迁移，整个集群可能瘫痪。
验证节点角色是否正确分离：
curl -XGET 'http://localhost:9200/_cat/nodes?v&h=name,roles'
输出中每个节点应只显示单一角色（m 或 d），避免出现 md 混合。
协调节点补充
除了 master 和 data，还有一类容易忽略的角色——协调节点（Coordinating Node），配置为 node.roles: []（空角色）。它不存数据、不参与选举，只负责接收客户端请求、分发到相关 data 节点、合并结果后返回。在查询聚合场景下，专用协调节点可以避免 data 节点承担结果合并的内存开销。
追问：Master 选举过程是怎样的？
ES 7.x 使用基于 Raft 的选举协议。当集群中 master 失联时，候选节点进入选举流程：先按 nodeId 排序确定优先级，优先级最高的候选节点发起投票，其他节点收到投票请求后检查任期号和日志完整性，决定是否投票。获得多数票（N/2+1）的节点成为新 master。整个过程通常在秒级完成，期间集群处于只读状态。
选举触发条件包括：master 节点宕机、网络分区导致心跳超时（默认 30s）、master 主动卸任。生产环境中，3 个 master 节点可容忍 1 个故障，这是最低推荐配置。