Open Stack

Excerpts from Matthew Booth's message of 2015-02-04 08:30:32 -0800:
> * Write followed by read on a different node can return stale data
> 
> During a commit, Galera replicates a transaction out to all other db
> nodes. Due to its design, Galera knows these transactions will be
> successfully committed to the remote node eventually[2], but it doesn't
> commit them straight away. The remote node will check these outstanding
> replication transactions for write conflicts on commit, but not for
> read. This means that you can do:
> 
> A: start transaction;
> A: insert into foo values(1)
> A: commit;
> B: select * from foo; <-- May not contain the value we inserted above[3]
> 
> This means that even for 'synchronous' slaves, if a client makes an RPC
> call which writes a row to write master A, then another RPC call which
> expects to read that row from synchronous slave node B, there's no
> default guarantee that it'll be there.
> 
> Galera exposes a session variable which will fix this: wsrep_sync_wait
> (or wsrep_causal_reads on older mysql). However, this isn't the default.
> It presumably has a performance cost, but I don't know what it is, or
> how it scales with various workloads.
> 

wsrep_sync_wait/wsrep_casual_reads doesn't actually hit the cluster
any harder, it simply tells the local Galera node "if you're not caught
up with the highest known sync point, don't answer queries yet". So it
will slow down that particular query as it waits for an update from the
leader about sync point and, if necessary, waits for the local engine
to catch up to that point. However, it isn't going to push that query
off to all the other boxes or anything like that.