Hi Shawn, thanks for replying. My solr version is 4.9.0 at all nodes. I just figured out what was the problem. When I edited the clusterstate.json on exhibitor, I forgot to also edit the file located at: /collections > <collection_name> > leaders > shard There is also a leader config on that file.
Once I updated the leader node on the file to match the one chosen at clusterstate.json and restarted the solr nodes that were facing the problem everything worked fine. Att., Francisco Andrade On Sat, Aug 8, 2015 at 12:04 PM, Shawn Heisey <apa...@elyograg.org> wrote: > On 8/8/2015 8:38 AM, Francisco Andrade wrote: > > Yesterday I had an issue where I needed to update the collection leader > on > > the clusterstate.json editing the file in exhibitor. > > If i access the console through other nodes the leader showing is the > right > > one. > > But it seems to me that the updated clusterstate.json was not sent > properly > > to this specific node. > > > > Any suggestions on how to fix it? > > First, what version of Solr are you running? Do you have the same > version on all nodes? > > I am not familiar enough with the code to try and debug what the log > messages mean, I will just speak in general terms. > > Unless it's the only way to fix a situation that has arisen because of > extraordinary circumstances, it's a bad idea to manually edit what's in > the zookeeper database, and even then, it's a good idea to restart Solr > to be sure it notices the change. > > On the topic of your specific edit, if you want to be able to control > which node is the leader, upgrade to the latest Solr version and use the > new preferred leader capability. I believe it was added in 5.0. > > > https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-RebalanceLeaders > > Something I would try at this point is shutting down and restarting each > Solr instance in your cluster, to be absolutely sure their internal > state agrees with zookeeper. Restarting Solr instances will shuffle > your leaders around, and you may not end up with the leader assignments > you want. The preferred leader feature is a much better way to handle > this. > > Thanks, > Shawn > >
