If you want to plan to have 2 shards and if you start up the first node it will be the leader of first shard. When you start up second node it will be the leader of second shard. If you start up third node it will be the replica of first shard. If you start up fourth node it will be the replica of second shard. If you start up fifth node it will be the replica of first shard ... and this will continue as like that as round robin.
2013/7/11 aabreur <alexandre.ab...@vtex.com.br> > I have a working Zookeeper ensemble running with 3 instances and also a > solrcloud cluster with some solr instances. I've created a collection with > settings to 2 shards. Then i: > > create 1 core on instance1 > create 1 core on instance2 > create 1 core on instance1 > create 1 core on instance2 > > Just to have this configuration: > > instance1: shard1_leader, shard2_replica > instance2: shard1_replica, shard2_leader > > If i add 2 cores to instance1 then 2 cores to instance2, both leaders will > be on instance1 and no re-election is done. > > instance1: shard1_leader, shard2_leader > instance2: shard1_replica, shard2_replica > > Back to my ideal scenario (detached leaders), also when i add a third > instance with 2 replicas and kill one of my instances running a leader, the > election picks the instance that already have a leader. > > My question is why Zookeeper takes this behavior. Shouldn't it distribute > leaders? If i deliver some stress to a double-leader instance, is Zookeeper > going to run an election? > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Leader-Election-when-tp4077381.html > Sent from the Solr - User mailing list archive at Nabble.com. >
