Re: [openstack-dev] [Trove] Replication Contract Verbiage
Daniel Salinas 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev pgpSmTHKNCxrc.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Replication Contract Verbiage
Daniel, Couple questions. So what happens if/when the volume is different on the nodes in the replication cluster? If you need to resize the volume larger to handle more data are you required to resize all the nodes individually? It makes sense that maybe all the instances could have a different flavor if its not the master in the cluster/grouping. So is there a status of the replication set? If its healthy? or is that just managed by the individual instances? Because what would you expect to see if the first instance you create is the master and the second is the slave and for what ever reason the slave never comes online or connects up to the master. Is the writable flag completely optional for creating the metadata on an instance? Would that mean that there is a default per datastore or overall? Thanks for putting all this together. Great work man. - Craig Vyvial On Wed, Feb 5, 2014 at 4:38 PM, Daniel Salinas wrote: > > 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. > > 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. > > 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Trove] Replication Contract Verbiage
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. 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. 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
