elasticsearch發生腦裂時JAVA客戶端的行為

這篇文章的原文地址是 http://blog.trifork.com/2013/10/31/java-clients-behavior-during-creating-a-split-brain-situation-in-elasticsearch/ ，發布于2013年10月

</div>

之前的博文解釋了 如何避免elasticsearch的腦裂問題 ，但只是大概講了它是怎么發生的。這次我會詳細講解下腦裂發生時索引和查詢請求會怎么樣。我想你已經知道了，這要看情況！這取決于你用的是什么類型的客戶端。因為我熟悉Java，所以我會用elasticsearch支持的Java API寫兩種類型的客戶端： transport客戶端和node客戶端。

模擬腦裂問題

首先我們先用Oracle的VirtualBox起兩個跑Ubuntu 13.10的虛擬機。使用網絡設置的“Bridged Adapter”模式，我很快的啟動了一個“虛擬”的elasticsearch集群。

在建立了一個獨立分片，一個獨立復制索引后，我寫了兩個Java小程序用兩個獨立線程（一個索引一個查詢）不斷地索引文檔和從新生成的索引進行查詢。

為了模擬腦裂我給iptables加了一個rule，阻塞兩個機器間的通訊：

iptables -A INPUT -s 192.168.0.1 -j DROP
iptables -A OUTPUT -d 192.168.0.1 -j DROP

在索引了大約200個文檔后我執行了以上命令。我同樣的測試做了兩次，一次使用 transport客戶端 一次使用 node客戶端 。 所有的測試用的是0.90.5版本的elasticsearch（發文時的最新版）

transport客戶端的測試

不出意料（transport客戶端是對集群無感知的），將兩個節點間的通信阻塞并沒有對索引和查詢產生錯誤。當我執行iptables exclusion后，elasticsearch用了差不多一分鐘來決定對方已經無響應了。在這期間，transport客戶端暫停了所有的排序和查詢。我給代碼里設置了無超時，所以所有的請求都在靜靜的等待elasticsearch返回一個可用的集群。跟預期一樣，每個節點都選舉自己為主所以現在每個節點都有一份索引的獨立拷貝。

索引和查詢請求隨機的請求到每個節點。運行期間每個索引請求并沒有報告兩份索引分開了。 沒有觀察到任何失敗和警告 - 以客戶端的視角整個測試期間一切都很正常。

node客戶端的測試

因為node客戶端在elasticsearch集群中創建了一個節點（node）， 我期望這次測試與transport客戶端的那次結果會不一樣。 在執行了iptables命令后， 索引請求完全暫停了， 但查詢請求仍然在運行，以round robin的形式在兩個節點間發生。 請求返回了不同的結果，在我切斷了兩個分片間的通信時復制分片與主分片失去了同步。

當兩個節點決定對方已經失效了， node客戶端隨機的選了其中一個座位新的集群主節點。從那時起，所有的索引和查詢請求都指向了這個新的主節點。一樣的，在測試期間沒有觀測到任何失敗，但node客戶端報告了它切換了主節點（INFO級別的日志）。

由于node客戶端在發生了腦裂后只指向了一個節點，所以兩份索引的拷貝并沒有分裂，但是只有其中一個是最新的。我相信這是node客戶端相對于transport客戶端的一個優點。

那么集群重啟呢？

當腦裂發生后，唯一的修復辦法是解決這個問題并重啟集群。 這兒有點復雜和可怕。 當elasticsearch集群啟動時，會選出一個主節點（一般是啟動的第一個節點被選為主）。由于索引的兩份拷貝已經不一樣了，elasticsearch會認為選出來的主保留的分片是“主拷貝”并將這份拷貝推送給集群中的其他節點。這很嚴重。讓我們設想下你是用的是node客戶端并且一個節點保留了索引中的正確數據。但如果是另外的一個節點先啟動并被選為主，它會將一份過期的索引數據推送給另一個節點，覆蓋它，導致丟失了有效數據。

結論

所以怎么從腦裂中恢復？第一個建議是給所有重索引的數據做備份。第二，如果腦裂發生了，要十分小心的重啟你的集群。停掉所有節點并決定哪一個節點第一個啟動。 如果需要，單獨啟動每個節點并分析它保存的數據。如果不是有效的，關掉它，并刪除它數據目錄的內容（刪前先做個備份）。如果你找到了你想要保存數據的節點，啟動它并且檢查日志確保它被選為主節點。這之后你可以安全的啟動你集群里的其他節點了。