技术库 > Java

SolrCloud的集群启动慢的原因

技术库:tec.5lulu.com

在维护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时间是在
  1. SyncStrategy.requestRecovery():  
  2.   server.setConnectionTimeout(30000);  
  3.   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中:
  1. 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启动就会很快。

SolrCloud的集群启动慢的原因


标签: solr本文链接 http://tec.5lulu.com/detail/110dmn2eh2gcw8562.html

我来评分 :6.1
0

转载注明:转自5lulu技术库

本站遵循:署名-非商业性使用-禁止演绎 3.0 共享协议

www.5lulu.com