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權威指南