Elasticsearch的集群容错机制以及选举机制

ES的容错机制

假设场景,现在一共有9个shard,其中3个shard 6个replica,一共有三个es节点,node1是master节点,具体如下图:

如果下载master节点挂掉,shard1,replica2-1,replica3-1 节点会丢失,在master节点挂掉的一瞬间 shard1就没了,此时shard1就不是active状态了,集群中不是所有的primary shard都是active状态了,所以集群的状态会在这一瞬间变为red

容错第一步

集群会自动选举另外一个node成为新的master,比如node2,承担起master的责任来

容错第二步

新的master会将丢失掉的primary shard的某个replica shard提升为primary shard,此时集群的状态是yellow了,因为所有的primary shard都变成了活跃状态, 但是因为少了一个replica shard 所以不是所有的replica shard都是active状态了

容错第三步

新的master重启之前宕机的节点,将丢失的副本都拷贝到该node上去,而且该node会使用宕机之前已有的shard的数据,只是同步一下宕机后发生的修改.此时集群的状态变为green,因为所有的primary shard 和 replica shard都是active状态了

ES扩容机制

shard&replica机制

1. 一个index可以包含多个shard, index中的数据会均匀的分配到每个shard中,就是es分片的机制.
2. 每个shard都是一个最小的工作单元,承载部分数据,es是基于Lucene去开发的,其实每个shard就是Lucene的实例,有完整的建立索引和处理请求的能力
3. 增减节点的时候shard会自动在nodes中负载均衡,比如一共有6个es节点,但是有7个shard 这个时候其中的一个es节点会有两个shard,如果这时候集群中再加进来一个es节点,那么承载两个shard的节点会分配一个shard到新加的节点上去
4. 每个document肯定只会存在于某一个primary shard中以及其对应的replica shard中,不可能同时存在于两个 primary shard中
5. replica shard是primary shard的副本,负责容错,以及承担读请求负载.
6. primary shard的数量在创建索引的时候就固定了,replica shard的数量可以随时修改
7. 一个index中primary shard的默认数量是5,replica shard默认是1(就是每个primary shard都有1个 replica),默认有10个shard 5个primary shard和5个replica shard
8. primary shard不能和自己的replica shard放在同一个节点上,如果放在同一个节点上 当这个节点宕机的时候primary shard和replica shard都丢失了,就起不到容错的作用, 同一个节点上一个放其他节点的replica shard

两个node环境下replica和shard的分配

集群中有两个es节点,创建一个index,设置有3个shard每个shard对应一个replica,如下图:

新添加一个节点到集群中

es集群会自动做负载均衡,如果我们现在加一个es节点到集群中来的话,es会按照一定的规则(一个shard和它对应的replica不会被分配到同一个节点上去)将部分shard分配到新的节点上去,如图:

集群选举

1. Master选举（假如宕机节点是Master）

   1. 脑裂：可能会产生多个Master节点

   2. 解决：discovery.zen.minimum_master_nodes=N/2+1

2. Replica容错，新的（或者原有）Master节点会将丢失的Primary对应的某个副本提升为Primary

3. Master节点会尝试重启故障机

4. 数据同步，Master会将宕机期间丢失的数据同步到重启机器对应的分片上去