乾貨 | Elasticsearch 集羣健康值紅色終極解決方案

題記
Elasticsearch當清理緩存（ echo 3 > /proc/sys/vm/drop_caches ）的時候，出現
以下集羣健康值：red，紅色預警狀態，同時部分分片都成爲灰色。

查看Elasticsearch啓動日誌會發現以下：
集羣服務超時鏈接的狀況。

bserver: timeout notification from cluster service. timeout setting [1m], time since start [1m]

該問題排查耗時很長，問題已經解決。
特將問題排查及解決方案詳盡的整理出來。

一、集羣狀態解讀

head插件會以不一樣的顏色顯示。

1）、綠色——最健康的狀態，表明全部的主分片和副本分片均可用；
2）、黃色——全部的主分片可用，可是部分副本分片不可用；
3）、紅色——部分主分片不可用。（此時執行查詢部分數據仍然能夠查到，遇到這種狀況，仍是趕快解決比較好。）

參考官網：http://t.cn/RltLEpN（部分中文集羣健康狀態博文資料翻譯的不夠精確，以官網爲準）

若是集羣狀態爲紅色， Head插件顯示：集羣健康值red 。則說明：至少一個主分片分配失敗。

這將致使一些數據以及索引的某些部分再也不可用。

儘管如此， ElasticSearch仍是容許咱們執行查詢，至因而通知用戶查詢結果可能不完整仍是掛起查詢，則由應用構建者來決定。

二、什麼是unassigned 分片？
一句話解釋：未分配的分片。
啓動ES的時候，經過Head插件不停刷新，你會發現集羣分片會呈現紫色、灰色、最終綠色的狀態。

三、爲何會出現 unassigned 分片？
若是不能分配分片，例如，您已經爲集羣中的節點數過度分配了副本分片的數量，則分片將保持UNASSIGNED狀態。
其錯誤碼爲：ALLOCATION_FAILED。

你能夠經過以下指令，查看集羣中不一樣節點、不一樣索引的狀態。

GET _cat/shards?h=index,shard,prirep,state,unassigned.reason

四、出現unassigned 分片後的症狀？
head插件查看會：Elasticsearch啓動N長時候後，某一個或幾個分片仍持續爲灰色。

五、unassigned 分片問題可能的緣由？

1）INDEX_CREATED：因爲建立索引的API致使未分配。

2）CLUSTER_RECOVERED ：因爲徹底集羣恢復致使未分配。

3）INDEX_REOPENED ：因爲打開open或關閉close一個索引致使未分配。

4）DANGLING_INDEX_IMPORTED ：因爲導入dangling索引的結果致使未分配。

5）NEW_INDEX_RESTORED ：因爲恢復到新索引致使未分配。

6）EXISTING_INDEX_RESTORED ：因爲恢復到已關閉的索引致使未分配。

7）REPLICA_ADDED：因爲顯式添加副本分片致使未分配。

8）ALLOCATION_FAILED ：因爲分片分配失敗致使未分配。

9）NODE_LEFT ：因爲承載該分片的節點離開集羣致使未分配。

10）REINITIALIZED ：因爲當分片從開始移動到初始化時致使未分配（例如，使用影子shadow副本分片）。

11）REROUTE_CANCELLED ：做爲顯式取消從新路由命令的結果取消分配。

12）REALLOCATED_REPLICA ：肯定更好的副本位置被標定使用，致使現有的副本分配被取消，出現未分配。

六、集羣狀態紅色如何排查？
症狀：集羣健康值紅色;
日誌：集羣服務鏈接超時；
可能緣由：集羣中部分節點的主分片未分配。
接下來的解決方案主要圍繞：使主分片unsigned 分片完成再分配展開。

七、如何Fixed unassigned 分片問題？
方案一：極端狀況——這個分片數據已經不可用，直接刪除該分片。
ES中沒有直接刪除分片的接口，除非整個節點數據已再也不使用，刪除節點。

curl -XDELETE ‘localhost:9200/index_name/’

方案二：集羣中節點數量>=集羣中全部索引的最大副本數量 +１。
N> = R + 1
其中：
N——集羣中節點的數目；
R——集羣中全部索引的最大副本數目。
知識點：

當節點加入和離開集羣時，主節點會自動從新分配分片，以確保分片的多個副本不會分配給同一個節點。

換句話說，主節點不會將主分片分配給與其副本相同的節點，也不會將同一分片的兩個副本分配給同一個節點。
若是沒有足夠的節點相應地分配分片，則分片可能會處於未分配狀態。
因爲個人集羣就一個節點，即Ｎ＝１；因此Ｒ＝０，才能知足公式。

問題就轉嫁爲：
１）添加節點處理，即Ｎ增大；
２）刪除副本分片，即R置爲0。
R置爲0的方式，能夠經過以下命令行實現：

curl -XPUT "http://localhost:9200/_settings" -d'
{ "number_of_replicas" : 0 } '

方案三：allocate從新分配分片。
若是方案二仍然未解決，能夠考慮從新分配分片。

可能的緣由：

1）節點在從新啓動時可能遇到問題。正常狀況下，當一個節點恢復與羣集的鏈接時，它會將有關其分片的信息轉發給主節點，而後主節點將這分片從「未分配」轉換爲「已分配/已啓動」。

2）當因爲某種緣由（例如節點的存儲已被損壞）致使該進程失敗時，分片可能保持未分配狀態。

在這種狀況下，您必須決定如何繼續：嘗試讓原始節點恢復並從新加入集羣（而且不要強制分配主分片）；

或者強制使用Reroute API分配分片並從新索引缺乏的數據原始數據源或備份。
若是您決定分配未分配的主分片，請確保將「allow_primary」：「true」標誌添加到請求中。

ES5.X使用腳本以下：

NODE="YOUR NODE NAME"IFS=$'\n'for line in
$(curl -s 'localhost:9200/_cat/shards' |
fgrep UNASSIGNED);
do
INDEX=$(echo $line | (awk '{print $1}'))
SHARD=$(echo $line | (awk '{print $2}'))

curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
"commands": [
{
" allocate_replica ": {
"index": "'$INDEX'",
"shard": '$SHARD',
"node": "'$NODE'",
"allow_primary": true
}
}
]
}'done

ES2.X及早期版本，將 allocate_replica改成 allocate，其餘不變。

腳本解讀：
步驟1：定位 UNASSIGNED 的節點和分片。

curl -s 'localhost:9200/_cat/shards' |
fgrep UNASSIGNED

步驟2：經過 allocate_replica 將 UNASSIGNED的分片從新分配。

八、核心知識點
1）路由
原理很簡單，把每一個用戶的數據都索引到一個獨立分片中，在查詢時只查詢那個用戶的分片。這時就須要使用路由。
使用路由優點：路由是優化集羣的一個很強大的機制。
它能讓咱們根據應用程序的邏輯來部署文檔, 從而能夠用更少的資源構建更快速的查詢。

2）在索引過程當中使用路由
咱們能夠經過路由來控制 ElasticSearch 將文檔發送到哪一個分片。
路由參數值可有可無，能夠取任何值。重要的是在將不一樣文檔放到同一個分片上時, 須要使用相同的值。

3）指定路由查詢
路由容許用戶構建更有效率的查詢，當咱們只須要從索引的一個特定子集中獲取數據時, 爲何非要把查詢發送到全部的節點呢?

指定路由查詢舉例:

curl -XGET 'localhost:9200/documents/_search?pretty&q=:&routing=A'

4）集羣再路由reroute
reroute命令容許顯式地執行包含特定命令的集羣從新路由分配。

例如，分片能夠從一個節點移動到另外一個節點，能夠取消分配，或者能夠在特定節點上顯式分配未分配的分片。

5）allocate分配原理
分配unassigned的分片到一個節點。

將未分配的分片分配給節點。接受索引和分片的索引名稱和分片號，以及將分片分配給它的節點。。
它還接受allow_primary標誌來明確指定容許顯式分配主分片（可能致使數據丟失）。

九、小結
1）該問題的排查累計超過6個小時，最終找到解決方案。以前幾近沒有思路，想放棄，但咬牙最終解決。

2) 切記，第一手資料很重要！
Elasticsearch出現問題，最高效的解決方案是第一手資料ES英文官網文檔，其次是ES英文論壇、ES github issues，再次是stackoverflow等英文論壇、博客。最後纔是：Elasticsearch中文社區、其餘相關中文技術博客等。

由於：全部的論壇、博客文字都是基於ES英文官方文檔再整理，不免有缺失或錯誤。

3）本身的Elasticsearch基礎原理、Lucene基礎知識的不牢固，別無它法，繼續深刻研究，繼續死磕中…….

參考
一、官網文檔地址：http://t.cn/RlttuVY
二、Elasticsearch unassigned shards 應急處理方案 ：http://t.cn/Rlwub5s
三、解決Unassigned Shards大探討：http://t.cn/RlwuVFn
四、快照&從新存儲數據方案：http://t.cn/RlwuXmm