Difference between revisions of "Trove/Blueprints/Trove-v1-MySQL-Replication"
Doug Shelley (talk | contribs) (→Description) |
Doug Shelley (talk | contribs) (→Justification/Benefits) |
||
| Line 3: | Line 3: | ||
== Justification/Benefits == | == Justification/Benefits == | ||
| − | * | + | Most of the datastores currently supported by Trove have replication capabilities to fulfill various use cases such as: |
| − | + | * scale out via read replicas | |
| + | * operational recovery (aka failover) | ||
| + | * offline backup | ||
| + | |||
| + | In order to be production ready, Trove needs to support easy configuration and management of these use cases. Today Amazon RDS fulfills the first use cases and part of the second use case for MySQL. | ||
| + | |||
| + | Over time all of these requirements should be evaluated; the goal of this blueprint is to focus on read replicas for scale out and target the MySQL datastore. It is expected that implementation of this scoping will occur for other datastores and then further work can be scoped out to meet the remaining requirements. | ||
== Impacts == | == Impacts == | ||
Revision as of 22:14, 4 March 2014
Contents
Description
Providing support for the various replication use cases is critical for use of Trove in production. This will describe the various use cases and related requirements and then propose a scoping for an initial V1 implementation for MySQL.
Justification/Benefits
Most of the datastores currently supported by Trove have replication capabilities to fulfill various use cases such as:
- scale out via read replicas
- operational recovery (aka failover)
- offline backup
In order to be production ready, Trove needs to support easy configuration and management of these use cases. Today Amazon RDS fulfills the first use cases and part of the second use case for MySQL.
Over time all of these requirements should be evaluated; the goal of this blueprint is to focus on read replicas for scale out and target the MySQL datastore. It is expected that implementation of this scoping will occur for other datastores and then further work can be scoped out to meet the remaining requirements.
Impacts
Configuration
- Does this impact any configuration files? If so, which ones?
Database
- Does this impact any existing tables? If so, which ones?
- Are the changes forward and backward compatible?
- Be sure to include the expected migration process
Public API
- Does this change any API that an end-user has access to?
- Are there any exceptions in terms of consistency with other APIs?
Internal API
- Does this change any internal messages between API and Task Manager or Task Manager to Guest
Guest Agent
- Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?
