solrcloud Recovery原理及沒法選舉分片leader

咱們在使用SolrCloud中會常常發現會有備份的shard出現狀態Recoverying，這就代表SolrCloud的數據存在着不一致性，須要進行Recovery，這個時候的SolrCloud建索引是不會寫入索引文件中的(每一個shard接受到update後寫入本身的ulog中)。

一、solrcloud Recovery原理

    1.一、Recovery緣由

        SolrCloud啓動的時候，主要因爲在建索引的時候發生意外關閉，致使一些replicat的數據與leader不一致，那麼在啓動的時候剛起的replicat就會從leader那裏同步數據。

        SolrCloud在進行leader選舉中出現錯誤，通常出如今leader宕機引發replicat進行選舉成leader過程當中。

         SolrCloud在進行update時候，因爲某種緣由leader轉發update至replicat沒有成功，會迫使replicat進行recoverying進行數據同步。

    1.二、Recovery原理

    着重介紹第三種狀況的recovery

    在solrcloud接受寫入的過程當中，無論update請求發送到哪一個shard 分片中，最後在solrcloud裏面進行分發的順序都是從Leader發往Replica。Leader接受到update請求後先將document放入本身的索引文件以及update寫入ulog中，而後將update同時轉發給各個Replica分片。這就流程在就是以前講到的add的索引鏈過程。

    在索引鏈的add過程完畢後，SolrCloud會再依次調用finish()函數用來接受每個Replica的響應，檢查Replica的update操做是否成功。若是一旦有一個Replica沒有成功，就會向update失敗的Replica發送RequestRecovering命令強迫該分片進行Recoverying。

    Recovery分爲Peer sync和Replication兩種方式

Peer sync：若是中斷的時間較短，recovering node只是丟失少許update請求，那麼它能夠從leader的update log中獲取。這個臨界值是100個update請求，若是大於100，就會從leader進行完整的索引快照恢復。

Replication：若是節點下線過久以致於不能從leader那進行同步，它就會使用solr的基於http進行索引的快照恢復。

二、沒法選舉分片leader

    沒法選舉分片leader有各類緣由，例如分片的每一個replicat都掛了（包括leader），再例如replicat均沒法與zk保持聯繫等等，這些狀況屬於很是極端，不容易出現，且經過重啓機器能解決問題。下面，討論一種在實踐中遇到的狀況

2.一、場景描述

三臺機器，各8GB內存，每臺各部署一個實例，測試collection分紅兩片，每片2個複製集（一個leader，一個replicat）

以每秒2萬左右的速度向該集羣數據，寫入到300多萬記錄時，出現查詢緩慢（http請求延時），replicat出現recovering 狀態；接着重啓leader，這時候出現分片不可用，選舉不出leader

 

2.二、問題分析

經過查看日誌發現，leader與replicat與之間出現大量的http請求超時的狀況

也就是是說在寫入數據時候，leader向replicat發出的update在leader的finish裏會收不到success（根據第三種Recovery狀況），從而使得replicat進入recovery狀態

    

    若是replicat在recovery的時候出現leader宕機

 

   

    replicat會試圖成爲leader，而此時replicat真是recovery狀態，勢必選舉成leader失敗（片再無其它可用replicat，只有一個leader和一個replicat）

    

    接下來    接下來，分片進入無leader狀態，從而致使collection不可用

    2.三、解決辦法

    a、由於solr是http請求方式，寫入只會在leader上，而後經過leader DistributedUpdate到各個replicat，評估leader的寫入量，結合業務場景是否有這麼大的寫入量，增長collection的分片來分攤寫入

    b、增長分片的replicat，上述狀況是一個leader，一個replicat，當leader與某一個replicat出現某種緣由，致使replicat進入recovery狀態，而剛好leader宕機，只能選擇該recovery狀態的replicat成爲leader，必然會失敗，若是有多個replicat，就會下降出現這種狀況的概率，從而能夠從其它replicat中選擇一個leader。

    c、若是多個replicat同時出現recovery狀態，並且leader宕機（這是極端例子），只能stop全部機器，而後重啓

    2.四、注意

    a、在增長replicat的同時，也會下降片的寫入的速度（由於寫入會DistributedUpdate到各個replicat），能夠考慮先停掉因此的replicat，等leader寫入完成之後，再啓動replicat，不過這隻適用於離線場景，在實時場景，每每有大量的查詢業務須要replicat分擔，寫入與查詢是並行量大

    b、在數據dataimport階段，寫入量大，即便查詢超時也不要去強行stop leader