[openstack-dev] [Trove] Replication Contract Verbiage

Michael Basnight mbasnight at gmail.com
Tue Feb 11 21:30:56 UTC 2014


Daniel Salinas <imsplitbit at gmail.com> writes:

> https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API#REPLICATION
>
> I have updated the wiki page to reflect the current proposal for
> replication verbiage with some explanation of the choices.  I would like to
> open discussion here regarding that verbiage.  Without completely
> duplicating everything I just wrote in the wiki here are the proposed words
> that could be used to describe replication between two datastore instances
> of the same type.  Please take a moment to consider them and let me know
> what you think.  I welcome all feedback.
>
> replicates_from:  This term will be used in an instance that is a slave of
> another instance. It is a clear indicator that it is a slave of another
> instance.
>
> replicates_to: This term will be used in an instance that has slaves of
> itself. It is a clear indicator that it is a master of one or more
> instances.

Nice work daniel. I think these are quite sane. They are pretty agnostic
to the datastore type. The only thing i remember Stewart Smith saying
was that these may not _both_ _always_ apply to all datastores. So
assuming we have a builtin way to say that a given datastore/replication
type may not support both of these (or may not have a need to expose it
like this).

> writable: This term will be used in an instance to indicate whether it is
> intended to be used for writes. As replication is used commonly to scale
> read operations it is very common to have a read-only slave in many
> datastore types. It is beneficial to the user to be able to see this
> information when viewing the instance details via the api.

Sounds reasonable. But how do we view a multi-tier slave? aka, a slave
to a slave. Is it both read only and writale, so to speak, depending on
where you are in the cluster hierarchy?

> The intention here is to:
> 1.  have a clearly defined replication contract between instances.
> 2.  allow users to create a topology map simply by querying the api for
> details of instances linked in the replication contracts
> 3.  allow the greatest level of flexibility for users when replicating
> their data so that Trove doesn't prescribe how they should make use of
> replication.
>
> I also think there is value in documenting common replication topologies
> per datastore type with example replication contracts and/or steps to
> recreate them in our api documentation.  There are currently no examples of
> this yet

++

> e.g. To create multi-master replication in mysql...
>
> As previously stated I welcome all feedback and would love input.
>
> Regards,
>
> Daniel Salinas
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 512 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140211/359ef4c8/attachment.pgp>


More information about the OpenStack-dev mailing list