You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Ravi Solr <ra...@gmail.com> on 2015/10/01 23:09:18 UTC
Solr 4.7.2 Vs 5.3.0 Docs different for same query
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
Re: Solr 4.7.2 Vs 5.3.0 Docs different for same query
Posted by Upayavira <uv...@odoko.co.uk>.
The new collections UI isn't yet committed. It is close, and i would
like to have it in 5.4.
Upayavira
On Fri, Oct 2, 2015, at 09:35 PM, Ravi Solr wrote:
> 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.1111@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 <er...@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 <ra...@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.1111@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 <ra...@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
> > > >> >
> > > >>
> > >
> >
Re: Solr 4.7.2 Vs 5.3.0 Docs different for same query
Posted by Ravi Solr <ra...@gmail.com>.
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.1111@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 <er...@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 <ra...@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.1111@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 <ra...@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
> > >> >
> > >>
> >
>
Re: Solr 4.7.2 Vs 5.3.0 Docs different for same query
Posted by Tomoko Uchida <to...@gmail.com>.
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 <er...@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 <ra...@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.1111@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 <ra...@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
> >> >
> >>
>
Re: Solr 4.7.2 Vs 5.3.0 Docs different for same query
Posted by Erick Erickson <er...@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 <ra...@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.1111@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 <ra...@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
>> >
>>
Re: Solr 4.7.2 Vs 5.3.0 Docs different for same query
Posted by Ravi Solr <ra...@gmail.com>.
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.1111@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 <ra...@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
> >
>
Re: Solr 4.7.2 Vs 5.3.0 Docs different for same query
Posted by Tomoko Uchida <to...@gmail.com>.
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 <ra...@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
>