[Elasticsearch] 集群工作

本文翻译自Elasticsearch官方指南的life
inside a cluster一章。

添加故障转移(Failover)功能

仅仅执行一个节点意味着可能存在着单点失败(Single point of failure)的问题 - 由于没有冗余。幸运的是。解决问题我们仅仅须要启动还有一个节点。

启动第二个节点

为了试验当你加入第二节点时会发生什么，你须要像启动第一个节点那样启动第二个节点(參见执行ES)。能够在同一个文件夹下
- 多个节点可以共享同样的文件夹。

仅仅要第二个节点也拥有和第一个节点同样的cluster.name(參见./config/elasticsearch.yml文件)，它就行自己主动地被识别和加入到第一个节点所在的集群中。

假设不是这种话，检查日志来得到错误信息。错误原因可能是你的网络禁用了多播(Multicast)，或者存在防火墙阻止了节点间的通信。

假设我们启动了第二个节点。如今的集群会像以下展示的那样：

如今第二个节点增加到了集群中，而且三个副本分片也被分配到了该节点上 - 这三个副本各自是三个主分片的副本。这意味着，此时我们假设失去了两个节点中的不论什么一个，都不会丢失数据。

不论什么被索引的文档首先都会被保存到主分片上，然后通过并行地方式被复制到相关联的副本分片上。

这保证了该文档可以通过主分片或者随意一个副本分片获取。

这个时候集群的健康状态会显示为green。表示全部的6个分片(3个主分片和3个副本分片)都是处于活动状态的：

{

   "cluster_name":          "elasticsearch",

   "status":                "green",

   "timed_out":             false,

   "number_of_nodes":       2,

   "number_of_data_nodes":  2,

   "active_primary_shards": 3,

   "active_shards":         6,

   "relocating_shards":     0,

   "initializing_shards":   0,

   "unassigned_shards":     0

}

此时。我们的集群不仅可以运行正常的功能，也具备了高可用性。

水平扩展(Scale Horizontally)

随着应用的扩展，ES怎样对集群进行扩展呢？假设我们启动了第三个节点，那么集群可能会像例如以下所看到的的那样又一次组织自身的结构：

节点1和节点2中各有一个分片如今被移动到了新的节点3中。此时每一个节点上都有2个分片，而不是原来的3个。这意味着每一个节点上的硬件资源(CPU，RAM。I/O)可以被更少的分片所享有，从而提高每一个分片的性能。

每一个分片本身就是一个完整的搜索引擎，它可以全然地利用一个节点上的全部资源。因此，在拥有6个分片(3主，3副本)的情况下，我们的集群最多可以扩展到6个节点，此时每一个节点上仅仅有1个分片。因此每一个分片就行拥有该节点100%的资源。

假设继续扩展

假设我们想扩展到多于6个节点呢？

在建立索引的时候，主分片的数量就被固定下来了。实际上，这个数量决定了该索引中可以存储的最大数据量。(实际数量取决于你的数据特征和你的硬件)。

可是，对于读请求 - 搜索或者获取文档 - 可以被主分片或者副本分片处理，因此当数据有越多的副本，也就意味着搜索的吞吐量可以更高。

副本分片的数量可以在一个活动的集群上动态改动，这就同意我们可以依据须要进行集群规模的调整。让我们将当前的副本分片数量从1调整到2：

PUT /blogs/_settings

{

   "number_of_replicas" : 2

}

调整后的组织例如以下所看到的：

如今blogs索引中就存在9个分片了：3个主分片和6个副本分片。这意味着如今我们可以最多扩展到9个节点。每一个节点中仅仅有一个分片。这可以让搜索性能相比原来的3个节点。提升3倍。

NOTE 当然，仅添加副本分片的数量而不添加节点的数量是不会对性能有不论什么提高的。这是由于在该情况下。每一个分片仅仅会得到其所在节点的一部分资源。

你须要添加硬件资源来提高吞吐量。

可是这些新加入的副本无疑添加了数据的冗余：像上图那样配置的话，我们如今可以做到即便丢失了两个节点也不会丢失数据。

应对失败

我们说过ES可以应对节点失败的情况，所以让我们试一试。假设我们杀死了第一个节点。那么此时的节点会变成这样：

被杀死的节点是主节点(Master Node)。

一个集群中必须有一个主节点来保证集群可以正常工作，所以第一件事就是剩下的节点会选出一个新的主节点：例如说节点2。

当我们杀死节点1的时候。同一时候也丢失了主分片1和主分片2，当缺少了主分片的时候索引是不能正常工作的。

此时假设检查集群的健康状态，我们会毫无疑问的得到一个red：不是全部的主分片都处于活动状态！

幸运的是，丢失的两个主分片的副本分片完善无损的存在于其他的节点上。所以被选为主节点的节点2首先须要做的就是提升节点2和节点3中的对应副本分片，让它们成为主分片。此时集群的状态就会变成yellow：全部的主分片又处于活动状态了。对于分片的提升是会马上启动的，就像扳动开关那样。

那么我们的集群为什么是yellow。而不是green？我们有3个主分片，可是我们指定了每一个主分片须要有2个副本分片，可是当前我们仅仅能分配1个副本分片(译注：由于此时我们仅仅有两个节点。同样数据不能同一时候存储于一个节点上)。

这组织了集群的状态变为green，可是这里我们并不须要过分操心：如果我们杀死了节点2。应用还是可以在不丢失数据的情况下继续执行。由于节点3还是保存了每一个分片的拷贝。

假设我们重新启动节点1。此时集群又可以对尚未分配的副本分片进行分配了。因此就恢复到了这样的组织结构：

假设节点1中仍然存在之前的分片。那么它会尝试继续使用它们，仅仅只是须要从相应的主分片中将最新的变化数据拷贝回来。

现在你应该ES如何使用碎片来实现膨胀的程度和如何理解的数据的安全性。稍后我们将介绍一些关于片等细节。