You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Bruno Roustant (Jira)" <ji...@apache.org> on 2023/03/03 10:08:00 UTC
[jira] [Comment Edited] (SOLR-16438) Shard split should be able to set preferred leaders on other replicas
[ 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-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org