elasticsearch—集羣初識篇（四）

1.集羣健康：

Elasticsearch 的集羣監控信息中包含了許多的統計數據，其中最爲重要的一項就是 集羣健康 ， 它在 status 字段中展示爲 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
}

status 字段指示着當前集羣在總體上是否工作正常。它的三種顏色含義如下：

• green
  所有的主分片和副本分片都正常運行。
• yellow
  所有的主分片都正常運行，但不是所有的副本分片都正常運行。
• red
  有主分片沒能正常運行。

2.添加索引

我們往 Elasticsearch 添加數據時需要用到 索引 --> 保存相關數據的地方。 索引實際上是指向一個或者多個物理分片 的 邏輯命名空間 。
一個 分片 是一個底層的 工作單元 ，它僅保存了全部數據中的一部分。 在分片內部機制中，我們將詳細介紹分片是如何工作的，而現在我們只需知道一個分片是一個 Lucene 的實例，以及它本身就是一個完整的搜索引擎。 我們的文檔被存儲和索引到分片內，但是應用程序是直接與索引而不是與分片進行交互。

Elasticsearch 是利用分片將數據分發到集羣內各處的。分片是數據的容器，文檔保存在分片內，分片又被分配到集羣內的各個節點裏。 當你的集羣規模擴大或者縮小時， Elasticsearch 會自動的在各節點中遷移分片，使得數據仍然均勻分佈在集羣裏。

一個分片可以是 主 分片或者 副本 分片。 索引內任意一個文檔都歸屬於一個主分片，所以主分片的數目決定着索引能夠保存的最大數據量。
一個副本分片只是一個主分片的拷貝。副本分片作爲硬件故障時保護數據不丟失的冗餘備份，併爲搜索和返回文檔等讀操作提供服務。

在索引建立的時候就已經確定了主分片數，但是副本分片數可以隨時修改。
讓我們在包含一個空節點的集羣內創建名爲 blogs 的索引。 索引在默認情況下會被分配5個主分片， 但是爲了演示目的，我們將分配3個主分片和一份副本（每個主分片擁有一個副本分片）：

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

如果我們現在查看集羣健康，我們將看到如下內容：

{
  "cluster_name": "elasticsearch",
  "status": "yellow", // 集羣 status 值爲 yellow
  "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,    //	沒有被分配到任何節點的副本數。
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 50
}

集羣的健康狀況爲 yellow 則表示全部 主 分片都正常運行（集羣可以正常服務所有請求），但是 副本 分片沒有全部處在正常狀態。 實際上，所有3個副本分片都是 unassigned —— 它們都沒有被分配到任何節點。 在同一個節點上既保存原始數據又保存副本是沒有意義的，因爲一旦失去了那個節點，我們也將丟失該節點上的所有副本數據。

3.添加故障轉移

當集羣中只有一個節點在運行時，意味着會有一個單點故障問題——沒有冗餘。 幸運的是，我們只需再啓動一個節點即可防止數據丟失。

啓動第二個節點
爲了測試第二個節點啓動後的情況，你可以在同一個目錄內，完全依照啓動第一個節點的方式來啓動一個新節點。多個節點可以共享同一個目錄。
當你在同一臺機器上啓動了第二個節點時，只要它和第一個節點有同樣的 cluster.name 配置，它就會自動發現集羣並加入到其中。 但是在不同機器上啓動節點的時候，爲了加入到同一集羣，你需要配置一個可連接到的單播主機列表。 詳細信息請查看最好使用單播代替組播

如果啓動了第二個節點，我們的集羣將會如Figure 3, “擁有兩個節點的集羣——所有主分片和副本分片都已被分配”。

• 一個節點的情況：
  
• 啓動第二個節點的情況：
  
  當第二個節點加入到集羣后，3個 副本分片 將會分配到這個節點上——每個主分片對應一個副本分片。 這意味着當集羣內任何一個節點出現問題時，我們的數據都完好無損。

所有新近被索引的文檔都將會保存在主分片上，然後被並行的複製到對應的副本分片上。這就保證了我們既可以從主分片又可以從副本分片上獲取數據。

cluster-health 現在展示的狀態爲 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,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 100
}

4.水平擴容

擁有三個節點的集羣——爲了分散負載而對分片進行重新分配，如下圖：

結論：Node 1 和 Node 2 上各有一個分片被遷移到了新的 Node 3 節點，現在每個節點上都擁有2個分片，而不是之前的3個。 這表示每個節點的硬件資源（CPU, RAM, I/O）將被更少的分片所共享，每個分片的性能將會得到提升。

分片是一個功能完整的搜索引擎，它擁有使用一個節點上的所有資源的能力。 我們這個擁有6個分片（3個主分片和3個副本分片）的索引可以最大擴容到6個節點，每個節點上存在一個分片，並且每個分片擁有所在節點的全部資源。

如果我們想要擴容超過6個節點怎麼辦呢？
主分片的數目在索引創建時就已經確定了下來。實際上，這個數目定義了這個索引能夠 存儲 的最大數據量。（實際大小取決於你的數據、硬件和使用場景。） 但是，讀操作——搜索和返回數據——可以同時被主分片 或 副本分片所處理，所以當你擁有越多的副本分片時，也將擁有越高的吞吐量。

在運行中的集羣上是可以動態調整副本分片數目的，我們可以按需伸縮集羣。讓我們把副本數從默認的 1 增加到 2 ：

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

如下圖所示， blogs 索引現在擁有9個分片：3個主分片和6個副本分片。 這意味着我們可以將集羣擴容到9個節點，每個節點上一個分片。相比原來3個節點時，集羣搜索性能可以提升 3 倍。

當然，如果只是在相同節點數目的集羣上增加更多的副本分片並不能提高性能，因爲每個分片從節點上獲得的資源會變少。 你需要增加更多的硬件資源來提升吞吐量。
但是更多的副本分片數提高了數據冗餘量：按照上面的節點配置，我們可以在失去2個節點的情況下不丟失任何數據。

5.故障處理

關閉第一個節點，這時集羣的狀態圖可描述爲：

我們關閉的節點是一個主節點。而集羣必須擁有一個主節點來保證正常工作，所以發生的第一件事情就是選舉一個新的主節點： Node 2 。
在我們關閉 Node 1 的同時也失去了主分片 1 和 2 ，並且在缺失主分片的時候索引也不能正常工作。 如果此時來檢查集羣的狀況，我們看到的狀態將會爲 red ：不是所有主分片都在正常工作。

幸運的是，在其它節點上存在着這兩個主分片的完整副本， 所以新的主節點立即將這些分片在 Node 2 和 Node 3 上對應的副本分片提升爲主分片， 此時集羣的狀態將會爲 yellow 。 這個提升主分片的過程是瞬間發生的，如同按下一個開關一般。

爲什麼我們集羣狀態是 yellow 而不是 green 呢？ 雖然我們擁有所有的三個主分片，但是同時設置了每個主分片需要對應2份副本分片，而此時只存在一份副本分片。 所以集羣不能爲 green 的狀態，不過我們不必過於擔心：如果我們同樣關閉了 Node 2 ，我們的程序 依然 可以保持在不丟任何數據的情況下運行，因爲 Node 3 爲每一個分片都保留着一份副本。

如果我們重新啓動 Node 1 ，集羣可以將缺失的副本分片再次進行分配，那麼集羣的狀態也將 參數 number_of_replicas 調大到 2。 如果 Node 1 依然擁有着之前的分片，它將嘗試去重用它們，同時僅從主分片複製發生了修改的數據文件。