Yokozuna unpredictable result count

Zeeshan Lakhani zlakhani at basho.com
Thu Feb 19 13:42:33 EST 2015


Ok. I’m guessing that you’re running a default cluster on one node. 

Did you attempt the read-repair I suggested earlier in the thread?

Also, you should try and get each node’s value for the bucket/key and see if they’re consistent. You can use https://github.com/basho/riak_kv/blob/d17409fdb934c076cca9e65a02818ad860fe310b/src/riak_kv_vnode.erl#L248 <https://github.com/basho/riak_kv/blob/d17409fdb934c076cca9e65a02818ad860fe310b/src/riak_kv_vnode.erl#L248> via `riak attach` on each vnode to check each value. You can get active preflist for that bucket/key to help you get the index via https://github.com/binarytemple/riak_utils/blob/d59bd38e34b697b2b48b853b39ab1a51ab04111a/sparrows.preflist.getter.markdown <https://github.com/binarytemple/riak_utils/blob/d59bd38e34b697b2b48b853b39ab1a51ab04111a/sparrows.preflist.getter.markdown>. That Preflist fun would take in an input like (<<“maps”>>, <<“albums”>>, <<“REM”>>).

Thanks.


> On Feb 19, 2015, at 12:09 PM, Cezary Kosko <koskocezarym at gmail.com> wrote:
> 
> I can't recall right now, but it's safe to assume I did delete it.
> 
> As for nodes, I have added one, nothing more.
> 
> Kind regards,
> Cezary
> 
> 2015-02-19 18:01 GMT+01:00 Zeeshan Lakhani <zlakhani at basho.com <mailto:zlakhani at basho.com>>:
> So, AAE is running.
> 
> Again, did you delete the single object at some point? Trying to see if this is related to you hitting a tombstone on queries. Also, when you added the object, did you add it and later leave (drop) a node from your cluster? 
> 
> Thanks.
> 
> Zeeshan Lakhani
> programmer | 
> software engineer at @basho | 
> org. member/founder of @papers_we_love |
> twitter => @zeeshanlakhani
> 
>> On Feb 19, 2015, at 11:53 AM, Cezary Kosko <koskocezarym at gmail.com <mailto:koskocezarym at gmail.com>> wrote:
>> 
>> By './data/yz_anti_entropy' do you mean '/var/lib/riak/yz_anti_entropy' by default or './data/yz_anti_entropy' inside each index's directory? If the former - it's there, the latter - not. riak-admin search aae-status says there's been some AAE activity in the past few hours.
>> 
>> Also I called yz_entropy_mgr:init([]) inside an attached erlang shell and curl-ed the object, it's still the same.
>> 
>> Kind regards,
>> Cezary
>> 
>> 2015-02-19 17:27 GMT+01:00 Zeeshan Lakhani <zlakhani at basho.com <mailto:zlakhani at basho.com>>:
>> Thanks Cezary. 
>> 
>> Have you deleted this object at some point in your runs? Please make sure AAE is running by checking search’s AAE status, `riak-admin search aae-status`, and that data exists in the correct directory, `./data/yz_anti_entropy` (http://docs.basho.com/riak/latest/ops/advanced/configs/search/ <http://docs.basho.com/riak/latest/ops/advanced/configs/search/>). You may just need to perform a read-repair by performing a fetch of the object itself first, before performing search queries again.
>> 
>> Zeeshan Lakhani
>> programmer | 
>> software engineer at @basho | 
>> org. member/founder of @papers_we_love |
>> twitter => @zeeshanlakhani
>> 
>>> On Feb 19, 2015, at 10:35 AM, Cezary Kosko <koskocezarym at gmail.com <mailto:koskocezarym at gmail.com>> wrote:
>>> 
>>> I have the exact same issue with regular http search queries, so I guess I'll just describe that part.
>>> 
>>> I've got a bucket of maps-of-sets, 2 of them are entityId_set and timestamps_set. Its search index is called 'job' and it's only this bucket that's indexed.
>>> 
>>> When I run
>>> curl "localhost:8098/search/query/job?wt=json&q=entityId_set:100000000000000000%20AND%20timestamps_set:%5B1419721530%20TO%201419721539%5D"
>>> 
>>> (that's a query that is supposed to return exactly one result), the numFound field is either 0 or 1, it seems that I get both kinds of result in 10 consecutive requests (and the timeAllowed parameter I wrote about, it doesn't really help).
>>> 
>>> That's the way they're handled in the schema:
>>> 
>>>    <field name="entityId_set"      type="string"  indexed="true" stored="false" multiValued="true" />
>>>    <field name="timestamps_set"      type="string"  indexed="true" stored="false" multiValued="true" />
>>> 
>>> 
>>> Kind regards,
>>> Cezary
>>> 
>>> 2015-02-19 16:04 GMT+01:00 Zeeshan Lakhani <zlakhani at basho.com <mailto:zlakhani at basho.com>>:
>>> Hello Cezary,
>>> 
>>> Firstly, are you able to retrieve your search result consistently when not using doing a mapreduce job? 
>>> 
>>> To better help out, can you send a gist of the mapreduce code you’re running? Thanks.
>>> 
>>> 
>>>> On Feb 18, 2015, at 9:13 PM, Cezary Kosko <koskocezarym at gmail.com <mailto:koskocezarym at gmail.com>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I've got a search index, and I'd like to run mapred job against that index. The thing is, for a search query that should return exactly one result, I sometimes (not always, yet not rarely) get none, i.e. the mapred job returns an empty list instead of, say, a list containing a single object. Did this only happen some time after uploading the data and then was consistently giving the right results, I wouldn't object. However, it's kind of an on-and-off situation - I get proper results, but then for a brief period of time I don't and so on.
>>>> 
>>>> I've read on a solr doc page that specifying a timeAllowed parameter in the query can give it longer to gather results and help, but that can't be specified in a mapred definition, or can it?
>>>> 
>>>> Is there anything else I can look for?
>>>> 
>>>> The data I'm querying is of the CRDT map-of-sets type, should that be of any relevance.
>>>> 
>>>> Kind regards,
>>>> Cezary
>>>> _______________________________________________
>>>> riak-users mailing list
>>>> riak-users at lists.basho.com <mailto:riak-users at lists.basho.com>
>>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com <http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com>
>>> 
>>> 
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20150219/4e6aef3b/attachment-0002.html>


More information about the riak-users mailing list