遇到這種情況不要慌，本文給出基礎叢集故障排查及修複指南，希望對你有所幫助。
1、叢集健康狀态的解讀
這裡直接用官方文檔的解析，以避免不準确導緻誤導。
叢集運作狀況為：綠色、黃色、紅色。
在分片級别：
綠色狀态：表示叢集健康；
黃色狀态：表示所有主分片均已配置設定，但有一個或多個副本分片未配置設定。如果叢集中的某個節點發生故障，則在修複該節點之前，某些資料可能不可用；
紅色狀态：表示存在一個或多個主分片未配置設定，是以某些資料不可用。在叢集啟動期間，伴随着主分片的配置設定過程，這可能會短暫發生。
索引級别狀态由最壞的分片狀态控制。叢集狀态由最差索引狀态控制。解釋一下：我們通常說叢集狀态變紅了，實際上叢集中某個索引出了問題，更精确的說，是某個索引上的某個分片出了問題。
注意 1：
叢集處于黃色狀态，索引仍在工作，并且資料也全部可以被索引、搜尋，隻是速度和可靠性可能達不到預期。
目前出問題的副本分片可能：丢失、損壞或存在其他問題；或者叢集可能處于移動或重建副本分片的過程中。
我們要做的工作是：手動或者自動重新處理這些可能出問題的副本分片以實作叢集恢複綠色狀态。
注意 2：
叢集處于紅色狀态，代表-一個或多個索引缺少主分片，即無法索引、搜尋或提供資料。
健康狀态基于每個分片的，假設叢集中有50個分片，其中一個主分片出問題，其所在索引狀态是紅色，整個叢集也都會變成紅色。
我們要做的工作是：手動查找或修複這些未配置設定的主分片，否則一旦索引資料丢失，隻能從快照或原始源資料中重新建立索引。
2、定位紅色或黃色的索引
2.1 第一步：确定你所知道的主要問題。
例如節點當機、磁盤空間（磁盤使用逼近或超過警戒水位線：85%、90%、甚至95%的磁盤使用率）問題等，這些問題很可能會造成叢集狀态的變化。
這些外部明顯的問題便于我們追溯問題、“對症下藥”形成解決方案。
有時你隻需要耐心等待，因為系統通常會通過移動資料來進行自我修複。
舉例1：重新啟動會經曆叢集由紅色變為黃色、黃色變為綠色。
舉例2：一個節點的主分片出了問題，系統會将副本分片更新為主分片，然後重新建立新副本，但這需要幾分鐘到更長的時間，具體取決于：分片數量、大小，叢集負載，磁盤速度等。
但是，除非明确系統正在修複，否則你不能僅指望系統自身修複這一招。有時情況确實是主分片或者副本分片出了問題，這也是為什麼要了解曆史記錄的原因。日志和慢日志都有助于輔助排查曆史記錄。
如果你是叢集運維人員，當叢集出故障之後，你看到或者監控到是叢集健康狀态的變化，你還能看到日志，大緻知道業務層面在做什麼操作導緻，但是，還是強烈建議你結合你的判定結果和開發人員進行業務層面的确認和推敲，以輔助定位問題所在。
2.2 第二步：确定哪些索引有問題，多少索引有問題。
_cat API 可以通過傳回結果告訴我們這一點：
GET _cat/indices?v&health=red
GET _cat/indices?v&health=yellow
GET _cat/indices?v&health=green
如下就是：索引為黃色的截圖。
由此我們可以了解到我們遇到了多少問題，這很可能與上述最近發生的事件有關。
我們還需要此截圖清單，以便我們可以更深入地研究每個索引。
2.3 第三步：檢視有問題的分片以及原因。
這與索引清單有關，但是索引清單隻會告訴你哪些索引存在問題，現在還需要我們根據索引清單形成問題清單。
為此我們應該使用如下_cat API：
GET /_cat/shards?v&h=n,index,shard,prirep,state,sto,sc,unassigned.reason,unassigned.details&s=sto,index
下圖展示了傳回的結果：
隻提示一個字段的含義：unassigned.reason 未配置設定分片的原因，傳回值包括：
ALLOCATION_FAILED：由于分片配置設定失敗而未配置設定。
CLUSTER_RECOVERED：由于叢集恢複而未配置設定。
DANGLING_INDEX_IMPORTED：由于導入了懸空索引導緻未配置設定。
EXISTING_INDEX_RESTORED：由于恢複為已關閉的索引導緻未配置設定。
INDEX_CREATED：由于API建立索引而未配置設定。
INDEX_REOPENED：由于打開已關閉索引而未配置設定。
NEW_INDEX_RESTORED：由于恢複到新索引而未配置設定。
NODE_LEFT：由于托管的節點離開叢集而未配置設定。
REALLOCATED_REPLICA：确定了更好的副本位置，并導緻現有副本配置設定被取消。
REINITIALIZED：當分片從開始移動回初始化，導緻未配置設定。
REPLICA_ADDED：由于顯式添加副本而未配置設定。
REROUTE_CANCELLED：由于顯式取消重新路由指令而未配置設定。
通過未配置設定列原因unassigned.reason似乎是已經夠詳細了，但是有時候我們需要更多細節，特别是如果我們有節點路由或其他更複雜的問題。
2.4 進一步定位未配置設定的原因
我們可以繼續問叢集為什麼不配置設定分片？
為此，我們可以要求叢集進一步傳回給定分片的目前配置設定情況和邏輯。需要結合 2.3 傳回結果對下面的 _cluster/allocation/explain API 參數進行修改。
GET /_cluster/allocation/explain
{
"index": "my_index_003",
"shard": 0,
"primary": false
}
以上幾個參數都是可選參數。
指定了三個參數：
index：索引名稱。
shard: 分片數。
primary: 是否是主分片。
傳回的結果也一目了然，在下面的 explanation 指出：分片不能再配置設定到相同的節點，是因為：該節點上已經有對應的主分片上了。
有叢集基礎認知的同學肯定都知道：主分片和副本分片要配置設定到不同的叢集節點上。
這個問題的根源也逐漸明朗：我是單節點叢集，但是為建立的索引 my_index_003 設定了副本分片，導緻了副本分片無法配置設定，分片呈現黃色。
這将使你對情況有更詳細的了解，接下來的操作取決于你在那裡找到原因。
一些常見的問題包括：
磁盤空間不足——沒有磁盤空間來配置設定分片；
分片數限制 ——每個節點的分片數量過多，在建立新索引或删除某些節點且系統找不到它們的位置時很常見；
JVM或記憶體限制——一些版本在記憶體不足時可以限制分片配置設定；
路由或配置設定規則——通用高可用雲雲或大型複雜系統會遇到；
崩潰或嚴重問題——可能會出現更多問題，每個問題都需要特别注意或解決，或者在許多情況下，需要重新導入資料解決。
2.5 對症下藥，解決問題。
修補程式分為幾類：
第一類：等待并讓 Elasticsearch 叢集自行修複。
适用于：臨時狀況、叢集啟動階段。
操作方法：節點重新開機。
第二類：将副本設定為0。
删除所有副本，針對場景：也許你無法修複副本或手動移動或配置設定它。
在這種情況下，隻要擁有主分片（健康狀态為黃色，而不是紅色），就可以始終使用以下指令将副本數設定為0，等待一分鐘，然後再設定為1或任意你業務場景需要設定的值。
PUT my_index_003/_settings
"index": {
"number_of_replicas": 0
}
第三類：手動配置設定分片，借助 reroute API。
舉例：
POST /_cluster/reroute
"commands": [
{
"move": {
"index": "test", "shard": 0,
"from_node": "node1", "to_node": "node2"
}
},
"allocate_replica": {
"index": "test", "shard": 1,
"node": "node3"
}
]
共做了：move 移動分片 和 allocate_replica 配置設定副本兩個操作。
第四類：檢查路由、配置設定規則。
許多高可用或複雜的系統使用路由或配置設定規則來控制分片配置設定，随着情況的變化，這會建立無法配置設定的分片。
這個時候，explain API 有助于排查問題。
3、小結
之前也寫過叢集紅色、黃色修複方案的文章，這次的更系統化一些，更偏方法論。
本篇的脈絡參考翻譯了：
https://www.elkman.io/blog/elasticsearch-index-red-yellow-why。
叢集健康狀态的維護是一項大工程，實際業務實戰中遇到的問題遠比我列的複雜，但我們要具備化繁為簡的能力，一步步把問題拆解，大問題變成小問題，
把一個個小問題解決了，大問題也就迎刃而解。
4、加餐-讨論
有讀者留言：
1、系列部落格比較散，有沒有考慮形成教程？
2、出書吧，你的書，我肯定買。。。
大家稍安勿躁，面包會有的，在一步步籌備籌劃中，時間都待定......
大家對本公衆号内容有好的意見或者建議，也歡迎留言讨論，置頂留言會有神秘獎勵。
加微信：elastic6（僅有少量坑位了），和 BAT 大佬一起精進 Elastic 技術！