On Fri Feb 06 2015 at 12:59:13 PM Gregory Haynes <g...@greghaynes.net> wrote:
> Excerpts from Joshua Harlow's message of 2015-02-06 01:26:25 +0000: > > Angus Lees wrote: > > > On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum <cl...@fewbar.com > > > <mailto:cl...@fewbar.com>> wrote: > > > I'd also like to see consideration given to systems that handle > > > distributed consistency in a more active manner. etcd and > Zookeeper are > > > both such systems, and might serve as efficient guards for critical > > > sections without raising latency. > > > > > > > > > +1 for moving to such systems. Then we can have a repeat of the above > > > conversation without the added complications of SQL semantics ;) > > > > > > > So just an fyi: > > > > http://docs.openstack.org/developer/tooz/ exists. > > > > Specifically: > > > > http://docs.openstack.org/developer/tooz/developers. > html#tooz.coordination.CoordinationDriver.get_lock > > > > It has a locking api that it provides (that plugs into the various > > backends); there is also a WIP https://review.openstack.org/#/c/151463/ > > driver that is being worked for etc.d. > > > > An interesting note about the etcd implementation is that you can > select per-request whether you want to wait for quorum on a read or not. > This means that in theory you could obtain higher throughput for most > operations which do not require this and then only gain quorum for > operations which require it (e.g. locks). > 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. - Gus (*) In case you're also curious, the only doc I found with any details was http://galeracluster.com/documentation-webpages/certificationbasedreplication.html and its sibling pages.
__________________________________________________________________________ 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