0x01 緣由
産品開發過程中沒有專人去深入了解elasticsearch相關原理，導緻在産品生産部署時，沒有做到合理的實體架構部署，導緻後期問題不斷出現。 當外場出現伺服器資源瓶頸時，緊急調整相關結構，忙中出錯，調整主節點時，導緻某個索引無法找回相關分片。類似：
1、3分片 “ UNASSIGNED”
0x02 場景描述
軟體：elasticsearch 5.1.1 版本 5個節點 1個主節點 運作軟體： 上面跑各種程式，導緻資源使用需要非常珍惜。 a.嘗試修改elasticsearch/config/elasticsearch.yml 中相關參數，即作為資料節點，又作為主節點如下： node.master: true node.data: true b.重新開機es 重新開機es幾分鐘後，重新分片還未完成，就開始重新開機其他節點。 c.過了幾個小時後，發現一個索引分片無法找回，狀态變為RED； 背景日志報錯： 017-08-31T15:37:06,018][WARN ][o.e.g.DanglingIndicesState] [node8] [[wide_protocols_215a_201707/j7yRa0RoT6eQPZzl67wv3g]] can not be importe d as a dangling index, as index with same name already exists in cluster metadata
0x03 問題分析
資料對于現網運作環境來說，比較重要。是以得想辦法去恢複索引分片。 a.檢視索引分片的uuuid:
b.然後進入背景資料存儲路徑，檢視，發現7月份索引兩個分片資訊，這也是導緻es背景日志有如下警告的原因： 017-08-31T15:37:06,018][WARN ][o.e.g.DanglingIndicesState] [node8] [[wide_protocols_215a_201707/j7yRa0RoT6eQPZzl67wv3g]] can not be importe d as a dangling index, as index with same name already exists in cluster metadata c.導緻es狀态總是 RED，影響到資料的檢索速度等。
0x04 解決思路和辦法
解決問題的過程中嘗試了很多做法： 1、強制重新分片---無用 2、嘗試修改分片檔案資訊---無用 最後，可行的方法是： 1、将所有節點新生成的UUID對象的檔案備份移走； 2、通過head等工具，直接删除該索引； 3、ES立馬把老的索引資訊恢複；
0x05 總結
解決問題是一個邏輯推理的過程，隻有根據相關資訊和理論去找原因，然後不斷在開發環境下嘗試，最後總會找到解決問題的方法。