[openstack-dev] [Trove] Replication and Clustering API

Daniel Salinas imsplitbit at gmail.com
Wed Oct 23 14:42:37 UTC 2013


Galera cluster, in this model would be considered a service type or
datastore type not a replication type.  All clusters would be treated this
way.  The method of replication is really not important to the api IMO but
rather the contract should reflect what host has copies of data (in whole
or in part) on other hosts.  How the data gets to each host is a function
of the underlying technology.  That is not to say that we couldn't add more
verbose information to the replication contract but I haven't yet seen
where or how that's important to the end user.


On Tue, Oct 22, 2013 at 5:32 PM, Georgy Okrokvertskhov <
gokrokvertskhov at mirantis.com> wrote:

> Hi,
>
> I don't see the replication type in the metadata replication contract. For
> example someone can use MySQL Galera cluster with synchronous replication +
> asynchronous replication master-slave for backup to remote site.
>
> MS SQL offers alwaysON availability groups clustering with pair of
> synchronous replication plus up to 3 nodes with asynchronous replication.
> Also there are some existing different mechanisms like data mirroring
> (synchronous or asynchronous) or log shipping.
>
> So my point is that when you say replication, it is not obvious which type
> of replication is used.
>
> Thanks
> Georgy
>
>
>
>
> On Tue, Oct 22, 2013 at 12:37 PM, Daniel Salinas <imsplitbit at gmail.com>wrote:
>
>> We have drawn up a new spec for the clustering api which removes the
>> concept of a /clusters path as well as the need for the /clustertypes
>> path.  The spec lives here now:
>>
>> https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API
>>
>> Initially I'd like to get eyes on this and see if we can't generate some
>> discussion.  This proposal is far reaching and will ultimately require a
>> major versioning of the trove API to support.  It is an amalgam of ideas
>> from Vipul, hub_cap and a few others but we feel like this gets us much
>> closer to having a more intuitive interface for users.  Please peruse the
>> document and lets start working through any issues.
>>
>> I would like to discuss the API proposal tomorrow during our weekly
>> meeting but I would welcome comments/concerns on the mailing list as well.
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Georgy Okrokvertskhov
> Technical Program Manager,
> Cloud and Infrastructure Services,
> Mirantis
> http://www.mirantis.com
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131023/2ea59687/attachment.html>


More information about the OpenStack-dev mailing list