ElasticSearch 5学习(7)——分布式集群学习分享2
前面主要学习了ElasticSearch分布式集群的存储过程中集群、节点和分片的知识（ElasticSearch 5学习(6)——分布式集群学习分享1），下面主要分享应对故障的一些实践。
应对故障
前面说了很多关于复制分片可以应对节点失效，很好保证集群的安全性，下面我们可以尝试杀掉第一个节点的进程，我们的集群变化成如下（所有的操作都是ElasticSearch自动处理）：
我们杀掉的节点是一个主节点。一个集群必须要有一个主节点才能使其功能正常，所以集群做的第一件事就是各节点选举了一个新的主节点：Node 2。
主分片1和2在我们杀掉Node 1时已经丢失，我们的索引在丢失主分片时不能正常工作。如果此时我们检查集群健康，我们将看到状态red：不是所有主分片都可用！
幸运的是丢失的两个主分片的完整拷贝存在于其他节点上，所以新主节点做的第一件事是把这些在Node 2和Node 3上的复制分片升级为主分片，这时集群健康回到yellow状态。这个提升是瞬间完成的，就好像按了一下开关。
为什么集群健康状态是yellow而不是green？我们有三个主分片，但是我们指定了每个主分片对应两个复制分片，当前却只有一个复制分片被分配，这就是集群状态无法达到green的原因，不过不用太担心这个：当我们杀掉Node 2，我们的程序依然可以在没有丢失数据的情况下继续运行，因为Node 3还有每个分片的拷贝。
如果我们重启Node 1，集群将能够重新分配丢失的复制分片，集群状况与上一节的 图5：增加number_of_replicas到2 类似。如果Node 1依旧有旧分片的拷贝，它将会尝试再利用它们，它只会从主分片上复制在故障期间有数据变更的那一部分。
故障实践1
上面是关于ElasticSearch在遇到故障时候的理论部分，下面我们开始实际操作。
查看目前集群状态
我们回顾一下之前的blogs索引，在结束最后的状态：
PUT /blogs
{
"settings" : {
"number_of_shards" : 3, (主分片个数)
"number_of_replicas" : 2, (每个主分片的复制分片个数)
}
}
切断节点
为了模拟这种情况，在我们自己的电脑上，直接用kill命令即可：
查看集群的状态
很正确，就是理论内容所描述中间会存在red的瞬间。
等·
等·
等·
可是等了半天，结果一直是red状态的结果，这是为什么呢？注意看提示无法连接到http://localhost:9200，突然意识到，我们关闭的节点正好是9200端口的Node 1节点。所以我们需要修改kibana.yml配置文件的elasticsearch.url项：
再次查看集群的状态
终于，可以看到我们想要的结果，ElasticSearch集群正如上面所说的重新选Node 2作为新的主节点：
我们还可以注意到集群的健康状况从绿色变成了黄色，这是因为我们设置每个主节点2个复制分片，而现在还有一个复制节点处于不可用状态。
故障实践2
回顾之前的一个集群状态，blogs索引只设置一个复制分片的情况下：
如果在这种情况下，我们把其中的任何一个节点关闭，会出现什么效果呢？我们分析看，至少我们关闭任何一个节点都能保所有的分片都还能存在。比如我们删除Node 2节点，正常情况下，Node 2中的分片0作为主分片被删除后，主节点会分配Node 1节点下复制分片0重新作为主分片0，而Node 2中的分片1本身是复制分片，直接删除即可，但是ElasticSearch集群，除此之外还会不会有其他操作。那就是，从新在两个节点中把所有的复制分片都置为可用。下面我们看结果：
首先我们看到的和我们前面分析的一样，主节点会分配Node 1节点下复制分片0重新作为主分片0，但是也可以看到现在集群的健康状况是黄色，因为存在复制节点处于不可用状态。我们继续等。。。：
终于我们可以看到，ElasticSearch集群确实会把所有的复制节点又都置为可用状态，因为节点存在它不拥有的分片，就可以创建这个节点，最大程度的保证高可用性。
实践注意点
在测试过程中，ElasticSearch集群确实可以帮助我们重新分配分片的状态，但是需要注意的是，每次一个节点关闭的时候，集群需要一定的时间去管理，如果这时候我们很快的将两个节点关闭，ElasticSearch集群将无法挽救回没有主分片，也没有复制分片的那些数据，所以测试的时候需要知道这一点。
不过这也反映我们在学习分享1中描述的，如果我们的复制节点足够多的话，我们可以保证高可用的能力就却强大，因为允许节点故障的次数更多，而且我们的节点故障以后，运维又可以将节点重启，继续斗争！！！
总结
现在我们对分片如何使Elasticsearch可以水平扩展并保证数据安全有了一个清晰的认识。真正感受到Elasticsearch天生就是分布式的，确实很强大！
转载请注明出处。
作者：wuxiwei
出处：http://www.cnblogs.com/wxw16/p/6188560.html
