Elasticsearch-6-shard&replica机制

发表于 | 分类于

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

单个es节点环境下创建index

比如我们现在创建一个index 设置有3个primary shard 每个 shard对应一个replica
创建代码如下:

1
2
3
4
5
6
7
PUT /test_index
{
   "settings" : {
      "number_of_shards" : 3,
      "number_of_replicas" : 1
   }
}

这时候es集群的状态是yellow,而且只会将3个primary shard分配到这个es节点上去,对应的3个replica是不会被创建的,就是上面提到的 shard自己的replica是不能跟自己放在一起的,此时集群可以正常工作,但是这个节点一旦宕机的话,数据就会全部丢失,而且集群不可用,无法承接任何请求

两个es节点环境下shard的分配

在上面单节点的环境下如果在添加一个es节点到集群中, 此时新添加进来的节点会承载之前节点的primary shard的replica shard, primary shard 和 replica shard中的数据是一样的, replica 和 primary shard 同样可以处理读请求.