轉：elasticsearch外場分片找回-UNASSIGNED

0x01 原因

     產品開發過程當中沒有專人去深刻理解elasticsearch相關原理，致使在產品生產部署時，沒有作到合理的物理架構部署，致使後期問題不斷出現。

     當外場出現服務器資源瓶頸時，緊急調整相關結構，忙中出錯，調整主節點時，致使某個索引沒法找回相關分片。相似：

     

     一、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 解決思路和辦法

   解決問題的過程當中嘗試了不少作法：

     一、強制從新分片---無用

     二、嘗試修改分片文件信息---無用

  最後，可行的方法是：

     一、將全部節點新生成的UUID對象的文件備份移走；

     二、經過head等工具，直接刪除該索引；

     三、ES立馬把老的索引信息恢復；

0x05 總結

     解決問題是一個邏輯推理的過程，只有根據相關信息和理論去找緣由，而後不斷在開發環境下嘗試，最後總會找到解決問題的方法。