In response to this mistake that I did of keeping the core.properties in the configuration directory when it was uploaded to zookeeper, how should I go about fixing it?
Thank you On Thursday, September 20, 2018, Schaum Mallik <schaum.mal...@gmail.com> wrote: > Hi Eric > > I created the collection the way you detailed it in here. The > configuration directory for the collections was copied over from the > standalone solr 6. the core.properties existed in the conf directory and I > didn’t realize it would cause this issue. > > Also all the nodes are solr 7.4. > > Thank you > > On Thursday, September 20, 2018, Erick Erickson <erickerick...@gmail.com> > wrote: > >> I agree with Shawn that having >> instanceDir=/opt/solr/server/solr/configsets/articles as where your >> core is located is strange, how are you starting Solr? In particular, >> do those nodes use a "-s' parameter to redefine SOLR_HOME? >> >> The "-d" option (assuming you created the collection with bin/solr) >> just tells Solr where the configset you're using is located on your >> local disk, it does _not_ put the instanceDir there, it just looks for >> the configset to upload to ZK. >> >> Check if there's a "core.properties" file in >> "/opt/solr/server/solr/configsets/articles". The presence of that file >> indicates that that's the home of the replica. >> >> Now to the very weird bit. This sounds an awful lot like >> https://issues.apache.org/jira/browse/SOLR-11503. Especially if your >> old system was Solr 6.6.1 or 6.6.2.. Short form, "core.properties" >> needs to contain a, you guessed it, "coreNodeName" property that >> corresponds to what's in ZooKeeper. >> >> However, I simply cannot reconcile this being the problem with what >> you're reporting. There's code in 7x that repairs this issue >> automatically. Is there any chance for the node in question that it's >> _not_ running 7.4 and still on 6.6.1/2? Maybe Shawn's latest comment >> would reconcile that? >> >> How to fix. Well, fixing should be automatic unless the fixer-upper >> code is no longer in 7.4, but on a quick check the code _is_ in 7.4. >> > Make very, very sure the Solr you're running on the nodes in question >> is 7.4, or at least _NOT_ 6.6.1/2 >> > Make very, very sure that you don't specify some strange "-s" parameter >> or have defined SOLR_HOME to point to >> /opt/solr/server/solr/configsets/articles, >> although that shouldn't really matter. >> > When you DELETEREPLICA, go to the node and manually see if the >> directory /opt/solr/server/solr/configsets/articles exists. It shouldn't >> (see the deleteInstanceDir option in the DELETEREPLICA for why). >> >> If none of that makes any difference, please show us the full output of >> > ps aux | grep solr >> > export (looking for you redefining SOLR_HOME) >> > the "core.properties" file in the indicated directory. >> >> Best, >> Erick >> >> On Thu, Sep 20, 2018 at 7:36 AM Shawn Heisey <apa...@elyograg.org> wrote: >> > >> > On 9/20/2018 8:22 AM, Schaum Mallik wrote: >> > > Thanks for the response Shawn. >> > > >> > > My follow up question is how would the zookeeper ensemble know that >> the >> > > location of the indexes has changed? Also do I need to apply the same >> > > changes to the other 2 solr nodes which are working fine? >> > >> > This move is not to change the location, it's to stop Solr from trying >> > to load the indexes completely. Solr will no longer try to load them. >> > I think these are invalid indexes from when the Solr instance was NOT >> > running in cloud mode, and have nothing at all to do with your working >> > collections. But just in case I'm wrong, I'm having you move them >> > instead of delete them, so they can be put back if it turns out they >> > actually were needed. >> > >> > ZooKeeper doesn't know anything at all about Solr and the data it puts >> > in ZK. It is just a service that stores cluster data where all nodes >> > can read it and handles elections when it is asked to. >> > >> > Thanks, >> > Shawn >> > >> >
