For me today, I deleted the leader replica of one of the two shard collection. Then other replica of that shard was 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 > > >
