[
https://issues.apache.org/jira/browse/SOLR-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-5991.
----------------------------------
Resolution: Fixed
Fixed with the checkins under SOLR-6491.
I'm calling this closed after the rebalancing done in SOLR-6517. There's still
room for causing a specific node to become leader (or stop being leader), but
let's raise that as a new JIRA if necessary.
There's also probably some new functionality in the offing (no JIRA yet) to
take a node offline for everything _except_ indexing. The idea here is to do
the minimal work to keep from having to re-synchronize. This'll avoid being
Overseer, shard leader, and processing queries and only accept incoming
updates. Details TBD.
Anyway, between the two I think the functionality of this JIRA can be
accomplished.
> 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
