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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to