elasticsearch 版本：5.2
集群節點數：5
索引主分片數：5
索引分片副本數：1
線上環境es儲存的資料量很大，當天由於儲存故障，導致一時間 5個節點的 es 集群，同時有兩個節點離線，乙個節點磁碟唯讀（機房小哥不會處理，無奈只有清空資料重新安裝系統），乙個節點重啟後，es集群報個別索引分片分配異常，es索引出於保證資料一致性的考慮，並沒有把重啟節點上的副本分片提公升為主分片，所以該索引處於個別主分片丟失不可寫入狀態（索引分片 red）。
由於此圖是後來取消副本數為0後，截的圖，所以此處並沒有副本分片。
在網上找了找類似的處理方案，分為以下幾個。
利用_rerouteapi 進行分片路由。
pass： 分片都啟不來，按照網上的操作執行失敗。
利用_reindexapi 進行現有資料重新複製到新索引，然後把舊索引刪除，新索引建立別名為老索引名稱。
優點：因為如圖分片 0 出於唯讀狀態，所以資料是可以訪問的，所以利用_reindex可以把副本分片的資料進行複製遷移到新索引，最大保證資料的安全性。
缺點：因為涉及的資料量比較大，而且_reindex效率很低，220g 的索引資料，大概要3-4天的時間才能寫入完畢。線上環境等不了這麼久。
也找了許多提公升_reindex效率的方法，設定新索引的副本數為 0，禁用重新整理 等等。提公升效果都很小。
線上環境能夠接受該索引部分資料的丟失，但求盡快恢復服務。
找了下官方文件，找到了如下方法。
}}}利用_shard_stores介面，檢視故障索引的分片異常原因。
（es5 節點上，我呼叫介面設定了副本數從1 變為 0，所以該唯讀索引還儲存有原有分片 0 的副本分片節點資訊，可忽略）
我們看到該索引的 0 主分片（故障主分片）以前是存在於 es3 節點上的。es 由於資料安全性保證，在兩個節點都有離線的情況下，鎖住了 0 主分片的寫入，導致索引也出於唯讀狀態。
我們可以手動呼叫集群的reroute介面，在接受部分資料丟失的情況下，我們可以把 es3 節點上的原有副本，強制提公升為索引的主分片。
官方文件 說明。
此外，/_cluster/reroute介面還能夠接受手動分配乙個空的主分片到已有索引分配之中。謹慎使用
這種更殘暴，直接把分片資料清空，強制拉上線。 但是這也不失為一種處理方法。
最終，該索引恢復正常。
記一次線上環境 ES 主分片為分配故障
elasticsearch 版本 5.2 集群節點數 5 索引主分片數 5 索引分片副本數 1 線上環境es儲存的資料量很大，當天由於儲存故障，導致一時間 5個節點的 es 集群，同時有兩個節點離線，乙個節點磁碟唯讀 機房小哥不會處理，無奈只有清空資料重新安裝系統 乙個節點重啟後，es集群報個別索引...
記一次線上環境rabbitmq訊息重複消費的始與末
與這個bug糾結了幾天，從懷疑消費者消費失敗訊息重發到生產者訊息傳送多次，均無果，問題只發生在雲上，測試環境無法重現，陷入了打log到否定問題點的死迴圈，好在重複消費不會影響正常的業務邏輯，不過再次收到重複的消費處理失敗會傳送郵件，郵箱被轟炸了幾天。請教眾方大神無果，把懷疑點瞄準雲服務 這裡就不說是...
記一次線上問題排查
這次線上問題來的比較突然，影響也大，用部落格記錄下整個過程，也當作是對這次事故的一次總結歸納。day1 2018年06月21號上午10點，收到運營同事通知，http com api 訪問量劇增，日誌量達到80g 天，而且有上公升趨勢。運營同事讓我們排查，這種訪問是否正常。運營統計訪問量 收到通知後立...