How QiYun Enhances OpenStack Trove for Seamless Master‑Slave Database Deployment

Introduction

OpenStack Trove provides Database-as-a-Service (DBaaS) on OpenStack, allowing users to quickly provision relational or non‑relational databases without handling complex management tasks.

Trove Overview

Trove runs entirely within OpenStack, interacting with other services via RESTful APIs. It creates virtual machines that host the trove‑guestagent and the database program, stores images in Glance, obtains network information from Neutron, and authenticates through Keystone.

Trove Components

API Server

Message Bus

Task Manager

Guest Agent

Conductor

The API Server exposes RESTful endpoints for creating and managing instances, delegating heavy asynchronous tasks to the Task Manager, while simple tasks may be handled directly by the Guest Agent.

The Task Manager performs resource‑intensive operations such as instance creation, lifecycle management, and database actions.

The Guest Agent runs inside each database instance, listening to the message queue and managing the database.

The Conductor runs on the host, receiving messages from client instances.

Key Concepts

Instance : a database instance, i.e., an OpenStack VM containing the database program.

Replica instance : a read‑only copy that must be linked to a master instance at creation.

Datastore/Datastore version : defines the database type, version, and associated VM image; required when creating an instance.

QiYun’s Implementation

System Architecture

Based on the native Mitaka version of Trove, QiYun added automated backup (Trove‑backup), monitoring (Trove‑monitor), and optimized master‑slave switching, instance scaling, and parameter configuration.

Creating Master‑Slave Instances

QiYun Trove supports a single API request that creates both master and slave instances, each belonging to separate physical clusters. The VM includes two NICs: a management NIC for internal communication and a data NIC isolated from the user network, plus a service IP (VIP) to enable seamless master‑slave failover.

Master‑Slave Failover

Clients connect to the database via the VIP. If the master node fails, administrators can switch roles by moving the VIP to the slave, ensuring continuous service availability.