1、shard&replica机制再次梳理
（1）index包含多个shard
（2）每个shard都是一个最小工作单元，承载部分数据，都是一个lucene实例，拥有完整的建立索引和处理请求的能力
（3）增减节点时，shard会自动在nodes中负载均衡
（4）primary shard和replica shard，每个document肯定只存在于某一个primary shard以及其对应的replica shard中，不可能存在于多个primary shard
（5）replica shard是primary shard的副本，负责容错，以及承担读请求负载
（6）primary shard的数量在创建索引的时候就固定了，replica shard的数量可以随时修改
（7）primary shard的默认数量是5，replica默认是1，例如默认有10个shard，其中5个是primary shard，5个是replica shard
（8）primary shard不能和自己的replica shard放在同一个节点上（否则节点宕机，primary shard和副本都丢失，起不到容错的作用），但是可以和其他primary shard的replica shard放在同一个节点上
2、单node环境下创建index是什么样子的
（1）单node环境下，创建一个index，有3个primary shard，3个replica shard
（2）集群status是yellow
（3）这个时候，只会将3个primary shard分配到仅有的一个node上去，另外3个replica shard是无法分配的
（4）集群可以正常工作，但是一旦出现节点宕机，数据全部丢失，而且集群不可用，无法承接任何请求
创建索引：索引名为test_index,3个primary shard，每个primary shard拥有1个replica shard，结果就是 3个primary shard，3个replica shard
PUT /test_index
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
3、2个node环境下replica shard是如何分配的
（1）replica shard分配：3个primary shard，3个replica shard，1 node
（2）primary与 replica的数据是同步
（3）读请求：primary/replica都会承载客户端请求
图解2个node环境下replica shard是如何分配的
4、Elasticsearch容错机制
假设es集群有3个node，9个shard，master节点宕机，cluster status会变为red，开始容错处理，步骤：
（1）master选举，自动选举另外一个node成为新的master，承担起master的责任来
（2）：新master，将丢失掉的primary shard的某个replica shard提升为primary shard，此时primary shard全部变为了active状态了，但是少了一个replica shard，不是所有的replica shard都是active，所以此时cluster status会变为yellow
（3）重启故障的node，新的master会将缺失的副本都copy一份到该node上去，而且该node会使用之前已有的shard数据，只是同步一下宕机之后发生过的修改
es容错机制处理
网友评论