[
https://issues.apache.org/jira/browse/SOLR-16438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696108#comment-17696108
]
Bruno Roustant edited comment on SOLR-16438 at 3/3/23 10:07 AM:
----------------------------------------------------------------
Fully reverted these commits (the initial and the 2 fixes).
Setting the preferred leader flag during split is ok. But the approach taken to
rebalance the leaders after the split was not correct. The waiting operation
made the async split request become synchronous, potentially holding locks and
timeouting.
We'll probably come back with another approach later.
was (Author: broustant):
Fully reverted these PRs (the initial and the 2 fixes).
Setting the preferred leader flag during split is ok. But the approach taken to
rebalance the leaders after the split was not correct. The waiting operation
made the async split request become synchronous, potentially holding locks and
timeouting.
We'll probably come back with another approach later.
> Shard split should be able to set preferred leaders on other replicas
> ---------------------------------------------------------------------
>
> Key: SOLR-16438
> URL: https://issues.apache.org/jira/browse/SOLR-16438
> Project: Solr
> Issue Type: Improvement
> Reporter: Bruno Roustant
> Assignee: Bruno Roustant
> Priority: Major
> Fix For: 9.2
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, shard split always create a first replica for each sub-shard on
> the current host. Then it creates other replicas and their corresponding
> sub-shards are in RECOVERY state. The effect is that the first replica (on
> the current host) is always the leader, meaning that if the sub-shards are
> split themselves, their sub-sub-shards leaders are also on the same host.
> This can lead to very unbalanced situation where the same host is the leader
> for a whole set of shards.
> A solution to distribute evenly the leaders is to flag some other replicas
> with the preferredLeader property during the split. Then a rebalance-leaders
> command can elect the appropriate leaders. If we do that for each split, then
> all the sub-shards have their leaders correctly balanced.
> To go further, we can improve CollectionsHandler#CollectionOperation to
> support combined operations. That way a CollectionOperation#SPLITSHARD_OP can
> trigger a split op, then a wait for split completion op, and then a rebalance
> leaders op.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
