Open Stack

On 5 February 2015 at 10:24, Joshua Harlow <harlowja at outlook.com> wrote:
> How interesting,
>
> Why are people using galera if it behaves like this? :-/

Because its actually fairly normal. In fact its an instance of point 7
on https://wiki.openstack.org/wiki/BasicDesignTenets - one of our
oldest wiki pages :).

In more detail, consider what happens in full isolation when you have
the A and B example given, but B starts its transaction before A.

B BEGIN
A BEGIN
A INSERT foo
A COMMIT
B SELECT foo -> NULL

- data inserted by a transaction with a higher transaction id isn't
visible to the older transaction (in a MVCC style engine - there are
other engines, but this is common).

When you add clustering in, many cluster DBs are not synchronous: -
postgresql replication is asynchronous - both log shipping and slony.
Neither is Galera. So reads will see older data than has been
committed to the cluster. Writes will conflict *if* the write was
dependent on data that was changed.

If rather than clustering you add multiple DB's, you get the same sort
of thing unless you explicitly wire in 2PC and a distributed lock
manager and oh my... and we have multiple DB's (cinder, nova etc) but
no such coordination between them.

Now, if we say that we can't accept eventual consistency, that we have
to have atomic visibility of changes, then we've a -lot- of work-
because of the multiple DB's thing.

However, eventual consistency can cause confusion if its not applied
well, and it may be that this layer is the wrong layer to apply it at
- thats certainly a possibility.

> Are the people that are using it know/aware that this happens? :-/

I hope so :)

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud