lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <j...@apache.org>
Subject [jira] [Created] (SOLR-6517) CollectionsAPI call REELECTLEADERS
Date Sat, 13 Sep 2014 21:54:33 GMT
Erick Erickson created SOLR-6517:
------------------------------------

             Summary: CollectionsAPI call REELECTLEADERS
                 Key: SOLR-6517
                 URL: https://issues.apache.org/jira/browse/SOLR-6517
             Project: Solr
          Issue Type: New Feature
    Affects Versions: 4.11, 5.0
            Reporter: Erick Erickson
            Assignee: Erick Erickson


Perhaps the final piece of SOLR-6491. Once the preferred leadership roles are assigned, there
has to be a command "make it so Mr. Solr". This is something of a placeholder to collect ideas.
One wouldn't want to flood the system with hundreds of re-assignments at once. Should this
be synchronous or asnych? Should it make the best attempt but not worry about perfection?
Should it???

a collection=name parameter would be required and it would re-elect all the leaders that were
on the 'wrong' node

I'm thinking an optionally allowing one to specify a shard in the case where you wanted to
make a very specific change. Note that there's no need to specify a particular replica, since
there should be only a single preferredLeader per slice.

This command would do nothing to any slice that did not have a replica with a preferredLeader
role. Likewise it would do nothing if the slice in question already had the leader role assigned
to the node with the preferredLeader role.



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