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 > >> > > >> >
