primary shard 和 replica shard机制
(1):index包含多个shard；
(2):每个shard都是一个最小的工作单元，承载部分的数据，Lucene实例，完整的简历索引和处理请求的能力；
(3):增减节点时，shard会自动在nodes中负载均衡；
(4):primary shard和replica shard，每一个doc只会存在某一个primary shard以及其对应的replica shard中，不可能存在于多个primary shard中；
(5):replica shard是primary shard的副本，负责容错，以及承担读请求负载（通常情况可以让primary shard负责写，replica shard负责读，来实现读写分离）；
(6):primary shard 的数量在创建索引的时候就固定了，replica shard的数量可以随时修改；
(7):primary shard的默认数量是5，replica shard默认是1，默认有10个shard，其中5个primary shard以及5个replica shard；
(8):primary shard和replica shard不能和自己的replica shard 放在一个节点中(这样规定是为避免节点宕机的时候，primary shard和replica shard数据都都丢失，起不到容错的作用)，但是可以和其他的primary shard的replica shard放在同一个节点中；
极限扩容
就像上面说的primary shard 在创建的时候就已经固定了，不可以再修改。也就是说如果我在创建的时候设置了primary shard是3（6个shard，3 primary，3 replica），最多扩容到6台机器，每个shard可以占用单台服务器的所有资源，性能最好。那如果我们的超出了上面所说的扩容极限了怎么办呢？primary shard不是不能修改么？
是的，primary shard 在创建后是不能修改的，但是replica shard可以添加啊，我们可以创建9个shard（3primary，6 replica），将服务器扩容到9台机器，吞吐量会大大增加，是3台服务器的三倍，当然为了提高容错率也可以在此基础上在每台服务器上部署多个shard（primary和replica不能在同一台服务器上）
容错机制
- master node宕机后，会自动重新选举master，此时为red；
- replica容错：新master是将replica提升为primary shard，此时为yellow（因为replica被升级为primary了，此时replica并不齐全）；
- 重启宕机node，master copy replica到该node，但是该node使用原有的shard并同步宕机后的修改（即仅同步宕机后丢失的数据），此时为green；
