ES的高可用

es最小高可用集群组成

  • At least three master-eligible nodes(至少三个符合主节点条件的节点)
  • At least two nodes of each role(每个角色至少有两个节点)
  • At least two copies of each shard (one primary and one or more replicas) (每个分片至少有两个副本(一个主副本和一个或多个副本))

为什么需要 3 个 master 节点?

因为当一个master节点挂掉之后,剩余的两个仍符合选举的"多数"从而完成选举

为什么每个角色至少需要 2 个节点?

因为一个该角色的节点挂掉之后,另一个可以替代

为什么每个分片至少需要两个副本?

因为主分片(primary shard) 和副本分片(replica shard) 不能分布在同一个节点,这样即使当一个节点失败导致分片数据丢失,还可以从另一个节点上的分片来恢复数据。保证数据安全。

不同节点数的集群,需要不同的不同配置以及健壮性对比:

|-----------------------------------|------------------|-------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------|
| 集群节点数 | 备注 | 角色分配 | 配置要求 | 健壮性 | client 连接串配置要求 |
| 1 个同配置节点 | 生产不推荐 | 该节点分配所有角色 | * index.number_of_replicas设置为0,这样集群才能green。 | 不能容忍节点失败,一旦失败只能从快照(snapshot)进行恢复。所以建议定时进行snapshot | |
| 2 个同配置节点 | 生产不推荐 | 2个节点都分配为除候选主节点外的其他角色。 | * index.number_of_replicas 只能设置为≤1,否则集群无法变成green; * 将其中的一个节点(node A)设置为候选master节点,另一个节点(node B)配置:node.master: false。这样node B挂了,也不影响集群的master选举。 | 只能容忍配置了node.master: false的节点挂掉,只不过这时集群为yellow,手动将index.number_of_replicas 设置为0,就变成单节点的es集群了,也能变成green | 不要只配置其中的1个节点,而应该使用类似负载均衡将请求分发到两个节点上。 |
| 2 高配置节点 +1 个低配置节点 | 资源紧张时可以这么用 | 1)2个高配置的节点:分配data,master等主要角色,不能配置voting_only角色; 2)1个低配置节点:分配voting_only角色(只用于选主时进行投票,不接受业务请求) | | 可以容忍配置了node.roles: master的任何一个节点的失败。 | 将客户端请求负载到2个高配置的节点(分配了node.role:master) |
| 3 个同配置节点 | 生产推荐 | 所有节点都分配所有角色 | | * 挂掉任何一个节点,集群不影响; * 挂掉2个节点,集群变yellow,如果将index.number_of_replicas 设置为0,集群变green | 将客户端请求负载到3个节点 |
| 多余 3 个节点 | 生产推荐(适应用大业务量的场景) | 1)建议节点专用,每个节点使用专用的角色。当然提高资源利用率,也可以考虑将节点分配几个角色(考虑负载即可) 2)候选主节点限制为3个能满足绝大多数的要求。因为太多主节点会有导致投票时间过长。 | | | |

相关推荐
Elastic 中国社区官方博客35 分钟前
5 分钟内将 56 页扫描文档转化为带引用的答案:面向搜索无法读取的文档的检索增强生成流水线
大数据·运维·人工智能·elasticsearch·搜索引擎·信息可视化·全文检索
Elasticsearch1 天前
5 分钟内将 56 页扫描文档转化为带引用的答案:面向搜索无法读取的文档的检索增强生成流水线
elasticsearch
core5122 天前
Elasticsearch 车牌号片段搜索:n-gram 倒排索引实战方案
elasticsearch·n-gram·索引·倒排索引·号牌·片段
এ慕ོ冬℘゜2 天前
ES Promise.all/ Promise.race
前端·javascript·elasticsearch
Sayai2 天前
Elasticsearch 日志写入链路调优实战:ingest pipeline 补时间戳、时区偏移修复与按值类型路由(附 translog 实测)
大数据·运维·elasticsearch·搜索引擎·性能优化
总爱写点小BUG2 天前
git-tidy:一个把「提交规范治理」做成闭环的 Git 桌面客户端
大数据·elasticsearch·搜索引擎
Elastic 中国社区官方博客3 天前
我们如何通过 70 多个拉取请求,将 OpenTelemetry Java agent 迁移到 invokedynamic
java·大数据·开发语言·elasticsearch·搜索引擎·全文检索·es
BreezeJiang4 天前
写了 Dockerfile 却没生效:ES + Kibana 的 compose 配置里,藏着三个反直觉的点
elasticsearch
Elasticsearch4 天前
Elastic 计划利用 NVIDIA RTX GPU 将 Jina 模型推理速度提升至 8 倍
elasticsearch
Elastic 中国社区官方博客4 天前
告别繁琐控制台:Kabanos 如何将 MongoDB Compass 的易用性带入 Elasticsearch
大数据·数据库·mongodb·elasticsearch·搜索引擎·全文检索