Ryan, Apologies on the long post delay. We pushed from pre11 to pre20, and figured out the issue. It looks like we had a mismatch between the n-val on the bucket, vs the n-val on the seach_index... Pre20 throws an error telling us to stop being stupid.
It does however allow us to change the n-val after linking the index to the bucket, so I would wager a guess that this might induce the same issue we saw before. We will test a bit to confirm when we get the chance, but I welcome sage advice as to the logic behind this. J On Wed, Jan 22, 2014 at 12:10 AM, Ryan Zezeski <rzeze...@basho.com> wrote: > John, > > 1. What did you use to load the data? Do you have a script? > > 2. What content-type is the data? > > 3. Do you see any errors in the log directory? Check error.log and solr.log. > > 4. Do you get any results for the query q=_yz_err:1 > > > 6. What version of Riak are you using? > > > -Z > > > On Tue, Jan 21, 2014 at 1:46 PM, John O'Brien <j...@boardom.ca> wrote: >> >> Issue: >> >> When running searchs against a single dev node cluster, pre-populated >> with 1000 keys, bitcask backend, search=on and a /search/svan?q=* >> search URI, the solr response is coming back with three different >> resultsets, 330 values, the other 354, the other 345. The range of >> keys 0-1000 are split in no obvious pattern between the 3 result >> shards.. >> >> Anyone have any clue as to what I may have messed up in the config? I >> assume this is not expected behaviour. >> >> Other than that, it works great. ;) >> >> Cheers, >> >> John >> >> _______________________________________________ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
