You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Forest Soup (JIRA)" <ji...@apache.org> on 2014/08/07 10:50:12 UTC
[jira] [Created] (SOLR-6333) Solr node(cores) cannot recover
quickly when there are lots of updates in the good node
Forest Soup created SOLR-6333:
---------------------------------
Summary: Solr node(cores) cannot recover quickly when there are lots of updates in the good node
Key: SOLR-6333
URL: https://issues.apache.org/jira/browse/SOLR-6333
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.7
Environment: Red Hat Enterprise Linux Server release 6.4 (Santiago)
Reporter: Forest Soup
http://lucene.472066.n3.nabble.com/Cannot-finish-recovery-due-to-always-met-ReplicationHandler-SnapPull-failed-Unable-to-download-xxx-fy-td4151611.html#a4151621
I have 2 solr nodes(solr1 and solr2) in a SolrCloud.
After some issue happened, solr2 are in recovering state. The peersync cannot finish in about 15 min, so it turn to snappull.
But when it's doing snap pull, it always met this issue below. Meanwhile, there are still update requests sent to this recovering node(solr2) and the good node(solr1). And the index in the recovering node is deleted and rebuild again and again. So it takes lots of time to finish.
Is it a bug or as solr design?
And could anyone help me on accelerate the progress of recovery?
2014年7月17日 下午5:12:50 ERROR ReplicationHandler SnapPull failed :org.apache.solr.common.SolrException: Unable to download _vdq.fdt completely. Downloaded 0!=182945
SnapPull failed :org.apache.solr.common.SolrException: Unable to download _vdq.fdt completely. Downloaded 0!=182945
at org.apache.solr.handler.SnapPuller$DirectoryFileFetcher.cleanup(SnapPuller.java:1305)
at org.apache.solr.handler.SnapPuller$DirectoryFileFetcher.fetchFile(SnapPuller.java:1185)
at org.apache.solr.handler.SnapPuller.downloadIndexFiles(SnapPuller.java:771)
at org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:421)
at org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:322)
at org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:155)
at org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:437)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:247)
We have below settings in solrconfig.xml:
<autoCommit>
<maxDocs>1000</maxDocs>
<maxTime>${solr.autoCommit.maxTime:15000}</maxTime>
<openSearcher>true</openSearcher>
</autoCommit>
<autoSoftCommit>
<maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime>
</autoSoftCommit>
and the <maxIndexingThreads>8</maxIndexingThreads> is as default.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org