Difference between revisions of "Trove-Replication-And-Clustering-API"
Imsplitbit (talk | contribs) |
Imsplitbit (talk | contribs) |
||
Line 22: | Line 22: | ||
POST /instance | POST /instance | ||
+ | <pre> | ||
{ | { | ||
"name": "foobar", | "name": "foobar", | ||
Line 31: | Line 32: | ||
} | } | ||
} | } | ||
− | + | </pre> | |
Delete cluster: | Delete cluster: |
Revision as of 17:40, 7 October 2013
WORK IN PROGRESS
A cluster is an independant service type. - This simplifies the configurations (ties to service_type) - The guest impl can be different for each service_type - We don't need cluster type and service_type when defining a cluster
Think: A instance is an instance is a cluster is an instance is *NOT* replication
CLUSTERING
Definition of cluster for purposes of Trove: A cluster must provide - High Availablility - Fault Tolerance
A cluster object is represented as an instance with a metadata attribute containing node information. A node is a sub-resource of a cluster and has a limited number of actions that can be performed on them.
Create cluster: Create a cluster with flavor X and size Y. All nodes are of equal size.
POST /instance
{ "name": "foobar", "flavor": "{flavor_id}", "service_type": "{service_type_id}", "size": 50, "metadata": { "nodes": 5, } }
Delete cluster: Deletes all nodes in the cluster. DELETE /instance/{id}
Downsize a cluster (Delete nodes): PATCH /instance/{id} { "metadata" { "nodes": 3 } }
Restart a cluster: POST /instance/{id}/restart
Restart a cluster node POST /instance/{id}/node/{id}/restart
Resize a cluster: POST /instance/{id}/resize
Initialize cluster: POST /instance/{id}/initialize
Rebalance/restripe cluster: POST /instance/{id}/rebalance
Node Operations: Restart a node: PATCH /instance/{id}/node/{id}/restart
Initialize a node: This only where applicable... PATCH /instance/{id}/node/{id}/initialize
REPLICATION
We think of replication as a capability of some service types. Not every service type will have this capability and it should be configurable via the service types capabilities feature.
What you cannot do: - create a master and slave in one call - one call per action means simplified workflow
Replication workflow:
1. Create an instance
2. Create an Nth instance with
- metadata {"master_instance": "id from 1", "replication_type": "typeid from replication_types api"}
- Caveat: adding a replicated slave will alter data on the master instance and will use the agent
to create the replication.
Create Replication:
POST /instance { "name": "foobar", "flavor": "flavor_id", "service_type": "mysql-5.1", "size": 50, "metadata": { "replication_type": "replication_type_id", "replication_data": { "master_instance": "instance_uuid" } } }