Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Thu, 5 Oct 2017 15:36:00 +0000 (UTC)
From: "Mark Miller (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.13106901.1507110840000.279880.1507217760377@Atlassian.JIRA>
In-Reply-To: <JIRA.13106901.1507110840000@Atlassian.JIRA>
References: <JIRA.13106901.1507110840000@Atlassian.JIRA> <JIRA.13106901.1507110840178@jira-lw-us.apache.org>
Subject: [jira] [Commented] (SOLR-11435) Replicas failed to be deleted can
 overwrite replicas of recreated collections
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 05 Oct 2017 15:36:04 -0000


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

Mark Miller commented on SOLR-11435:
------------------------------------

We should add a test for this for sure.

bq. I think we should add it back when users are not using the autoAddReplica feature?

That may be a good short term fix, but we should consider how this all works with legacyCloud=false and the new autoAddReplica replacement longer term.

Another option is to just revert that change for now, even with it's affect on autoAddReplica, given the nightly test was broken some time ago and a variety of things could be broken now.

Also though, I wonder if SOLR-7248 was really the right fix for this issue. Using the coreNodeName is a very simple design to understand. This complicated things. Can we not prevent this behavior in a better way?

The most important thing is to have a test for this though.

> Replicas failed to be deleted can overwrite replicas of recreated collections
> -----------------------------------------------------------------------------
>
>                 Key: SOLR-11435
>                 URL: https://issues.apache.org/jira/browse/SOLR-11435
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: 7.0
>            Reporter: Mano Kovacs
>
> When a replica comes up that was deleted from ZK while it was gone, it can replace replicas in ZK if the collection an core names are equal.
> Reproduction:
> # Create {{collection1}} with 1 shard, 2 replicas on {{node1}} and {{node2}}
> # Shut down {{node2}}
> # Delete {{collection1}}
> # Create {{collection1}} on {{node1}} and {{node3}}
> # Start {{node2}}
> Expected:
> {{node2}} will not initialize node as it is not assigned to in ZK ({{legacyCloud=false}})
> Actual:
> {{node2}} will overwrite the {{baseurl}} in {{state.json}} for one of the replicas as the {{coreNodeName}} and the collection name will match the core it has.
> Note: SOLR-7248 introduced a {{baseurl}} comparison which was removed in SOLR-10279.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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