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