Clustered

When you start a database with Trove, you can determine whether the database should run on a single VM or in a cluster. This works for all database drivers in Trove that support replication of the respective database (i.e., currently, MongoDB, MySQL, Redis, Cassandra, and others, but not PostgreSQL).

With the use of MySQL, the approach from the admin's point of view is simple: First, start a single MySQL database, which is then supported with a slave database. The Trove agent running on the VM started by Trove then automatically configures the database. In this way, the cluster is created without any further intervention by the user. The command:

trove create lm-slave 1 --size 2 --slave_of ae427c76-eee3-11e6-802a-00215acd73e2

would add a slave node named lm-slave of flavor 1 to the database with the ID ae427c76-eee3-11e6-802a-00215acd73e2 (Figure 3).

Figure 3: Trove can use the clustering modes of a variety of database systems, including MySQL, as shown here.

If you are using a fairly recent cloud with OpenStack Mitaka, you could even use Galera for clustering with MySQL (see also the article on MySQL group replication [6]). Trove then starts several MySQL instances and prepares them in such a way that Galera creates a multimaster database.

Such a setup easily can be combined with local storage on hypervisor nodes: Because the data then exists several times on different hosts, it does not matter if a single host fails or temporarily disappears from the cluster for maintenance. However, Galera replicates synchronously, so a single network latency at least is generated, which is passed on to the client. However, this is significantly lower latency than for Ceph.

Backups and Snapshots

Creating snapshots or backups is part of everyday operations when you work with databases. A running database is a good thing to have, but the gap between being happy and losing all your data is narrow. Data is often destroyed by overly eager delete commands, and sometimes the content of the database breaks down completely, even without fat fingering. For example, imagine a software update that also updates the database schema unfortunately going wrong and leaving only garbage in the database. In such cases, a good solution is necessary, and a backup is critical to the admin's survival.

The number of tools that can be used to back up and restore different databases is almost unmanageable. Because a user running Trove on a VM cannot actually get to the database, some of the usual candidates are already ruled out. Therefore, Trove developers have given their software its own backup feature: Backups can be launched directly from the VM via the OpenStack API and stored centrally. The restore follows the same path. The following example demonstrates the MySQL-based approach.

Backup Database

First, the user needs the ID of the Trove instance from which a backup is to be created. At the command line, the trove list command displays all running Trove instances belonging to the respective user. The entries in the id field are important. As soon as the ID of the database from which a backup is to be created is known, you then run the

trove backup-create <ID> backup-1

command to achieve the desired results (Figure 4). This command then displays the backup it created. If the entry in the status field reads COMPLETED , everything worked.

Figure 4: Backing up a database with Trove is easy, given it has been installed and configured successfully.

For successful backups, the Trove Guest Agent must be configured properly on the VM. More specifically, /etc/trove/trove-guestagent.conf needs to state where the Guest Agent should store the backups. The default is in OpenStack Swift, the cloud environment's object store.

If you want the backups to be placed elsewhere, as a customer, you will either need to give your VM a modified Guest Agent configuration via the Nova metadata or ask the provider to provide a Trove image. The provider should do the groundwork, anyway, and offer a Trove image in Glance that is adapted to the respective environment.