[
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: [email protected]
For additional commands, e-mail: [email protected]
