%openstack; ]>

The Database service provides scalable and reliable cloud provisioning functionality for both relational and non-relational database engines. Users can quickly and easily use database features without the burden of handling complex administrative tasks.

Assume that you have installed the Database service and populated your data store with images for the type and versions of databases that you want, and that you can create and access a database. This example shows you how to create and access a MySQL 5.5 database. When you create a database instance, you must specify a nova flavor. The flavor indicates various characteristics of the instance, such as RAM, root volume size, and so on. The default nova flavors are not sufficient to create database instances. You might need to create or obtain some new nova flavors that work for databases. The first step is to list flavors by using the nova flavor-list command. Here are the default flavors, although you may have additional custom flavors in your environment: $ nova flavor-list +-----+-----------+-----------+------+-----------+------+-------+-------------+-----------+ | ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | +-----+-----------+-----------+------+-----------+------+-------+-------------+-----------+ | 1 | m1.tiny | 512 | 1 | 0 | | 1 | 1.0 | True | | 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True | | 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True | | 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True | | 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True | +-----+-----------+-----------+------+-----------+------+-------+-------------+-----------+ Now take a look at the minimum requirements for various database instances: Database RAM (MB) Disk (GB) VCPUs MySQL 512 5 1 Cassandra 2048 5 1 MongoDB 1024 5 1 Redis 512 5 1 If you have a custom flavor that meets the needs of the database that you want to create, proceed to and use that flavor. If your environment does not have a suitable flavor, an administrative user must create a custom flavor by using the nova flavor-create command. This example creates a flavor that you can use with a MySQL database. This example has the following attributes: Flavor name: mysql_minimum Flavor ID: You must use an ID that is not already in use. In this example, IDs 1 through 5 are in use, so use ID 6. RAM: 512 Root volume size in GB: 5 Virtual CPUs: 1 $ nova flavor-create mysql-minimum 6 512 5 1 +----+---------------+-----------+------+-----------+------+-------+-------------+-----------+ | ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | +----+---------------+-----------+------+-----------+------+-------+-------------+-----------+ | 6 | mysql-minimum | 512 | 5 | 0 | | 1 | 1.0 | True | +----+---------------+-----------+------+-----------+------+-------+-------------+-----------+ This example creates a database instance with the following characteristics: Name of the instance: mysql_instance_1 Database flavor: 6 In addition, this command specifies these options for the instance: A volume size of 5 (5 GB). The myDB database. The database is based on the mysql data store and the mysql-5.5 datastore_version. The userA user with the password password. $ trove create mysql_instance_1 6 --size 5 --databases myDB \ --users userA:password --datastore_version mysql-5.5 \ --datastore mysql +-------------------+---------------------------------------------------------------------------------------t------------------------------------------------------------------------------------------------------------------+ | Property | Value | +-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | created | 2014-05-29T21:26:21 | | datastore | {u'version': u'mysql-5.5', u'type': u'mysql'} | | datastore_version | mysql-5.5 | | flavor | {u'id': u'6', u'links': [{u'href': u'https://controller:8779/v1.0/46d0bc4fc32e4b9e8520f8fc62199f58/flavors/6', u'rel': u'self'}, {u'href': u'https://controller:8779/flavors/6', u'rel': u'bookmark'}]} | | id | 5599dad6-731e-44df-bb60-488da3da9cfe | | name | mysql_instance_1 | | status | BUILD | | updated | 2014-05-29T21:26:21 | | volume | {u'size': 5} | +-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ First, use the trove list command to list all instances and their IDs: $ trove list +--------------------------------------+------------------+-----------+-------------------+--------+-----------+------+ | id | name | datastore | datastore_version | status | flavor_id | size | +--------------------------------------+------------------+-----------+-------------------+--------+-----------+------+ | 5599dad6-731e-44df-bb60-488da3da9cfe | mysql_instance_1 | mysql | mysql-5.5 | BUILD | 6 | 5 | +--------------------------------------+------------------+-----------+-------------------+--------+-----------+------+ This command returns the instance ID of your new instance. You can now pass in the instance ID with the trove show command to get the IP address of the instance. In this example, replace INSTANCE_ID with 5599dad6-731e-44df-bb60-488da3da9cfe. $ trove show INSTANCE_ID +-------------------+--------------------------------------+ | Property | Value | +-------------------+--------------------------------------+ | created | 2014-05-29T21:26:21 | | datastore | mysql | | datastore_version | mysql-5.5 | | flavor | 6 | | id | 5599dad6-731e-44df-bb60-488da3da9cfe | | ip | 172.16.200.2 | | name | mysql_instance_1 | | status | BUILD | | updated | 2014-05-29T21:26:54 | | volume | 5 | +-------------------+--------------------------------------+ This command returns the IP address of the database instance. You can now access the new database you just created (myDB) by using typical database access commands. In this MySQL example, replace IP_ADDRESS with 172.16.200.2. $ mysql -u userA -ppassword -h IP_ADDRESS myDB

You can use Database services to backup a database and store the backup artifact in the Object Storage module. Later on, if the original database is damaged, you can use the backup artifact to restore the database. The restore process creates a database instance. This example shows you how to back up and restore a MySQL database. As background, assume that you have created a database instance with the following characteristics: Name of the database instance: guest1 Flavor ID: 10 Root volume size: 2 Databases: db1 and db2 Users: The user1 user with the password password First, get the ID of the guest1 database instance by using the trove list command: $ trove list +--------------------------------------+--------+-----------+-------------------+--------+-----------+------+ | id | name | datastore | datastore_version | status | flavor_id | size | +--------------------------------------+--------+-----------+-------------------+--------+-----------+------+ | 97b4b853-80f6-414f-ba6f-c6f455a79ae6 | guest1 | mysql | mysql-5.5 | ACTIVE | 10 | 2 | +--------------------------------------+--------+-----------+-------------------+--------+-----------+------+ Back up the database instance by using the trove backup-create command. In this example, the backup is called backup1. In this example, replace INSTANCE_ID with 97b4b853-80f6-414f-ba6f-c6f455a79ae6: This command syntax pertains only to python-troveclient version 1.0.6 and later. Earlier versions require you to pass in the backup name as the first argument. $ trove backup-create INSTANCE_ID backup1 +-------------+--------------------------------------+ | Property | Value | +-------------+--------------------------------------+ | created | 2014-03-18T17:09:07 | | description | None | | id | 8af30763-61fd-4aab-8fe8-57d528911138 | | instance_id | 97b4b853-80f6-414f-ba6f-c6f455a79ae6 | | locationRef | None | | name | backup1 | | parent_id | None | | size | None | | status | NEW | | updated | 2014-03-18T17:09:07 | +-------------+--------------------------------------+ Note that the command returns both the ID of the original instance (instance_id) and the ID of the backup artifact (id). Later on, use the trove backup-list command to get this information: $ trove backup-list +--------------------------------------+--------------------------------------+---------+-----------+-----------+---------------------+ | id | instance_id | name | status | parent_id | updated | +--------------------------------------+--------------------------------------+---------+-----------+-----------+---------------------+ | 8af30763-61fd-4aab-8fe8-57d528911138 | 97b4b853-80f6-414f-ba6f-c6f455a79ae6 | backup1 | COMPLETED | None | 2014-03-18T17:09:11 | +--------------------------------------+--------------------------------------+---------+-----------+-----------+---------------------+ You can get additional information about the backup by using the trove backup-show command and passing in the BACKUP_ID, which is 8af30763-61fd-4aab-8fe8-57d528911138. $ trove backup-show BACKUP_ID +-------------+-------------------------------------------------------------------------------------------------------------------------------------+ | Property | Value | +-------------+-------------------------------------------------------------------------------------------------------------------------------------+ | created | 2014-03-18T17:09:07 | | description | None | | id | 8af30763-61fd-4aab-8fe8-57d528911138 | | instance_id | 97b4b853-80f6-414f-ba6f-c6f455a79ae6 | | locationRef | http://10.0.0.1:8080/v1/AUTH_626734041baa4254ae316de52a20b390/database_backups/8af30763-61fd-4aab-8fe8-57d528911138.xbstream.gz.enc | | name | backup1 | | parent_id | None | | size | 0.17 | | status | COMPLETED | | updated | 2014-03-18T17:09:11 | +-------------+-------------------------------------------------------------------------------------------------------------------------------------+ Now assume that your guest1 database instance is damaged and you need to restore it. In this example, you use the trove create command to create a new database instance called guest2. You specify that the new guest2 instance has the same flavor (10) and the same root volume size (2) as the original guest1 instance. You use the --backup argument to indicate that this new instance is based on the backup artifact identified by BACKUP_ID. In this example, replace BACKUP_ID with 8af30763-61fd-4aab-8fe8-57d528911138. $ trove create guest2 10 --size 2 --backup BACKUP_ID +-------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Property | Value | +-------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | created | 2014-03-18T17:12:03 | | datastore | {u'version': u'mysql-5.5', u'type': u'mysql'} | | datastore_version | mysql-5.5 | | flavor | {u'id': u'10', u'links': [{u'href': u'https://10.125.1.135:8779/v1.0/626734041baa4254ae316de52a20b390/flavors/10', u'rel': u'self'}, {u'href': u'https://10.125.1.135:8779/flavors/10', u'rel': u'bookmark'}]} | | id | ac7a2b35-a9b4-4ff6-beac-a1bcee86d04b | | name | guest2 | | status | BUILD | | updated | 2014-03-18T17:12:03 | | volume | {u'size': 2} | +-------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Now check that the new guest2 instance has the same characteristics as the original guest1 instance. Start by getting the ID of the new guest2 instance. $ trove list +--------------------------------------+--------+-----------+-------------------+--------+-----------+------+ | id | name | datastore | datastore_version | status | flavor_id | size | +--------------------------------------+--------+-----------+-------------------+--------+-----------+------+ | 97b4b853-80f6-414f-ba6f-c6f455a79ae6 | guest1 | mysql | mysql-5.5 | ACTIVE | 10 | 2 | | ac7a2b35-a9b4-4ff6-beac-a1bcee86d04b | guest2 | mysql | mysql-5.5 | ACTIVE | 10 | 2 | +--------------------------------------+--------+-----------+-------------------+--------+-----------+------+ Use the trove show command to display information about the new guest2 instance. Pass in guest2's INSTANCE_ID, which is ac7a2b35-a9b4-4ff6-beac-a1bcee86d04b. $ trove show INSTANCE_ID +-------------------+--------------------------------------+ | Property | Value | +-------------------+--------------------------------------+ | created | 2014-03-18T17:12:03 | | datastore | mysql | | datastore_version | mysql-5.5 | | flavor | 10 | | id | ac7a2b35-a9b4-4ff6-beac-a1bcee86d04b | | ip | 10.0.0.3 | | name | guest2 | | status | ACTIVE | | updated | 2014-03-18T17:12:06 | | volume | 2 | | volume_used | 0.18 | +-------------------+--------------------------------------+ Note that the data store, flavor ID, and volume size have the same values as in the original guest1 instance. Use the trove database-list command to check that the original databases (db1 and db2) are present on the restored instance. $ trove database-list INSTANCE_ID +--------------------+ | name | +--------------------+ | db1 | | db2 | | performance_schema | | test | +--------------------+ Use the trove user-list command to check that the original user (user1) is present on the restored instance. $ trove user-list INSTANCE_ID +--------+------+-----------+ | name | host | databases | +--------+------+-----------+ | user1 | % | db1, db2 | +--------+------+-----------+ Tell the users who were accessing the now-disabled guest1 database instance that they can now access guest2. Provide them with guest2's name, IP address, and any other information they might need. (You can get this information by using the trove show command.) At this point, you might want to delete the disabled guest1 instance, by using the trove delete command. $ trove delete INSTANCE_ID

Incremental backups let you chain together a series of backups. You start with a regular backup. Then, when you want to create a subsequent incremental backup, you specify the parent backup. Restoring a database instance from an incremental backup is the same as creating a database instance from a regular backup—the Database service handles the complexities of applying the chain of incremental backups. This example shows you how to use incremental backups with a MySQL database. Assume that you have created a regular backup for the following database instance: Instance name: guest1 ID of the instance (INSTANCE_ID): 792a6a56-278f-4a01-9997-d997fa126370 ID of the regular backup artifact (BACKUP_ID): 6dc3a9b7-1f3e-4954-8582-3f2e4942cddd Use the trove backup-create command and specify: The INSTANCE_ID of the database instance you are doing the incremental backup for (in this example, 792a6a56-278f-4a01-9997-d997fa126370) The name of the incremental backup you are creating: backup1.1 The BACKUP_ID of the parent backup. In this case, the parent is the regular backup, with an ID of 6dc3a9b7-1f3e-4954-8582-3f2e4942cddd $ trove backup-create INSTANCE_ID backup1.1 --parent BACKUP_ID +-------------+--------------------------------------+ | Property | Value | +-------------+--------------------------------------+ | created | 2014-03-19T14:09:13 | | description | None | | id | 1d474981-a006-4f62-b25f-43d7b8a7097e | | instance_id | 792a6a56-278f-4a01-9997-d997fa126370 | | locationRef | None | | name | backup1.1 | | parent_id | 6dc3a9b7-1f3e-4954-8582-3f2e4942cddd | | size | None | | status | NEW | | updated | 2014-03-19T14:09:13 | +-------------+--------------------------------------+ Note that this command returns both the ID of the database instance you are incrementally backing up (instance_id) and a new ID for the new incremental backup artifact you just created (id). The name of your second incremental backup is backup1.2. This time, when you specify the parent, pass in the ID of the incremental backup you just created in the previous step (backup1.1). In this example, it is 1d474981-a006-4f62-b25f-43d7b8a7097e. $ trove backup-create INSTANCE_ID backup1.2 --parent BACKUP_ID +-------------+--------------------------------------+ | Property | Value | +-------------+--------------------------------------+ | created | 2014-03-19T14:09:13 | | description | None | | id | bb84a240-668e-49b5-861e-6a98b67e7a1f | | instance_id | 792a6a56-278f-4a01-9997-d997fa126370 | | locationRef | None | | name | backup1.2 | | parent_id | 1d474981-a006-4f62-b25f-43d7b8a7097e | | size | None | | status | NEW | | updated | 2014-03-19T14:09:13 | +-------------+--------------------------------------+ Now assume that your guest1 database instance is damaged and you need to restore it from your incremental backups. In this example, you use the trove create command to create a new database instance called guest2. To incorporate your incremental backups, you simply use the --backup parameter to pass in the BACKUP_ID of your most recent incremental backup. The Database service handles the complexities of applying the chain of all previous incremental backups. $ trove create guest2 10 --size 1 --backup BACKUP_ID +-------------------+-----------------------------------------------------------+ | Property | Value | +-------------------+-----------------------------------------------------------+ | created | 2014-03-19T14:10:56 | | datastore | {u'version': u'mysql-5.5', u'type': u'mysql'} | | datastore_version | mysql-5.5 | | flavor | {u'id': u'10', u'links': | | | [{u'href': u'https://10.125.1.135:8779/v1.0/ | | | 626734041baa4254ae316de52a20b390/flavors/10', u'rel': | | | u'self'}, {u'href': u'https://10.125.1.135:8779/ | | | flavors/10', u'rel': u'bookmark'}]} | | id | a3680953-eea9-4cf2-918b-5b8e49d7e1b3 | | name | guest2 | | status | BUILD | | updated | 2014-03-19T14:10:56 | | volume | {u'size': 1} | +-------------------+-----------------------------------------------------------+

You can manage database configuration tasks by using configuration groups. Configuration groups let you set configuration options, in bulk, on one or more databases. This example assumes you have created a MySQL database and shows you how to use a configuration group to configure it. Although this example sets just one option on one database, you can use these same procedures to set multiple options on multiple database instances throughout your environment. This can provide significant time savings in managing your cloud. First, determine which configuration options you can set. Different data store versions have different configuration options. List the names and IDs of all available versions of the mysql data store: $ trove datastore-version-list mysql +--------------------------------------+-----------+ | id | name | +--------------------------------------+-----------+ | eeb574ce-f49a-48b6-820d-b2959fcd38bb | mysql-5.5 | +--------------------------------------+-----------+ Pass in the data store version ID with the trove configuration-parameter-list command to get the available options: $ trove configuration-parameter-list DATASTORE_VERSION_ID +--------------------------------+---------+---------+----------------------+------------------+ | name | type | min | max | restart_required | +--------------------------------+---------+---------+----------------------+------------------+ | auto_increment_increment | integer | 1 | 65535 | False | | auto_increment_offset | integer | 1 | 65535 | False | | autocommit | integer | 0 | 1 | False | | bulk_insert_buffer_size | integer | 0 | 18446744073709547520 | False | | character_set_client | string | | | False | | character_set_connection | string | | | False | | character_set_database | string | | | False | | character_set_filesystem | string | | | False | | character_set_results | string | | | False | | character_set_server | string | | | False | | collation_connection | string | | | False | | collation_database | string | | | False | | collation_server | string | | | False | | connect_timeout | integer | 1 | 65535 | False | | expire_logs_days | integer | 1 | 65535 | False | | innodb_buffer_pool_size | integer | 0 | 68719476736 | True | | innodb_file_per_table | integer | 0 | 1 | True | | innodb_flush_log_at_trx_commit | integer | 0 | 2 | False | | innodb_log_buffer_size | integer | 1048576 | 4294967296 | True | | innodb_open_files | integer | 10 | 4294967296 | True | | innodb_thread_concurrency | integer | 0 | 1000 | False | | interactive_timeout | integer | 1 | 65535 | False | | join_buffer_size | integer | 0 | 4294967296 | False | | key_buffer_size | integer | 0 | 4294967296 | False | | local_infile | integer | 0 | 1 | False | | max_allowed_packet | integer | 1024 | 1073741824 | False | | max_connect_errors | integer | 1 | 18446744073709547520 | False | | max_connections | integer | 1 | 65535 | False | | max_user_connections | integer | 1 | 100000 | False | | myisam_sort_buffer_size | integer | 4 | 18446744073709547520 | False | | server_id | integer | 1 | 100000 | True | | sort_buffer_size | integer | 32768 | 18446744073709547520 | False | | sync_binlog | integer | 0 | 18446744073709547520 | False | | wait_timeout | integer | 1 | 31536000 | False | +--------------------------------+---------+---------+----------------------+------------------+ In this example, the configuration-parameter-list command returns a list of options that work with MySQL 5.5. A configuration group contains a comma-separated list of key-value pairs. Each pair consists of a configuration option and its value. You can create a configuration group by using the trove configuration-create command. The general syntax for this command is: $ trove configuration-create NAME VALUES --datastore DATASTORE_NAME NAME. The name you want to use for this group. VALUES. The list of key-value pairs. DATASTORE_NAME. The name of the associated data store. Set VALUES as a JSON dictionary, for example: {"myFirstKey" : "someString", "mySecondKey" : someInt} This example creates a configuration group called group1. group1 contains just one key and value pair, and this pair sets the sync_binlog option to 1. $ trove configuration-create group1 '{"sync_binlog" : 1}' --datastore mysql +----------------------+--------------------------------------+ | Property | Value | +----------------------+--------------------------------------+ | datastore_version_id | eeb574ce-f49a-48b6-820d-b2959fcd38bb | | description | None | | id | 9a9ef3bc-079b-476a-9cbf-85aa64f898a5 | | name | group1 | | values | {"sync_binlog": 1} | +----------------------+--------------------------------------+ Before you use the newly-created configuration group, look at how the sync_binlog option is configured on your database. Replace the following sample connection values with values that connect to your database: $ mysql -u user7 -ppassword -h 172.16.200.2 myDB7 Welcome to the MySQL monitor. Commands end with ; or \g. ... mysql> show variables like 'sync_binlog'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | sync_binlog | 0 | +---------------+-------+ As you can see, the sync_binlog option is currently set to 0 for the myDB7 database. You can change a database's configuration by attaching a configuration group to a database instance. You do this by using the trove configuration-attach command and passing in the ID of the database instance and the ID of the configuration group. Get the ID of the database instance: $ trove list +--------------------------------------+------------------+-----------+-------------------+--------+-----------+------+ | id | name | datastore | datastore_version | status | flavor_id | size | +--------------------------------------+------------------+-----------+-------------------+--------+-----------+------+ | 26a265dd-1c88-4333-b3ed-6b4e9e87ffbb | mysql_instance_7 | mysql | mysql-5.5 | ACTIVE | 6 | 5 | +--------------------------------------+------------------+-----------+-------------------+--------+-----------+------+ Get the ID of the configuration group: $ trove configuration-list +--------------------------------------+--------+-------------+--------------------------------------+ | id | name | description | datastore_version_id | +--------------------------------------+--------+-------------+--------------------------------------+ | 9a9ef3bc-079b-476a-9cbf-85aa64f898a5 | group1 | None | eeb574ce-f49a-48b6-820d-b2959fcd38bb | +--------------------------------------+--------+-------------+--------------------------------------+ Attach the configuration group to the database instance: This command syntax pertains only to python-troveclient version 1.0.6 and later. Earlier versions require you to pass in the configuration group ID as the first argument. $ trove configuration-attach DB_INSTANCE_ID CONFIG_GROUP_ID Display the sync_binlog setting again: mysql> show variables like 'sync_binlog'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | sync_binlog | 1 | +---------------+-------+ As you can see, the sync_binlog option is now set to 1, as specified in the group1 configuration group. Using a configuration group to set a single option on a single database is obviously a trivial example. However, configuration groups can provide major efficiencies when you consider that: A configuration group can specify a large number of option values. You can apply a configuration group to hundreds or thousands of database instances in your environment. Used in this way, configuration groups let you modify your database cloud configuration, on the fly, on a massive scale. There are also a number of useful maintenance features for working with configuration groups. You can: Disassociate a configuration group from a database instance, using the trove configuration-detach command. Modify a configuration group on the fly, using the trove configuration-patch command. Find out what instances are using a configuration group, using the trove configuration-instances command. Delete a configuration group, using the trove configuration-delete command. You might want to do this if no instances use a group.

You can create a replica of an existing database instance. When you make subsequent changes to the original instance, the system automatically applies those changes to the replica. Replicas are read-only. When you create a replica, do not specify the --users or --databases options. You can choose a smaller volume or flavor for a replica than for the original, but the replica's volume must be big enough to hold the data snapshot from the original. This example shows you how to replicate a MySQL database instance. Get the ID of the original instance you want to replicate: $ trove list +--------------------------------------+----------+-------------+-------------------+--------+-----------+------+ | id | name | datastore | datastore_version | status | flavor_id | size | +--------------------------------------+------------+-----------+-------------------+--------+-----------+------+ | 97b4b853-80f6-414f-ba6f-c6f455a79ae6 | base_1 | mysql | mysql-5.5 | ACTIVE | 10 | 2 | +--------------------------------------+----------+-------------+-------------------+--------+-----------+------+ Create a new instance that will be a replica of the original instance. You do this by passing in the --replica_of option with the trove create command. This example creates a replica called replica_1. replica_1 is a replica of the original instance, base_1: $ trove create replica_1 6 --size=5 --datastore_version mysql-5.5 --datastore mysql --replica_of ID_OF_ORIGINAL_INSTANCE Pass in replica_1's instance ID with the trove show command to verify that the newly created replica_1 instance is a replica of the original base_1. Note that the replica_of property is set to the ID of base_1. $ trove show INSTANCE_ID_OF_REPLICA_1 +-------------------+--------------------------------------+ | Property | Value | +-------------------+--------------------------------------+ | created | 2014-09-16T11:16:49 | | datastore | mysql | | datastore_version | mysql-5.5 | | flavor | 6 | | id | 49c6eff6-ef91-4eff-91c0-efbda7e83c38 | | name | replica_1 | | replica_of | 97b4b853-80f6-414f-ba6f-c6f455a79ae6 | | status | BUILD | | updated | 2014-09-16T11:16:49 | | volume | 5 | +-------------------+--------------------------------------+ Now pass in base_1's instance ID with the trove show command to list the replica(s) associated with the original instance. Note that the replicas property is set to the ID of replica_1. If there are multiple replicas, they appear as a comma-separated list. $ trove show INSTANCE_ID_OF_BASE_1 +-------------------+--------------------------------------+ | Property | Value | +-------------------+--------------------------------------+ | created | 2014-09-16T11:04:56 | | datastore | mysql | | datastore_version | mysql-5.5 | | flavor | 6 | | id | 97b4b853-80f6-414f-ba6f-c6f455a79ae6 | | ip | 172.16.200.2 | | name | base_1 | | replicas | 49c6eff6-ef91-4eff-91c0-efbda7e83c38 | | status | ACTIVE | | updated | 2014-09-16T11:05:06 | | volume | 5 | | volume_used | 0.11 | +-------------------+--------------------------------------+ If the original instance goes down, you can detach the replica. The replica becomes a standalone database instance. You can then take the new standalone instance and create a new replica of that instance. You detach a replica using the trove detach-replica command: $ trove detach-replica INSTANCE_ID_OF_REPLICA

You can store data across multiple machines by setting up MongoDB sharded clusters. Each cluster includes: One or more shards. Each shard consists of a three member replica set (three instances organized as a replica set). One or more query routers. A query router is the machine that your application actually connects to. This machine is responsible for communicating with the config server to figure out where the requested data is stored. It then accesses and returns the data from the appropriate shard(s). One or more config servers. Config servers store the metadata that links requested data with the shard that contains it. This example shows you how to set up a MongoDB sharded cluster. Make sure that: The administrative user has registered a MongoDB datastore type and version. The administrative user has created an appropriate flavor that meets the MongoDB minimum requirements. Create a cluster by using the trove cluster-create command. This command creates a one-shard cluster. Pass in: The name of the cluster. The name and version of the datastore you want to use. The three instances you want to include in the replication set for the first shard. Specify each instance by using the --instance argument and the associated flavor ID and volume size. Use the same flavor ID and volume size for each instance. In this example, flavor 7 is a custom flavor that meets the MongoDB minimum requirements. $ trove cluster-create cluster1 mongodb "2.4" \ --instance flavor_id=7,volume=2 --instance flavor_id=7,volume=2 \ --instance flavor_id=7,volume=2 +-------------------+--------------------------------------+ | Property | Value | +-------------------+--------------------------------------+ | created | 2014-08-16T01:46:51 | | datastore | mongodb | | datastore_version | 2.4 | | id | aa6ef0f5-dbef-48cd-8952-573ad881e717 | | name | cluster1 | | task_description | Building the initial cluster. | | task_name | BUILDING | | updated | 2014-08-16T01:46:51 | +-------------------+--------------------------------------+ Display information about a cluster by using the trove cluster-show command. Pass in the ID of the cluster. The cluster ID display when you first create a cluster. (If you need to find it later on, use the trove cluster-list command to list the names and IDs of all the clusters in your system.) $ trove cluster-show CLUSTER_ID +-------------------+--------------------------------------+ | Property | Value | +-------------------+--------------------------------------+ | created | 2014-08-16T01:46:51 | | datastore | mongodb | | datastore_version | 2.4 | | id | aa6ef0f5-dbef-48cd-8952-573ad881e717 | | ip | 10.0.0.2 | | name | cluster1 | | task_description | No tasks for the cluster. | | task_name | NONE | | updated | 2014-08-16T01:59:33 | +-------------------+--------------------------------------+ The trove cluster-show command displays the IP address of the query router. This is the IP address your application uses to retrieve data from the database. List the instances in a cluster by using the trove cluster-instances command. $ trove cluster-instances CLUSTER_ID +--------------------------------------+----------------+-----------+------+ | ID | Name | Flavor ID | Size | +--------------------------------------+----------------+-----------+------+ | 45532fc4-661c-4030-8ca4-18f02aa2b337 | cluster1-rs1-1 | 7 | 2 | | 7458a98d-6f89-4dfd-bb61-5cf1dd65c121 | cluster1-rs1-2 | 7 | 2 | | b37634fb-e33c-4846-8fe8-cf2b2c95e731 | cluster1-rs1-3 | 7 | 2 | +--------------------------------------+----------------+-----------+------+ Note that the Name column displays an instance name that includes the replication set name. The replication set names and instance names are automatically generated, following these rules: This name consists of the cluster name, followed by the string -rsn, where n is 1 for the first replication set you create, 2 for the second replication set, and so on. In this example, the cluster name is cluster1, and there is only one replication set, so the replication set name is cluster1-rs1. This name consists of the replication set name followed by the string -n, where n is 1 for the first instance in a replication set, 2 for the the second instance, and so on. In this example, the instance names are cluster1-rs1-1, cluster1-rs1-2, and cluster1-rs1-3. List all the clusters in your system, using the trove cluster-list command. $ trove cluster-list +--------------------------------------+----------+-----------+-------------------+-----------+ | ID | Name | Datastore | Datastore Version | Task Name | +--------------------------------------+----------+-----------+-------------------+-----------+ | aa6ef0f5-dbef-48cd-8952-573ad881e717 | cluster1 | mongodb | 2.4 | NONE | | b8829c2a-b03a-49d3-a5b1-21ec974223ee | cluster2 | mongodb | 2.4 | BUILDING | +--------------------------------------+----------+-----------+-------------------+-----------+ Delete a cluster, using the trove cluster-delete command. $ trove cluster-delete CLUSTER_ID Each cluster includes at least one query router and one config server. Query routers and config servers count against your quota. When you delete a cluster, the system deletes the associated query router(s) and config server(s).