Open Stack

Hi Angus,

If causal reads is set in a session, it won't delay all reads, just
that specific read that you set if for. Let's say you have 4 sessions,
in one of them you set causal reads, the other 3 won't wait on
anything. The read in the one session that you set this in will be
delayed, in the other 4, it won't be. Also this delay is usually
small. Since the replication itself is synchronous if a node it not
able to keep up with the rest of the cluster in terms of writes, it
will send flow control messages to the other nodes. Flow control means
that it has it's receive queue full, and the other nodes have to wait
until they can do more writes (in case of flow control writes on the
other nodes are blocked until the given node catches up with writes).
So the delay imposed here can't be arbitrarily large.


On Sat, Feb 7, 2015 at 3:00 AM, Angus Lees <gus at inodes.org> wrote:
> Thanks for the additional details Peter.  This confirms the parts I'd
> deduced from the docs I could find, and is useful knowledge.
>
> On Sat Feb 07 2015 at 2:24:23 AM Peter Boros <peter.boros at percona.com>
> wrote:
>>
>> - Like many others said it before me, consistent reads can be achieved
>> with wsrep_causal_reads set on in the session.
>
>
> 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).
>
> 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.
>
> 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.
>
>
> 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 ;)
>
>  - Gus
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Peter Boros, Principal Architect, Percona
Telephone: +1 888 401 3401 ext 546
Emergency: +1 888 401 3401 ext 911
Skype: percona.pboros