1、shard&replica知识点清单
(1)什么是shart?
每个shard都是一个最小工作单元,承载部分数据,lucene的实例,拥有完整的建立索引和处理请求的能力
(2)primary shard和replica shard?
primary shard负责读写请求,replica shart,负责容错,以及承担读请求负载,是primary shart副本。
每个document肯定只存在于某一个primary shard以及其对应的replica shard中,不可能存在于多个primary shard
(3)增减节点时,shard会自动在nodes中负载均衡
(4)primary shard的数量在创建索引的时候就固定了,replica shard的数量可以随时修改
(5)primary shard的默认数量是5,replica默认是1,默认有10个shard,5个primary shard,5个replica shard
(6)primary shard不能和自己的replica shard放在同一个节点上(否则节点宕机,primary shard和副本都丢失,起不
到容错的作用),但是可以和其他primary shard的replica shard放在同一个节点上
(7)index和shart的关系
一个index部署到多个shart上,和多个index部署在多个shart对比。
比如:一个公司有两套系统,一套是portal门户网站的,一套是后台的员工信息管理的系统,如果将这两套系统的
数据的index建立在了同一个集群中,也就是说一个shart中包含了多个index的数据,当员工信息管理系统在月末
结算工资的时候,需要大量计算,查询,分页,严重占用cpu、内存资源,如果此时的门户网站上有用户访问,
没有资源给给它分配就会阻塞,这样网站的可用性就降低了,所以都使用的方式是,一个index部署到多个shart
中,不让多个index共享shart
2单node环境下的shart分配
1.创建index 3个primary shard,3个replica shard
PUT /test_index
{
"settings" : {
"number_of_shards" : 3, //shart的数量
"number_of_replicas" : 1 //每个shart的replica shart的数量
}
}
2.集群status是yellow 因为只会将3个primary shard分配到仅有的一个node上去,
另外3个replica shard是无法分配的
3.集群可以正常工作,但是一旦出现节点宕机,数据全部丢失,而且集群不可用,无法承接任何请求
3双node环境下的shart分配
当使用双节点的时候,起码可以保证一台服务宕机后,另一台服务可以继续提供服务
4三node环境下的shart分配
(1)方案一
6个shard,3 primary,3 replica允许一个node宕机,还可以继续提供服务
(2)方案二
9个shard,3 primary,6 replica允许二个node宕机,还可以继续提供服务
(3)瓶颈
如果有3个primary shart 和3个replica shart而此时有9台服务器的话,primary shart的数量分配后是不可改变的,只能增加 3个replica shart ,每台机器上都是一个shart,这样整体性能就会提高