集群不依赖zookeeper，自己具有选取master的能力，master的机器最好为奇数台，防止“脑裂”
集群组成
- Master：创建和删除索引。 从集群中添加或删除一台节点，无需掌管文档级的变更和索引
- Node：掌管文档级的变更和索引，分为：数据节点、非数据节点;
容灾
如果cluster有一个节点，添加一个index blogs，执行如下语句
PUT /blogs
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
数据存储形态为：
单节点.png
集群的状态有绿、黄（replica shard没有完全被分配）、红（primary shard没有完全被分配），此时集群状态为黄，replica shard还没有被分配。
单node如果失败，数据就不可用，此时添加一个node，一个节点失败，数据还可使用。
failover.png
水平扩展
如果再添加一个node，cluster自动负载均衡，无需重启集群，数据在cluster中分布如下：
水平扩展.png
主分片的数量在创建索引时已经确定。但主分片或者复制分片都可以处理读请求——搜索或文档检索，所以数据的冗余越多，我们能处理的搜索吞吐量就越大。
复制分片的数量可以在运行中的集群中动态地变更，这允许我们可以根据需求扩大或者缩小规模。让我们把复制分片的数量从原来的1 增加到2：
PUT /blogs/_settings
{
"number_of_replicas" : 2
}
2_replica_shard.png
故障恢复
如果杀掉node1，集群健康状态为红：
no_node1.png
选举master，Node2选为master
在Node 2和Node 3上的复制分片升级为主分片，这时集群健康回到
yellow状态
如果我们重启Node 1，集群将能够重新分配丢失的复制分片,如果Node 1依旧有旧分片的拷贝，它将会尝试再利用它们，它只会从主分片上复制在故障期间有数据变更的那一部分。
