lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-6513) Add a collectionsAPI call BALANCESLICEUNIQUE
Date Tue, 30 Sep 2014 18:28:34 GMT

     [ https://issues.apache.org/jira/browse/SOLR-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Erick Erickson updated SOLR-6513:
---------------------------------
    Description: 
Another sub-task for SOLR-6491. The ability to assign a property on a node-by-node basis is
nice, but tedious to get right for a sysadmin, especially if there are, say, 100s of nodes
hosting a system. This JIRA would essentially provide an automatic mechanism for assigning
a property. This particular command simply changes the cluster state, it doesn't do anything
like re-assign functions.

My idea for this version is fairly limited. You'd have to specify a collection and there would
be no attempt to, say, evenly distribute the preferred leader role/property for this collection
by looking at _other_ collections. Or by looking at underlying hardware capabilities. Or....

It would be a pretty simple round-robin assignment. About the only intelligence built in would
be to change as few roles/properties as possible. Let's say that the correct number of nodes
for this role turned out to be 3. Any node currently having 3 properties for this collection
would NOT be changed. Any node having 2 properties would have one added that would be taken
from some node with > 3 properties like this.

This probably needs an optional parameter, something like "includeInactiveNodes=true|false"

Since this is an arbitrary property, one must specify sliceUnique=true. So for the "preferredLeader"
functionality, one would specify something like:
action=BALANCESLICEUNIQUE&property=preferredLeader&proprety.value=true.

There are checks in this code that require the preferredLeader to have a t/f value and require
that sliceUnique bet true. That said, this can be called on an arbitrary property that has
only one such property per slice.

  was:
Another sub-task for SOLR-6491. The ability to assign a preferred leader on a node-by-node
basis is nice, but tedious to get right for a sysadmin, especially if there are, say, 100s
of nodes hosting a system. This JIRA would essentially provide an automatic mechanism for
assigning these roles (or properties). This particular command would NOT re-elect leaders,
just change the flag in the clusterstate.

My idea for this version is fairly limited. You'd have to specify a collection and there would
be no attempt to, say, evenly distribute the preferred leader role/property for this collection
by looking at _other_ collections. Or by looking at underlying hardware capabilities. Or....

It would be a pretty simple round-robin assignment. About the only intelligence built in would
be to change as few roles/properties as possible. Let's say that the correct number of nodes
for this role turned out to be 3. Any node currently having 3 preferred leaders for this collection
would NOT be changed. Any node having 2 preferred leaders would have one added that would
be taken from some node with > 3 preferred leaders.

This probably needs an optional parameter, something like "includeInactiveNodes=true|false"

        Summary: Add a collectionsAPI call BALANCESLICEUNIQUE  (was: Add a collectionsAPI
call ASSIGNPREFERREDLEADERS)

> Add a collectionsAPI call BALANCESLICEUNIQUE
> --------------------------------------------
>
>                 Key: SOLR-6513
>                 URL: https://issues.apache.org/jira/browse/SOLR-6513
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>         Attachments: SOLR-6513.patch
>
>
> Another sub-task for SOLR-6491. The ability to assign a property on a node-by-node basis
is nice, but tedious to get right for a sysadmin, especially if there are, say, 100s of nodes
hosting a system. This JIRA would essentially provide an automatic mechanism for assigning
a property. This particular command simply changes the cluster state, it doesn't do anything
like re-assign functions.
> My idea for this version is fairly limited. You'd have to specify a collection and there
would be no attempt to, say, evenly distribute the preferred leader role/property for this
collection by looking at _other_ collections. Or by looking at underlying hardware capabilities.
Or....
> It would be a pretty simple round-robin assignment. About the only intelligence built
in would be to change as few roles/properties as possible. Let's say that the correct number
of nodes for this role turned out to be 3. Any node currently having 3 properties for this
collection would NOT be changed. Any node having 2 properties would have one added that would
be taken from some node with > 3 properties like this.
> This probably needs an optional parameter, something like "includeInactiveNodes=true|false"
> Since this is an arbitrary property, one must specify sliceUnique=true. So for the "preferredLeader"
functionality, one would specify something like:
> action=BALANCESLICEUNIQUE&property=preferredLeader&proprety.value=true.
> There are checks in this code that require the preferredLeader to have a t/f value and
require that sliceUnique bet true. That said, this can be called on an arbitrary property
that has only one such property per slice.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message