Then something sounds wrong with your setup. The configs are stored in ZK, and read from ZooKeeper every time Solr starts. So how the replica “does not have the correct schema” is a complete mystery.
You say you have ClassicIndexSchemaFactory set up. Take a look at your configs _through the Admin UI from the “collections” drop-down_ and verify. This reads the same thing in ZooKeeper. Sometimes I’ve thought I was set up one way and discovered later that I wasn’t. Next: Do you have “managed-schema” _and_ “schema.xml” in your configs? If you’re indeed using classic, you can remove managed-schema. All to make sure your’e operating as you think you are. Best, Erick > On Sep 24, 2019, at 3:58 PM, Antony A <antonyaugus...@gmail.com> wrote: > > Hi, > > I also observed that whenever the JVM crashes, the replicas does not have > the correct schema. Anyone seen similar behavior. > > Thanks, > AA > > On Wed, Sep 4, 2019 at 9:58 PM Antony A <antonyaugus...@gmail.com> wrote: > >> Hi, >> >> I have confirmed that ZK ensemble is external. Even though both >> managed-schema and schema.xml are on the admin ui, I see the below class >> defined in solrconfig. >> <schemaFactory class="ClassicIndexSchemaFactory" /> >> >> The workaround is till to run "solr zk upconfig" followed by restarting >> the cores of the collection. Anything else I should be looking into? >> >> Thanks >> >> On Wed, Sep 4, 2019 at 6:31 PM Erick Erickson <erickerick...@gmail.com> >> wrote: >> >>> This almost always means that you really _didn’t_ update the schema and >>> reload the collection, you just thought you did ;). >>> >>> One common reason is to fire up Solr with an internal ZooKeeper but have >>> the rest of your collection be using an external ensemble. >>> >>> Another is to be modifying schema.xml when using managed-schema or >>> vice-versa. >>> >>> First thing I’d do is check the ZK ensemble, are any of the ports >>> reference by the admin screen anywhere 9983? If so it’s internal. >>> >>> Second thing I’d do is, in the admin UI, select my collection from the >>> drop down list, then click files and open up the schema. Check that there >>> is only managed-schema or schema.xml. If both are present, check your >>> solrconfig to see which one you’re using. Then open the schema and check >>> that your field is there. BTW, the field will be explicitly stated in the >>> solr log. >>> >>> Third thing I’d do is open the admin >>> UI>>configsets>>the_configset_you’re_using and check which schema you’re >>> using and again if the field is in the schema. >>> >>> Best, >>> Erick >>> >>>> On Sep 4, 2019, at 3:27 PM, Antony A <antonyaugus...@gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> I ran the collection reload after a new "leader" core was selected for >>> the >>>> collection due to heap failure on the previous core. But I still have >>> stack >>>> trace with common.SolrException: undefined field. >>>> >>>> On Thu, Aug 29, 2019 at 1:36 PM Antony A <antonyaugus...@gmail.com> >>> wrote: >>>> >>>>> Yes. I do restart the cores on all the different servers. I will look >>> at >>>>> implementing reloading the collection. Thank you for your suggestion. >>>>> >>>>> Cheers, >>>>> Antony >>>>> >>>>> On Thu, Aug 29, 2019 at 1:34 PM Shawn Heisey <apa...@elyograg.org> >>> wrote: >>>>> >>>>>> On 8/29/2019 1:22 PM, Antony A wrote: >>>>>>> I do restart Solr after changing schema using "solr zk upconfig". I >>> am >>>>>> yet >>>>>>> to confirm but I do have a daily cron that does "delta" import. Does >>>>>> that >>>>>>> process have any bearing on some cores losing the field? >>>>>> >>>>>> Did you restart all the Solr servers? If the collection lives on >>>>>> multiple servers, restarting one of the servers is not going to affect >>>>>> replicas living on other servers. >>>>>> >>>>>> Reloading the collection with an HTTP request to the collections API >>> is >>>>>> a better option than restarting Solr. >>>>>> >>>>>> Thanks, >>>>>> Shawn >>>>>> >>>>> >>> >>>
