‘Then use "bin/solr zk rm" to get rid of it from ZK.‘ <— can you give the full command for this one if you don’t mind
Thank you On Thursday, September 20, 2018, Erick Erickson <erickerick...@gmail.com> wrote: > bq. 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? > > Oh my. You're saying that core.properties is _in_ ZooKeeper? Never > seen that before ;). > > OK, I think I see what's happening. Somehow you have nodes that have > the core.properties file in your ...solr/server/configsets. Your > SOLR_HOME some ancestor of that directory and the recursive search is > finding it and trying to load it. > > So just remove it from that directory on all the Solr nodes where it > exists. I'd have Solr shut down at the time, but that's probably not > strictly necessary. > > Then use "bin/solr zk rm" to get rid of it from ZK. > > If possible, I'd do all this with all the Solr instances shut down, > but that's probably not absolutely necessary, I'm just paranoid. > > On Thu, Sep 20, 2018 at 8:13 AM Schaum Mallik <schaum.mal...@gmail.com> > wrote: > > > > 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 > > >> > > > >> > > > >
