Thank you very much Erick and Uchida. I will take a look at the URL u gave Erick.
Thanks Ravi Kiran Bhaskar On Fri, Oct 2, 2015 at 12:41 PM, Tomoko Uchida <tomoko.uchida.1...@gmail.com > wrote: > Hi Ravi, > > And for minor additional information, > you may want to look through Collections API reference guide to handle > collections properly in SolrCloud environment. (I bookmark this page.) > https://cwiki.apache.org/confluence/display/solr/Collections+API > <https://cwiki.apache.org/confluence/display/solr/Collections+API> > > Regards, > Tomoko > > 2015-10-03 1:15 GMT+09:00 Erick Erickson <erickerick...@gmail.com>: > > > do we have to "reload" the collections on all the nodes to see the > > updated config ?? > > YES > > > > Is there a single call which can update all nodes connected to the > > ensemble ?? > > > > NO. I'll be a little pedantic here. When you say "ensemble", I'm not > quite > > sure > > what that means and am interpreting it as "all collections registered > with > > ZK". > > But see below. > > > > I just went to the admin UI and hit "Reload" button manually on each > > of the node...Is that > > the correct way to do it ? > > > > NO. The admin UI, "core admin" is a remnant from the old days (like > > 3.x) where there was > > no concept of distributed collection as a distinct entity, you had to > > do all the things you now > > do automatically in SolrCloud "by hand". PLEASE DO NOT USE THIS > > EXCEPT TO VIEW A REPLICA WHEN USING SOLRCLOUD! In particular, don't try > to > > take any action that manipulates the core (reload, add, unload and the > > like). > > It'll work, but you have to know _exactly_ what you are doing. Go > > ahead and use it for > > viewing the current state of a replica/core, but unless you need to do > > something that > > you cannot do with the Collections API it's very easy to go astray. > > > > > > Instead, use the "collections API". In this case, there's a call like > > > > > > > http://localhost:8983/solr/admin/collections?action=RELOAD&name=CollectionName > > > > that will cause all the replicas associated with the collection to be > > reloaded. Given you > > mentioned linkconfig, I'm guessing that you have more than one > > collection looking at a > > particular configset, so the pedantic bit is you'd have to issue the > > above for each > > collection that references that configset. > > > > Best, > > Erick > > > > P.S. Two bits: > > 1> actually the collections API uses the core admin calls to > > accomplish its tasks, but > > lots of effort went in to doing exactly the right thing > > 2> Upayavira has been creating an updated admin UI that will treat > > collections as > > first-class citizens (a work in progress). You can access it in 5.x by > > hitting > > > > solr_host:solr_port/solr/index.html > > > > Give it a whirl if you can and please provide any feedback you can, it'd > > be much > > appreciated. > > > > On Fri, Oct 2, 2015 at 7:47 AM, Ravi Solr <ravis...@gmail.com> wrote: > > > Mr. Uchida, > > > Thank you for responding. It was my fault, I had a update > > processor > > > which takes specific text and string fields and concatenates them into > a > > > single field, and I search on that single field. Recently I used Atomic > > > update to fix a specific field's value and forgot to disable the > > > UpdateProcessor chain...Since I was only updating one field the > aggregate > > > field got messed up with just that field value and hence I had issues > > > searching. I reindexed the data again yesterday night and now it is all > > > good. > > > > > > I do have a small question, when we update the zookeeper ensemble with > > new > > > configs via 'upconfig' and 'linkconfig' commands do we have to "reload" > > the > > > collections on all the nodes to see the updated config ?? Is there a > > single > > > call which can update all nodes connected to the ensemble ?? I just > went > > to > > > the admin UI and hit "Reload" button manually on each of the node...Is > > that > > > the correct way to do it ? > > > > > > Thanks > > > > > > Ravi Kiran Bhaskar > > > > > > On Fri, Oct 2, 2015 at 12:04 AM, Tomoko Uchida < > > tomoko.uchida.1...@gmail.com > > >> wrote: > > > > > >> Are you sure that you've indexed same data to Solr 4.7.2 and 5.3.0 ? > > >> If so, I suspect that you have multiple shards and request to one > shard. > > >> (In that case, you might get partial results) > > >> > > >> Can you share HTTP request url and the schema and default search > field ? > > >> > > >> > > >> 2015-10-02 6:09 GMT+09:00 Ravi Solr <ravis...@gmail.com>: > > >> > > >> > I we migrated from 4.7.2 to 5.3.0. I sourced the docs from 4.7.2 > core > > and > > >> > indexed into 5.3.0 collection (data directories are different) via > > >> > SolrEntityProcessor. Currently my production is all whack because of > > this > > >> > issue. Do I have to go back and reindex all again ?? Is there a > quick > > fix > > >> > for this ? > > >> > > > >> > Here are the results for the query 'obama'...please note the > numfound. > > >> > 4.7.2 has almost 148519 docs while 5.3.0 says it only has 5.3.0 > docs. > > Any > > >> > pointers on how to correct this ? > > >> > > > >> > > > >> > Solr 4.7.2 > > >> > > > >> > <response> > > >> > <lst name="responseHeader"> > > >> > <int name="status">0</int> > > >> > <int name="QTime">2</int> > > >> > <lst name="params"> > > >> > <str name="q">obama</str> > > >> > <str name="rows">0</str> > > >> > </lst> > > >> > </lst> > > >> > <result name="response" numFound="148519" start="0"/> > > >> > </response> > > >> > > > >> > SolrCloud 5.3.0 > > >> > > > >> > <response> > > >> > <lst name="responseHeader"> > > >> > <int name="status">0</int> > > >> > <int name="QTime">2</int> > > >> > <lst name="params"> > > >> > <str name="q">obama</str> > > >> > <str name="rows">0</str> > > >> > </lst> > > >> > </lst> > > >> > <result name="response" numFound="2805" start="0"/> > > >> > </response> > > >> > > > >> > > > >> > Thanks > > >> > > > >> > Ravi Kiran Bhaskar > > >> > > > >> > > >
