Difference between revisions of "Trove/volume-data-snapshot-design"
< Trove
(→Benefits) |
(→Description) |
||
| Line 3: | Line 3: | ||
=== Description === | === Description === | ||
:This feature is being proposed as the addition backup/restore strategy | :This feature is being proposed as the addition backup/restore strategy | ||
| + | [[User:Slicknik|slicknik]] ([[User talk:Slicknik|talk]]) Can you please clarify this? You mention that it will be an "addition", but nowhere do you mention how a user will be able to specify through the API how to actually take a database backup through a volume snapshot. Or is it meant as an "alternative" rather than an "addition"? | ||
==== Volumes Snapshots ==== | ==== Volumes Snapshots ==== | ||
:This introduction provides a high level overview of the two basic resources offered by the OpenStack Block Storage service. The first is Volumes and the second is Snapshots which are derived from Volumes. | :This introduction provides a high level overview of the two basic resources offered by the OpenStack Block Storage service. The first is Volumes and the second is Snapshots which are derived from Volumes. | ||
| − | + | [[User:Slicknik|slicknik]] ([[User talk:Slicknik|talk]]) The BP / spec is supposed to contain relevant information about requirements for the spec, and what changes are proposed to meet the requirements. If you feel that the intended audience might need more background about Volumes, or Snapshots you can link to the Cinder wiki / docs (eg. https://wiki.openstack.org/wiki/Cinder), rather than try and cover all background details in the spec, since it distracts from the purpose of the spec. | |
| + | |||
==== Volumes ==== | ==== Volumes ==== | ||
:Volumes are allocated block storage resources that can be attached to instances as secondary storage or they can be used as the root store to boot instances. Volumes are persistent R/W Block Storage devices most commonly attached to the Compute node via iSCSI. | :Volumes are allocated block storage resources that can be attached to instances as secondary storage or they can be used as the root store to boot instances. Volumes are persistent R/W Block Storage devices most commonly attached to the Compute node via iSCSI. | ||
| + | [[User:Slicknik|slicknik]] ([[User talk:Slicknik|talk]]) See note above | ||
==== Snapshots ==== | ==== Snapshots ==== | ||
:A Snapshot in OpenStack Block Storage is a read-only point in time copy of a Volume. The Snapshot can be created from a Volume that is currently in use (via the use of '--force True') or in an available state. The Snapshot can then be used to create a new volume via create from snapshot. | :A Snapshot in OpenStack Block Storage is a read-only point in time copy of a Volume. The Snapshot can be created from a Volume that is currently in use (via the use of '--force True') or in an available state. The Snapshot can then be used to create a new volume via create from snapshot. | ||
| + | [[User:Slicknik|slicknik]] ([[User talk:Slicknik|talk]]) See note above | ||
| + | |||
------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ||
Revision as of 00:52, 21 July 2014
Contents
Data volume snapshot
Description
- This feature is being proposed as the addition backup/restore strategy
slicknik (talk) Can you please clarify this? You mention that it will be an "addition", but nowhere do you mention how a user will be able to specify through the API how to actually take a database backup through a volume snapshot. Or is it meant as an "alternative" rather than an "addition"?
Volumes Snapshots
- This introduction provides a high level overview of the two basic resources offered by the OpenStack Block Storage service. The first is Volumes and the second is Snapshots which are derived from Volumes.
slicknik (talk) The BP / spec is supposed to contain relevant information about requirements for the spec, and what changes are proposed to meet the requirements. If you feel that the intended audience might need more background about Volumes, or Snapshots you can link to the Cinder wiki / docs (eg. https://wiki.openstack.org/wiki/Cinder), rather than try and cover all background details in the spec, since it distracts from the purpose of the spec.
Volumes
- Volumes are allocated block storage resources that can be attached to instances as secondary storage or they can be used as the root store to boot instances. Volumes are persistent R/W Block Storage devices most commonly attached to the Compute node via iSCSI.
slicknik (talk) See note above
Snapshots
- A Snapshot in OpenStack Block Storage is a read-only point in time copy of a Volume. The Snapshot can be created from a Volume that is currently in use (via the use of '--force True') or in an available state. The Snapshot can then be used to create a new volume via create from snapshot.
slicknik (talk) See note above
Backup workflow
- The actual flow will be:
- ask if instance if it has the volume
- prepare database for storage snapshot
- snapshot
- return database in to the normal state
Restore workflow
- create a new volume from the given snapshot
- swap the volume
- update backend record
- delete initial volume
Recovery process
- So, lets say, cinder failed to create the snapshot, for the Trove it's like - no problem, lets mark it as FAILED and thats all.
Justification/Benefits
Justification
- Data could be backued in two ways:
- Standart backup strategies (innobackupex, nodetoolsnapshot) + Swift container (already implemented).
- Snapshot of the attached block storage (not implemented).
- Basically, its the another way of backupin' data through standard OpenStack capabilities.
Benefits
- Generic way to backup the data. This feature is not the datastore-type/version specific. Makes Swift storage optional.
Impacts
Changes the behavior to the backups made by Trove, it impacts at already implemented backuping process through native database tools (mysqldump, nodetool, etc.) and the Swift as storage container service. Changes are backward compatible.
Configuration
- Configuration parameters are guest specific.
| Name | Type | Default | Available variants |
|---|---|---|---|
| backup_agent | String | trove.guestagent.backup.backupagent.SwiftAgent | trove.guestagent.backup.backupagent.CinderAgent |
| storage_strategy | String | Swift | Cinder |
Database
No changes
Public API
No changes
Internal API
From trove-api to trove-taskamanger
No changes
From trove-taskamanger to trove-guestagent
No changes
Guest Agent
Changes are backward compatible. Changes will be available for all datastores. This method of the backuping is generic for the all datastores types/versions.
