By default, w=2, so only two of the default three nodes need to be successfully written for a write to be a success. That final write could potentially take some time to replicate, especially if you're loading a lot of data at once. You could try setting 3=w on initial bulk upload to ensure values are in sync.
The other thing to note, is to be sure you aren't connecting to a solr shard directly. You have to connect through riak search so that yokozuna can properly distribute the query. Because even with an incomplete replication, you shouldn't get an unbalanced numFound. Eric On Jan 17, 2014, at 8:18 AM, Jonathan Gividen <jgivi...@facilityone.com> wrote: > I'm running into a yokozuna/solr issue I'm hoping someone can help me with. > I'm have a 5 node dev cluster and I'm inserting ~200000 documents. When I > run searches on the data different numFounds are returned each time even > though the query is the same. I started looking at each shard individually > and noticed that some documents (~2000 of them) were only indexed on 2 out of > the 5 nodes so I issued a post to re-index each of these and the numFound > values thereafter were correct/consistent. My question is why would/how > could the index only end up on 2 (instead of 3) shards and the system get > into this state? > > Thank you, > > Jonathan > _______________________________________________ > 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
