[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13856797#comment-13856797
]
Noble Paul commented on SOLR-5476:
----------------------------------
The strategy to implement this is as follows
Prioritization logic run at Overseer node
* Any Overseer elect would first check for the presence of /roles.json in ZK.
If not return
* lookup the children of /overseer_elect node and see if there are nodes with
Overseer roles among children. If not return
* All nodes whose seq number is smaller than that of the first Overseer role
node is asked to disconnect and reconnect . So that those nodes will append
themselves to the tail of the list and the Overseer role node would come up at
the head
* After this process , the Overseer checks if it is itself an Overseer role
node , If not ,relinquish it's Overseer position and go back to election
If a new node comes up who is assigned an Overseer role, it has to ensure that
it is at the head of the election queue ,
* If any new node comes up, it checks for the /roles.json . If present , checks
if it is assigned an overseer role, if yes , it checks if the head of the
election queue is a node with Overseer role. If not, send a message to the
current Overseer to run the prioritization logic
> Overseer Role for nodes
> -----------------------
>
> Key: SOLR-5476
> URL: https://issues.apache.org/jira/browse/SOLR-5476
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Noble Paul
> Assignee: Noble Paul
>
> In a very large cluster the Overseer is likely to be overloaded.If the same
> node is a serving a few other shards it can lead to OverSeer getting slowed
> down due to GC pauses , or simply too much of work . If the cluster is
> really large , it is possible to dedicate high end h/w for OverSeers
> It works as a new collection admin command
> command=assignRole&whitelist=overseer&node=192.168.1.5:8983_solr&node=192.168.1.6:8983_solr
> This results in the creation of a entry in the /roles.json in ZK which would
> look like the following
> {
> "overseer" : {
> "whitelist":["192.168.1.5:8983_solr",
> "192.168.1.6:8983_solr"]
> }
> }
> If a node is whitelisted for overseer it gets preference over others when
> overseer election takes place. If no whitelisted servers are available
> another random node would become the Overseer.
> Later on, if one of the whitelisted nodes are brought up ,it would take over
> the Overseer role from the current Overseer to become the Overseer of the
> system
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
