-
google后某个人说因为更新solr的document导致solr内部没有同步造成,之后查找该方面资料,没有详细说明。
-
后来想到当初制造shard的split,如果原始shard没有删除,那么查询可能会落在原始shard,但新的insert只会进入新shard,造成查询结果不同步,那么会不会因为查了不同的shard造成结果不同呢?
-
接下来尝试针对不同shard进行查询(distrib=false),同一个shard的lead节点和replica节点出现的结果集不同
-
然后看哪个replica节点的日志,发现某个时间点恢复失败了(因为当初更新solr的jar包进行了重启,中间出现了同步失败的错误),估计solr失败后由于内部某方面的bug,没有尽心个标记从而继续进行replica操作
-
重启replica节点,期望别不行啊,不然蛮难恢复的,但结果是成功恢复了那一部分的数据(同步失败的那一部分)
综合分析,因为查询被solrcloud分配到不同shard进行查询因为得到不同步的结果,这点没问题。但是为什么得到不同步的结果这个还有待Review,今后可以注意的是重启solr的时候如果不是集群整个重启,那么最好针对同一个shard的replicas节点分别重启,即一个重启成功并且恢复成功以后再重启另外一个,如果发现recovery fail,那么需要立即查看是否有不同步,减少这类事件的发生