On Sep 26, 2013, at 6:07 AM, Ilya Sviridov wrote: > The blueprint https://blueprints.launchpad.net/trove/+spec/mysql-ha > > In order to become production ready DBaaS, Trove should provide ability to > deploy and manage high available database. > > There are several approaches to achive HA in MySQL: driven by high > availability resource managers like Peacemaker [1] ,master-master > replication, Percona XTraDB Cluster [2] based on Galera library [3] so on. > > But, as far as Trove DB instances are running in cloud environment, general > approach can be not always the best suitable option and should be discussed > > -- > [1] http://clusterlabs.org/ > [2] http://www.percona.com/software/percona-xtradb-cluster > [3] https://launchpad.net/galera
This, to me, is a perfect fit for our (work in progress) clustering API. The Codership (galera) team and the Continuent (tungsten) team have both expressed interest in helping to guide the Trove team toward building an awesome clustering product. I think till be up to the people who want to contribute to define what MySQL clustering impl will be the best in Trove. Each of the clustering products has pros/cons, so its hard to say Trove will support only X for clustering. Im personally a fan of both of the aforementioned clustering product because they are different. Galera is synchronous multi master, and tungsten is async master/slave. Our first implementation is, of course, basic master/slave builtin replication, and it too solves a problem. So to answer your question, i think we can build a MySQL cluster using different technologies and let operators choose what they want to support. And better yet, if operators choose to support > 1 cluster type, we can let customers choose what they feel is the right choice for their data.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
