[
https://issues.apache.org/jira/browse/SOLR-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Forest Soup updated SOLR-6333:
------------------------------
Attachment: solrconfig.xml
my config are in this file
> 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
> Attachments: solrconfig.xml
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
