[
https://issues.apache.org/jira/browse/SOLR-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe reopened SOLR-5991:
-----------------------------------------
I'd like to reopen this Jira, some of what was discussed here is not really
resolved by the linked Jiras. The work done allows one to move the leader of a
shard of a collection off of a node, however for the purpose of shutting down
hosts (either a single one of multiple) this is not enough. First, in order to
achieve this for multiple collections one should go though all the cores of a
node and for each one, find a replica in the cluster in a node that is not
being shutdown and make it leader. But even then, collections that are created
(or replicas added) during this process can still land in these nodes that are
trying to be removed.
I like the idea that was discussed to use roles, like AVOID_RESPONSIBILITY or
just LEADER (given that OVERSEER already exists) like Anshum proposed. Maybe
there could also be a DATA role to allow/avoid new replicas landing in this
host. These roles would act at the host level instead of per collection (like
SOLR-6220 and SOLR-6491). This would still need the "rebalancereader" or
"forceelection" action or something similar after the roles are set.
I must confess that I'm not yet 100% sure how to implement those roles but
wanted to bring this up and hear feedback before spending hours on it and maybe
realizing it's not even possible. Also, backward compatibility may be a
challenge.
PS: I reopened the Jira instead of creating a new one because it doesn't have
any commit or fix version and I wanted to keep the comments history, let me
know if that's wrong and I need to create a new one.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
