[
https://issues.apache.org/jira/browse/SOLR-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154947#comment-14154947
]
Erick Erickson commented on SOLR-6513:
--------------------------------------
Shalin:
The biggest bit here is that by having a property and inserting itself at the
head of the list for leader election, the cluster will tend to self-correct.
That is, every time a leader election occurs, the replica with the property
should be at the head of the list (assuming it's active) and become the leader.
Most of the time, this will probably be "good enough", but in the pathological
case of things getting really out of whack, hitting the "relect leaders" API
call (SOLR-6517) will re-distribute leadership.
So one scenario is to set up a cluster, call this API and not have to
redistribute the leaders periodically via SOLR-6517.
Additionally, as discussed in SOLR-6491, there's no real substitute for an
operations person's knowledge of the system. Consider a cluster of
heterogeneous machines hosting multiple collections, some of which have heavy
traffic and some of which do not. Even creating a way to characterize that kind
of setup in a general way such that having only a "rebalance your leaders now"
command would do the right thing hurts my head.
> 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]
