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 <g...@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.bo...@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-requ...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev