Elasticsearch * cluster internal workings

Elasticsearch cluster internal workings

用 Elasticsearch 的时候能够长时间都没必要担忧 shard、 replicate、 failover ——可是它会帮助你理解Elasticsearch内部的工做流程

Elasticsearch 经过增长 node 来均摊负载和增长可靠性。

Elasticsearch 天生就是分布式的：它知道如何管理节点来提供高扩展和高可用。这意味着你的程序不须要关心这些。

2.1 Empty cluster

只有一个空节点的集群

一个 node 就是一个 Elasticsearch实例. cluster 中的多个 node，they have the same cluster.name.
它们协同工做，分享数据和负载。当加入新的节点或者删除一个节点时，集群就会感知到并平衡数据。

集群中一个 node 会被选举为 master, 它将临时管理 cluster level 的一些变动，例如 create index、add or del node 等。master 不参与 doc level 的变动或搜索，这意味着在流量增加的时候，该 master 不会成为集群的瓶颈。任何 node 均可以成为 master

As user，cluster any node 通讯。每一个 node 都知道文档存在于哪一个node上，它们能够转发请求到相应的node上。咱们访问的 node 负责收集 各nodes 返回的数据，最后一块儿返回给客户端。这一切都由 Elasticsearch 处理。

2.2 Cluster healthy

green、yellow、red。

GET /_cluster/health

{
   "cluster_name":          "elasticsearch",
   "status":                "green",
   "timed_out":             false,
   "number_of_nodes":       1,
   "number_of_data_nodes":  1,
   "active_primary_shards": 0,
   "active_shards":         0,
   "relocating_shards":     0,
   "initializing_shards":   0,
   "unassigned_shards":     0
}

颜色	意义
green	All primary-shard 和 replica-shard good
yellow	All primary-shard good，not all replica-shard is good
red	not all primary-shard is good

2.3 Add index

index 只是一个用来指向多个 shards “logical namespace”.

一个shard是一个最小级别 “worker unit” ,它只是保存了 index 中全部数据的一部分。可是如今咱们只要知道shard 就是一个Lucene实例，而且它自己就是一个完整的搜索引擎。咱们的 doc 存储在 shard 中，而且在shard 中被索引，可是咱们的应用程序不会直接与它们通讯，而是，直接与 index 通讯。

复制分片只是主分片的一个副本，它能够防止硬件故障致使的数据丢失，同时能够提供读请求，好比搜索或者从别的shard取回文档。

当index建立完成的时候，primary-shard 的数量就固定了，可是 replica-shard 的数量能够随时调整

当index建立完成的时候，primary-shard　的数量就固定了，可是 replica-shard 的数量能够随时调整。

让咱们在集群中惟一一个空节点上建立一个叫作blogs的索引。默认状况下，一个索引被分配5个主分片，可是为了演示的目的，咱们只分配3个 primary-shard 和一个 replica-shard（每一个 primary-shard 都有一个replica-shard）：

PUT /blogs
{
   "settings" : {
      "number_of_shards" : 3,
      "number_of_replicas" : 1
   }
}

{
   "cluster_name":          "elasticsearch",
   "status":                "yellow", <1>
   "timed_out":             false,
   "number_of_nodes":       1,
   "number_of_data_nodes":  1,
   "active_primary_shards": 3,
   "active_shards":         3,
   "relocating_shards":     0,
   "initializing_shards":   0,
   "unassigned_shards":     3 <2>
}

事实上全部的 3 个 replica-shard 如今都是 unassigned状态——它们还未被分配给节点

2.4 Failover，横向扩展

故障转移

横向扩展

shard 自己就是一个完整的搜索引擎，它可使用单一 node 的全部资源。咱们拥有6个分片（3个 primary-shard and replica-shard），最多能够扩展到 6 个 node，每一个node上有一个shard，每一个 shard 能够100%使用这个节点的资源。

2.5 更多扩展

咱们要扩展到6个以上的节点 begin...

primary-shard 的数量在create index 时已经肯定。实际上，这个数量定义了能存储到索引里数据的最大数量（实际的数量取决于你的数据、硬件和应用场景）。然而，primary-shard or replica-shard 均可以处理读请求——搜索或文档检索，因此数据的冗余越多，咱们能处理的搜索吞吐量就越大。2

复制分片的数量能够在运行中的集群中动态地变动，这容许咱们能够根据需求扩大或者缩小规模。让咱们把replica-shard 的数量从原来的 1 增长到 2 ：

PUT /blogs/_settings
{
   "number_of_replicas" : 2
}

blogs 索引如今有9个分片：3 primary-shard 和 6 replica-shard。这意味着咱们可以扩展到 9个 node，再次变成每一个 node 一个 shard。这样理论上，搜索性能相比原始的 3node 集群增长三倍。

2.6 应对故障

杀掉第一个节点后的集群

primary-shard 1 和 2 在咱们杀掉 Node 1 时已经丢失，咱们的 index 在丢失 primary-shard 时不能正常工做。若是此时咱们检查集群健康，咱们将看到状态 red ：不是全部 primary-shard 均可用！

幸运的是丢失的两个 primary-shard 的完整拷贝存在于其余节点上，因此 new primary-shard 作的第一件事是把这些在 Node 2 和 Node 3上的 replica-shard 升级为 primary-shard，这时集群健康回到 yellow 状态。

Reference articles

Elasticsearch权威指南