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 總結
解決問題是一個邏輯推理的過程,隻有根據相關資訊和理論去找原因,然後不斷在開發環境下嘗試,最後總會找到解決問題的方法。