elasticsearch 版本：5.2
叢集節點數：5
索引主分片數：5
索引分片副本數：1
線上環境es存儲的資料量很大，當天由于存儲故障，導緻一時間 5個節點的 es 叢集，同時有兩個節點離線，一個節點磁盤隻讀（機房小哥不會處理，無奈隻有清空資料重新安裝系統），一個節點重新開機後，es叢集報個别索引分片配置設定異常，es索引出于保證資料一緻性的考慮，并沒有把重新開機節點上的副本分片提升為主分片，是以該索引處于個别主分片丢失 不可寫入 狀态（索引分片 red）。
由于此圖是後來取消副本數為0後，截的圖，是以此處并沒有副本分片。
在網上找了找類似的處理方案，分為以下幾個。
利用 <code>_reroute</code> api 進行分片路由。
pass： 分片都啟不來，按照網上的操作執行失敗。
利用 <code>_reindex</code> api 進行現有資料重新複制到新索引，然後把舊索引删除，新索引建立别名為老索引名稱。
優點：因為如圖分片 0 出于隻讀狀态，是以資料是可以通路的，是以利用<code>_reindex</code>可以把副本分片的資料進行複制遷移到新索引，最大保證資料的安全性。
缺點：因為涉及的資料量比較大，而且<code>_reindex</code>效率很低，220g 的索引資料，大概要3-4天的時間才能寫入完畢。線上環境等不了這麼久。
也找了許多提升<code>_reindex</code>效率的方法，設定新索引的副本數為 0，禁用重新整理 等等。提升效果都很小。
線上環境能夠接受該索引部分資料的丢失，但求盡快恢複服務。
找了下官方文檔，找到了如下方法。
利用 <code>_shard_stores</code> 接口，檢視故障索引的分片異常原因。
（es5 節點上，我調用接口設定了副本數從1 變為 0，是以該隻讀索引還儲存有原有分片 0 的副本分片節點資訊，可忽略）
我們看到該索引的 0 主分片（故障主分片）以前是存在于 es3 節點上的。es 由于資料安全性保證，在兩個節點都有離線的情況下，鎖住了 0 主分片的寫入，導緻索引也出于隻讀狀态。
我們可以手動調用叢集的 <code>reroute</code> 接口，在接受部分資料丢失的情況下，我們可以把 es3 節點上的原有副本，強制提升為索引的主分片。
官方文檔 說明。
此外，<code>/_cluster/reroute</code> 接口還能夠接受手動配置設定一個空的主分片到已有索引配置設定之中。謹慎使用
這種更殘暴，直接把分片資料清空，強制拉上線。 但是這也不失為一種處理方法。
最終，該索引恢複正常。