lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noble Paul (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-5476) Overseer Role for nodes
Date Mon, 30 Dec 2013 11:18:51 GMT

     [ 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=addrole&role=overseer&node=192.168.1.5:8983_solr

This results in the creation of a entry in the /roles.json in ZK which would look like the
following

{code:javascript}
{
"overseer" : ["192.168.1.5:8983_solr"]
}
{code}
If a node is designated for overseer it gets preference over others when overseer election
takes place. If no designated servers are available another random node would become the Overseer.

Later on, if one of the designated 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=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

{code:javascript}
{
"overseer" : ["192.168.1.5:8983_solr", "192.168.1.6:8983_solr"]
}
{code}
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




> 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
>         Attachments: SOLR-5476.patch
>
>
> 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=addrole&role=overseer&node=192.168.1.5:8983_solr
> This results in the creation of a entry in the /roles.json in ZK which would look like
the following
> {code:javascript}
> {
> "overseer" : ["192.168.1.5:8983_solr"]
> }
> {code}
> If a node is designated for overseer it gets preference over others when overseer election
takes place. If no designated servers are available another random node would become the Overseer.
> Later on, if one of the designated 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message