On 5 February 2015 at 10:24, Joshua Harlow <harlo...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ 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
