[
https://issues.apache.org/jira/browse/SOLR-17288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18072370#comment-18072370
]
David Smiley commented on SOLR-17288:
-------------------------------------
The underlying idea is that, _by default_, leadership should be
consistent/sticky and placed in a balanced way instead of being seemingly
arbitrary.
Without this, of course users can set preferredLeader after creating
collections:
{noformat}
curl
"http://localhost:8983/solr/admin/collections?action=BALANCESHARDUNIQUE&collection=my_collection&property=preferredLeader"
{noformat}
And it's easy to forget / not realize that you *should* do this, _especially_
if you exclusively use TLOG replicas.
> automatic preferredLeader
> -------------------------
>
> Key: SOLR-17288
> URL: https://issues.apache.org/jira/browse/SOLR-17288
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: David Smiley
> Priority: Major
>
> I'd like to have the preferredLeader replica property be assigned
> automatically by Solr (if configured to). It would be applied when replicas
> are created for a new shard, like collection creation and restoring a
> collection from a backup. Shard split is maybe different.
> I propose that a
> [ReplicaPlacement|https://github.com/apache/solr/blob/branch_9_6/solr/core/src/java/org/apache/solr/cluster/placement/ReplicaPlacement.java#L35]
> decision, computed by a PlacementPlugin, include a "preferredLeader"
> boolean. Alternatively, we could alter PlacementPlugin.computePlacements
> method contract to further state that the returned order is significant --
> that replicas are created in iteration order. Furthermore, the consumer (in
> Assign) would mark the first replica as preferredLeader.
> A default algorithm could simply choose a preferredLeader at random.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]