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. __________________________________________________________________________ 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