OpenStack Trove for users, sys admins, and database admins



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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Exploring OpenStack's Trove DBaaS
    DBaaS moves the database service to the cloud, promising a new database instance at the click of a mouse.
  • The new OpenStack version 2014.1 alias "Icehouse"
    The new OpenStack version "Icehouse" comes with new features and new components, on top of numerous improvements to existing components.
  • How to back up in the cloud
    In cloud computing practice, backups are important in several ways: Customers want to secure their data, and vendors want to secure the essential details of their platforms. Rescue yourself, if you can.
  • Ceph and OpenStack Join Forces

    When building cloud environments, you need more than just a scalable infrastructure; you also need a high-performance storage component. We look at Ceph, a distributed object store and filesystem that pairs well in the cloud with OpenStack.

  • The state of OpenStack in 2022
    The unprecedented hype surrounding OpenStack 10 years ago changed to disillusionment, which has nevertheless had a positive effect: OpenStack is still evolving and is now mainly deployed where it actually makes sense to do so.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=