Thanks for looking this up.
It could be a hint where to jump into the code.
I wonder why they rejected a jira ticket about this problem?
Regards, Bernd
Am 06.12.18 um 16:31 schrieb Vadim Ivanov:
Is solr-dev forum I came across this post
http://lucene.472066.n3.nabble.com/Rebalance-Leaders-Leader-node-deleted-when-rebalancing-leaders-td4417040.html
May be it will shed some light?
-----Original Message-----
From: Atita Arora [mailto:atitaar...@gmail.com]
Sent: Thursday, November 29, 2018 11:03 PM
To: solr-user@lucene.apache.org
Subject: Re: REBALANCELEADERS is not reliable
Indeed, I tried that on 7.4 & 7.5 too, indeed did not work for me as well,
even with the preferredLeader property as recommended in the
documentation.
I handled it with a little hack but certainly this dint work as expected.
I can provide more details if there's a ticket.
On Thu, Nov 29, 2018 at 8:42 PM Aman Tandon
<amantandon...@gmail.com> wrote:
++ correction
On Fri, Nov 30, 2018, 01:10 Aman Tandon <amantandon...@gmail.com
wrote:
For me today, I deleted the leader replica of one of the two shard
collection. Then other replicas of that shard wasn't getting elected for
leader.
After waiting for long tried the setting addreplicaprop preferred leader
on one of the replica then tried FORCELEADER but no luck. Then also tried
rebalance but no help. Finally have to recreate the whole collection.
Not sure what was the issue but both FORCELEADER AND REBALANCING
didn't
work if there was no leader however preferred leader property was setted.
On Wed, Nov 28, 2018, 12:54 Bernd Fehling <
bernd.fehl...@uni-bielefeld.de
wrote:
Hi Vadim,
thanks for confirming.
So it seems to be a general problem with Solr 6.x, 7.x and might
be still there in the most recent versions.
But where to start to debug this problem, is it something not
correctly stored in zookeeper or is overseer the problem?
I was also reading something about a "leader queue" where possible
leaders have to be requeued or something similar.
May be I should try to get a situation where a "locked" core
is on the overseer and then connect the debugger to it and step
through it.
Peeking and poking around, like old Commodore 64 days :-)
Regards, Bernd
Am 27.11.18 um 15:47 schrieb Vadim Ivanov:
Hi, Bernd
I have tried REBALANCELEADERS with Solr 6.3 and 7.5
I had very similar results and notion that it's not reliable :(
--
Br, Vadim
-----Original Message-----
From: Bernd Fehling [mailto:bernd.fehl...@uni-bielefeld.de]
Sent: Tuesday, November 27, 2018 5:13 PM
To: solr-user@lucene.apache.org
Subject: REBALANCELEADERS is not reliable
Hi list,
unfortunately REBALANCELEADERS is not reliable and the leader
election has unpredictable results with SolrCloud 6.6.5 and
Zookeeper 3.4.10.
Seen with 5 shards / 3 replicas.
- CLUSTERSTATUS reports all replicas (core_nodes) as state=active.
- setting with ADDREPLICAPROP the property preferredLeader to other
replicas
- calling REBALANCELEADERS
- some leaders have changed, some not.
I then tried:
- removing all preferredLeader properties from replicas which
succeeded.
- trying again REBALANCELEADERS for the rest. No success.
- Shutting down nodes to force the leader to a specific replica left
running.
No success.
- calling REBALANCELEADERS responds that the replica is inactive!!!
- calling CLUSTERSTATUS reports that the replica is active!!!
Also, the replica which don't want to become leader is not in the
list
of collections->[collection_name]->leader_elect->shard1..x->election
Where is CLUSTERSTATUS getting it's state info from?
Has anyone else problems with REBALANCELEADERS?
I noticed that the Reference Guide writes "preferredLeader" (with
capital "L")
but the JAVA code has "preferredleader".
Regards, Bernd
