[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-5476:
-----------------------------
Description:
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
was:
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=node1_name&node=node2_name
This results in the creation of a entry in the /roles.json in ZK which would
look like the following
{
"overseer" : {
}
}
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 will be picked up
> 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
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
