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个同配置节点 |
生产不推荐 |
该节点分配所有角色 |
|
不能容忍节点失败,一旦失败只能从快照(snapshot)进行恢复。所以建议定时进行snapshot |
|
2个同配置节点 |
生产不推荐 |
2个节点都分配为除候选主节点外的其他角色。 |
|
只能容忍配置了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个同配置节点 |
生产推荐 |
所有节点都分配所有角色 |
|
将客户端请求负载到3个节点 |
|
多余3个节点 |
生产推荐(适应用大业务量的场景) |
1)建议节点专用,每个节点使用专用的角色。当然提高资源利用率,也可以考虑将节点分配几个角色(考虑负载即可) 2)候选主节点限制为3个能满足绝大多数的要求。因为太多主节点会有导致投票时间过长。 |