SolrCloud的集群启动慢的调查

最新推荐文章于 2019-09-06 17:32:30 发布

果然如此

最新推荐文章于 2019-09-06 17:32:30 发布

阅读量2.8k

点赞数

分类专栏： solr

solr 专栏收录该内容

13 篇文章 0 订阅

订阅专栏

在维护SolrCloud 集群过程中，最害怕的重启SolrCloud 集群，因为这需要等待很长的时间。
至于为啥要等待这么长的时间，到了今天我才花了点时间弄明白了。了解原理之后我也找到了快速重启集群的方法。
首先我们要说明的是，SolrCloud 集群在重启过程中步骤。
1.启动core实例，加载配置，replay log。这个不是本文所讲述的重点，暂时不去探讨。
2.Recover 、Sync恢复和同步。
整个事件就花费在recover和sync上面。
那么这个过程到底做了什么？
通过对比日志和代码，solr会把第一个启动实例作为集群中的leader，这个leader在启动的时候，首先做recover和sync，

Leader在做同步和恢复的时候的日志

27771 [coreLoadExecutor-4-thread-23] INFO  org.apache.solr.cloud.SyncStrategy  – Sync replicas to http://192.168.1.166:9080/solr/testcore_r1/
27771 [coreLoadExecutor-4-thread-23] INFO  org.apache.solr.update.PeerSync  – PeerSync: core=testcore_r1 url=http://192.168.1.166:9080/solr START replicas=[http://192.168.1.165:9080/solr/testcore/] nUpdates=100
27903 [coreLoadExecutor-4-thread-43] INFO  org.apache.solr.cloud.ShardLeaderElectionContext  – Enough replicas found to continue.
27903 [coreLoadExecutor-4-thread-43] INFO  org.apache.solr.cloud.ShardLeaderElectionContext  – I may be the new leader - try and sync

从日志可以看出：作为leader的实例会发送http请求要求其他replica来向他自身进行recover和sync，但是此时由于leader和replica的web容器都还未启动好，所以发送请求是不成功，也就是会超时，这个超时恰好就是30秒，该timeout时间是在
SyncStrategy.requestRecovery()：
server.setConnectionTimeout(30000);
server.setSoTimeout(120000);

这段代码到处可见。

所以在30秒时候就会出现超时，此时solr就会将这种情况是为自己已经准备好。

57406 [coreLoadExecutor-4-thread-14] WARN org.apache.solr.update.PeerSync – PeerSync: core=testcore_r1 url=http://192.168.1.166:9080/solr couldn't connect to http://192.168.1.165:9080/solr/testcore/, counting as success
57407 [coreLoadExecutor-4-thread-14] INFO org.apache.solr.update.PeerSync – PeerSync: core=testcore_r1 url=http://192.168.1.166:9080/solr DONE. sync succeeded

一旦solr的leader实例将自己的同步状态视为成功。此时他就再一次会去向replica发送同步命令。同样此时leader和replica的实例都没有准备好。

57408 [coreLoadExecutor-4-thread-14] INFO org.apache.solr.cloud.SyncStrategy – http://192.168.1.166:9080/solr/testcore_r1/: try and ask http://192.168.1.165:9080/solr/testcore/ to sync

Replica日志如下：

24149 [RecoveryThread] INFO org.apache.solr.cloud.RecoveryStrategy – ###### startupVersions=[]
24149 [RecoveryThread] INFO org.apache.solr.cloud.ZkController – publishing core=defaultcore1 state=recovering
24149 [RecoveryThread] INFO org.apache.solr.cloud.ZkController – numShards not found on descriptor - reading it from system property
25629 [localhost-startStop-1-EventThread] INFO org.apache.solr.common.cloud.ZkStateReader – A cluster state change: WatchedEvent state:SyncConnected type:NodeDataChanged path:/clusterstate.json, has occurred - updating... (live nodes size: 2)
。。。

从replica的日志上看你觉得他正在做recovery，但是我认为，由于web容器根本还没有启动好，根本不能接受和响应http请求，所以在SyncStrategy 中，到这里，我觉得http线程会timeout的。

这时你只有等待，等待，solr完成同步和恢复。于是你就等啊等啊，5分钟，10分钟，15分钟。。还没好。。

奇迹发生在780秒以后（是第18分钟），780秒之后，随着一大对异常的抛出，你集群好像活了，至少leader活了，并且replica上面的一些core活了。此时你要做的是将replica节点重新启动一遍，这一次，你发现replica启动非常快。

但是为什么需要等待18分钟？答案是solr这么固定了这个时间，SolrCloud的lead选举中设置了780（600+180）秒来作为leader选举的超时时间。至于代码么，就在org.apache.solr.cloud.ZkController.getLeaderProps中：
String leaderUrl = getLeader(cloudDesc, leaderVoteWait + 600000);

这里的leaderVoteWait 时间ConfigSolr.DEFAULT_LEADER_VOTE_WAIT=180

以上代码就解释了为啥要等待18秒。

由于在web 容器启动过程中，阻塞了http的请求，所以lead向replica发送出来的请求都会超时，超时时长如前面所述：30秒。

所以总共要等待的时间是30+780=810秒，也就是说重启集群你至少需要810秒。

实际上在leader完成自身的同步之后，并没有能讲集群的leader信息写入到zk上面，而replica就是需要依赖在zk上面元数据，这样就会出现了死锁，只能利用超时来强行关闭replica上面的core。
那么如何要加快这个过程呢，答案是在集群重启之后，replica和leader都启动了，让leader尽快知道replica死了，也就是发送的http返回connection异常，而不是一直等待。
当leader发现replica死了之后，他就跳过等待replica的步骤，直接向zk上面写元数据。
当zk上面的有关集群的描述的元数据好了之后，再去启动replica就会，replica启动就会很快。

-----------------------------------------------------------------------------------------------------------------------------------------

当一个leader挂掉后，其中的几个replica 要重新选一个leader出来，但默认的是要等待3分钟，这个时间也太长了。对于开始在测试solrCloud功能来说，等待这么长时间，有可能觉得重新选举失败的挫败感。

这里4.1之后已解决了这个bug：https://issues.apache.org/jira/browse/SOLR-3940

默认情况下可以看到，当某个leader挂彩了时候，日志打印如下：

INFO: Waiting until we see more replicas up: total=3 found=1 timeoutin=171467  
Dec 19, 2012 10:14:40 AM org.apache.solr.cloud.ShardLeaderElectionContext waitForReplicasToComeUp  
INFO: Waiting until we see more replicas up: total=3 found=1 timeoutin=170965  
Dec 19, 2012 10:14:41 AM org.apache.solr.cloud.ShardLeaderElectionContext waitForReplicasToComeUp  
INFO: Waiting until we see more replicas up: total=3 found=1 timeoutin=170463  
Dec 19, 2012 10:14:41 AM org.apache.solr.cloud.ShardLeaderElectionContext waitForReplicasToComeUp  
INFO: Waiting until we see more replicas up: total=3 found=1 timeoutin=169961

你可以只接受3分钟的等待，您也可以降低等待3分钟（如10秒或0秒）

配置选举等待时间：
在solr.xml上配置：
leaderVoteWait="${leaderVoteWait:20000}"

<?xml version="1.0" encoding="UTF-8" ?>
<solr persistent="true">
<cores defaultCoreName="video_shard1" adminPath="/admin/cores" zkClientTimeout="${zkClientTimeout:1500}" hostPort="${jetty.port:}" hostContext="solr" leaderVoteWait="${leaderVoteWait:20000}">

</cores>
</solr>