Open Stack

On 2015-02-05 9:36 PM, Angus Lees wrote:
> On Fri Feb 06 2015 at 12:59:13 PM Gregory Haynes <greg at greghaynes.net
> <mailto:greg at greghaynes.net>> wrote:
>
> Along those lines and in an effort to be a bit less doom-and-gloom, I
> spent my lunch break trying to find non-marketing documentation on the
> Galera replication protocol and how it is exposed. (It was surprisingly
> difficult to find such information *)
>
> It's easy to get the transaction ID of the last commit
> (wsrep_last_committed), but I can't find a way to wait until at least a
> particular transaction ID has been synced.  If we can find that latter
> functionality, then we can expose that sequencer all the way through
> (HTTP header?) and then any follow-on commands can mention the sequencer
> of the previous write command that they really need to see the effects of.
>
> In practice, this should lead to zero additional wait time, since the
> Galera replication has almost certainly already caught up by the time
> the second command comes in - and we can just read from the local server
> with no additional delay.
>
> See the various *Index variables in the etcd API, for how the same idea
> gets used there.
>

I don't use Galera but managed to understand that you don't need all 
this complex system, it's already built-in within Galera. Matthew Booth 
already mentioned it in his first post.

The wsrep_sync_wait [1][2][3] variable can be scoped to the session and 
force a synchronous/committed read if you *really* need it but will 
result in larger read latencies.

[1] 
http://galeracluster.com/documentation-webpages/mysqlwsrepoptions.html#wsrep-sync-wait
[2] 
http://www.percona.com/doc/percona-xtradb-cluster/5.5/wsrep-system-index.html#wsrep_sync_wait
[3] 
https://mariadb.com/kb/en/mariadb/galera-cluster-system-variables/#wsrep_sync_wait

-- 
Mathieu