Thanks for the additional details Peter.  This confirms the parts I'd deduced from the docs I could find, and is useful knowledge.<br><br><div class="gmail_quote">On Sat Feb 07 2015 at 2:24:23 AM Peter Boros <<a href="mailto:peter.boros@percona.com">peter.boros@percona.com</a>> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Like many others said it before me, consistent reads can be achieved<br>
with wsrep_causal_reads set on in the session.</blockquote><div><br></div><div>So the example was two dependent command-line invocations (write followed by read) that have no way to re-use the same DB session (without introducing lots of affinity issues that we'd also like to avoid).</div><div><br></div><div>Enabling wsrep_casual_reads makes sure the latter read sees the effects of the earlier write, but comes at the cost of delaying all reads by some amount depending on the write-load of the galera cluster (if I understand correctly).  This additional delay was raised as a concern severe enough not to just go down this path.</div><div><br></div><div>Really we don't care about other writes that may have occurred (we always need to deal with races against other actors), we just want to ensure our earlier write has taken effect on the galera server where we sent the second read request.  If we had some way to say "wsrep_delay_until $first_txid" then we we could be sure of read-after-write from a different DB session and also (in the vast majority of cases) suffer no additional delay.  An opaque sequencer is a generic concept across many of the distributed consensus stores I'm familiar with, so this needn't be exposed as a Galera-only quirk.</div><div><br></div><div><br></div><div>Meh, I gather people are bored with the topic at this point.  As I suggested much earlier, I'd just enable wsrep_casual_reads on the first request for the session and then move on to some other problem ;)</div><div><br></div><div> - Gus</div></div>