lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ishan Chattopadhyaya (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-6333) Solr node(cores) cannot recover quickly when there are lots of updates in the good node
Date Mon, 21 Nov 2016 17:16:58 GMT

    [ https://issues.apache.org/jira/browse/SOLR-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15684133#comment-15684133
] 

Ishan Chattopadhyaya commented on SOLR-6333:
--------------------------------------------

I used Solr 6.3 to creat two nodes, created a collection with two shards, two replicas each.
Indexed a bunch of documents, restarted one of the nodes, indexed a few documents while restarting
was going on. Upon restarting, there was a recovery attempt by the node and peersync succeeded
without any problems.

I think this issue could've been present on some old Solr version, or there could've been
some network issue. Since I couldn't reproduce this issue, I suggest we close the issue for
now and reopen if someone can assist in reproducing it.

> 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.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message