关于SolrCloud的集群启动慢的原因调查

原创，转载请注明出处


在维护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启动就会很快。