stale view data?

[ooi]

We've used bigcouch successfully with N=R=W=1 but as soon as we try to implement N=3, our views tend to return stale data.  We don't explicitly create or query our views options for stale or update_after results.  Is there a default we haven't found?  According to the github bug reports, changing W=3 should fix the issue but it does not -- we can still write 3 copies of the data and get back stale view results.  

9 nodes, N=W=3, tried R=1 and R=3, centos 6, BC1.1.1

Suggestions?

[Paul Davis]

Can you provide a bit more detail on what you mean by implementing
N=3? Also, how stale is stale in your case? Are you doing things like
write/view-query in a quick loop? Theoretically if you have an N=3 db
and use W=3 everywhere then you shouldn't be seeing stale view results
though it is possible in some circumstances when nodes are
misbehaving.

> --
> You received this message because you are subscribed to the Google Groups
> "BigCouch Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bigcouch-use...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[ooi]

"what you mean by implementing N=3" 

 

By this I mean I am changing our bigcouch setup from a simple demo installation on one node to a 9 node cluster with N=3 copies of the data and a hardware load balancer.

"how stale is stale in your case? Are you doing things like write/view-query in a quick loop?"  

Although not a loop, we are writing an item then immediately fetching it from a view.

"you shouldn't be seeing stale view results though it is possible in some circumstances"

Could you be more specific about which circumstances?  Can I do anything to fix it?

Is this really "misbehaving" or is there an expected lag between the write completing (even with W=3) and the _changes feed being absorbed into the views?  

That is, will the view update be part of the write operation or an async operation that follows?

[John Nowlin]

We are experiencing views not returning recently written data on our cluster ( n=3, q=3, r=2, w=2 ). It does take a bit of a load, but is easily replicable.

You suggest that this is possible "in some circumstances".  Can you please elaborate on these circumstances and how this can be avoided?

john