elasticsearch高可用集群需系统性设计，核心是角色分离、合理分片、跨故障域部署和健康保障；主节点仅管元数据，数据节点专注存储，最小3台专用主节点+至少2台数据节点，关键配置如cluster.name、discovery.seed_hosts等须显式设置。
搭建Elasticsearch高可用集群不是简单加几个节点，而是围绕容错、可扩展、易运维三个目标系统性设计。核心在于角色分离、合理分片、跨故障域部署和健康保障机制。
节点角色必须分离，避免脑裂风险
主节点（Master-eligible）只管集群元数据，不存数据；数据节点（Data）专注存储与查询；小规模集群（≤5节点）可合并角色，但master和data绝不能共存于同一节点。推荐最小配置：
- 3台专用Master节点：每台8核CPU、32GB内存、JVM堆设为16GB，仅启用
node.master: true - 至少2台Data节点：按数据量扩展，单节点建议64GB+内存、NVMe SSD、JVM堆≤31GB（留1GB给Lucene）
- 可选Coordinating节点：专用于请求分发与结果聚合，减轻Data节点压力，适合高并发搜索场景
关键配置项必须显式设置
默认配置无法支撑生产高可用，以下参数需在elasticsearch.yml中明确定义：
-
cluster.name：全集群统一名称，避免误加入其他集群 -
node.name：每个节点唯一标识，建议用主机名或带角色前缀（如master-01） -
discovery.seed_hosts：列出所有Master候选节点的host:port，例如["192.168.1.10:9300", "192.168.1.11:9300", "192.168.1.12:9300"] -
cluster.initial_master_nodes：首次启动时参与选举的节点名列表，仅初启时需要，值为["master-01", "master-02", "master-03"] -
node.roles：明确指定角色，如[master]或[data]，禁用隐式角色
分片与副本策略直接影响可用性
高可用不仅靠节点冗余，更依赖数据级冗余：
- 主分片数（
number_of_shards）按单分片20–50GB目标容量预估，避免后期无法调整 - 副本数（
number_of_replicas）至少设为1，确保任意一个Data节点宕机时，所有分片仍有副本来提供服务 - 新建索引时强制指定：
PUT /logs-2026-09 {"settings": {"number_of_shards": 6, "number_of_replicas": 1}} - 使用ILM（索引生命周期管理）自动滚动和删除，防止单索引无限膨胀
部署位置要跨故障域
节点物理或逻辑隔离是防止单点失效的根本手段：
- 云环境：3个Master节点分别部署在不同可用区（AZ），Data节点也尽量分散
- IDC环境：节点分布在不同机柜、不同交换机、不同供电线路下
- Kubernetes部署：通过
nodeAffinity和topologySpreadConstraints确保Pod不集中调度到同一节点或区域 - 禁用
gateway.recover_after_nodes等过时参数，Elasticsearch 8.x起由集群状态自动协调恢复时机
