Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Thu, 19 Jan 2017 23:13:26 +0000 (UTC)
From: "Erick Erickson (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.13036362.1484864339000.57304.1484867606400@Atlassian.JIRA>
In-Reply-To: <JIRA.13036362.1484864339000@Atlassian.JIRA>
References: <JIRA.13036362.1484864339000@Atlassian.JIRA> <JIRA.13036362.1484864339745@jira-lw-us.apache.org>
Subject: [jira] [Commented] (SOLR-10006) Cannot do a full sync (fetchindex)
 if the replica can't open a searcher
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 19 Jan 2017 23:13:31 -0000


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

Erick Erickson commented on SOLR-10006:
---------------------------------------

No, SOLR-9836 doesn't fix this one I'm afraid. The error is:

 'eoe_shard1_replica1' is not available due to init failure: Error opening new searcher
.
.
.
NoSuchFileException: /blahblahblah

The core admin APi REQUESTRECOVERY call fails with: "Could not find core to call recovery..."

Not sure this fixable without major surgery though. And it should be rare enough that manually fixing things like this up isn't onerous.

> Cannot do a full sync (fetchindex) if the replica can't open a searcher
> -----------------------------------------------------------------------
>
>                 Key: SOLR-10006
>                 URL: https://issues.apache.org/jira/browse/SOLR-10006
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: 5.3.1, 6.4
>            Reporter: Erick Erickson
>
> Doing a full sync or fetchindex requires an open searcher and if you can't open the searcher those operations fail.
> For discussion. I've seen a situation in the field where a replica's index became corrupt. When the node was restarted, the replica tried to do a full sync but fails because the core can't open a searcher. The replica went into an endless sync/fail/sync cycle.
> I couldn't reproduce that exact scenario, but it's easy enough to get into a similar situation. Create a 2x2 collection and index some docs. Then stop one of the instances and go in and remove a couple of segments files and restart.
> The replica stays in the "down" state, fine so far.
> Manually issue a fetchindex. That fails because the replica can't open a searcher. Sure, issuing a fetchindex is abusive.... but I think it's the same underlying issue: why should we care about the state of a replica's current index when we're going to completely replace it anyway?


--
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