[
https://issues.apache.org/jira/browse/SOLR-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14552705#comment-14552705
]
Tomás Fernández Löbbe commented on SOLR-5991:
---------------------------------------------
{quote}
Right, the REBALANCE stuff was all about a condition where leaders for a
collection were all landing on the same node...
{quote}
Yes, I understand and I'm not saying that that work is not needed. What I'm
saying is that it may not be enough for the case of decommissioning the node.
{quote}
Assuming that there was a way to add node properties...
{quote}
That is what ADDROLE action in the collection API is doing, right?
{quote}
once that was set wouldn't DELETEREPLICA for all the replicas on that node
essentially decommission it?
{quote}
Yes, but the idea is also make sure they are no leaders. In my mind the process
of shutting down a server (e.g. node1) would be:
# REMOVEROLE DATA for node1 -> Not send any new replica for any existing or new
collection to this node
# REMOVEROLE OVERSEER for node1 -> Don't let this host be elected as overseer
# REMOVEROLE LEADER for node1 -> Don't let any of the replicas of this node to
be shard leader
# for each replica in any collection in node1:
ADDREPLICA -> Create new replicas in different nodes
# REBALANCELEADER for any collection with at least one replica in node1
# (Optional, if the node will be restarted) DELETEREPLICA for all replicas in
node1
# Shutdown node1
In this scenario I'm considering that nodes are started always with the three
of those roles, other option would be AVOID_RESPONSIBILITY and AVOID_DATA or
something like that. In case of having to shutdown many hosts at once, you
could do the steps from 1 to 3 in all the nodes, then proceed with 4 to 7
> SolrCloud: Add API to move leader off a Solr instance
> -----------------------------------------------------
>
> Key: SOLR-5991
> URL: https://issues.apache.org/jira/browse/SOLR-5991
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.7.1
> Reporter: Rich Mayfield
> Assignee: Erick Erickson
>
> Common maintenance chores require restarting Solr instances.
> The process of a shutdown becomes a whole lot more reliable if we can
> proactively move any leadership roles off of the Solr instance we are going
> to shut down. The leadership election process then runs immediately.
> I am not sure what the semantics should be (either accomplishes the goal but
> one of these might be best):
> * A call to tell a core to give up leadership (thus the next replica is
> chosen)
> * A call to specify which core should become the leader
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
