How MySQL 8.0 Powers Modern DBaaS: Architecture, Availability, and Future Plans

1. MySQL 8.0

MySQL, a 20‑year‑old open‑source database, has evolved to support both SQL and NoSQL workloads. Since version 5.7 it offered a JSON data type, and MySQL 8.0 further optimizes JSON handling and introduces the X Protocol to expose NoSQL‑style APIs.

These improvements let MySQL serve as a hybrid SQL + NoSQL platform, offering richer query capabilities comparable to PostgreSQL while maintaining compatibility with existing MySQL deployments.

2. Why DBaaS?

Enterprises increasingly demand a Database‑as‑a‑Service (DBaaS) model that abstracts MySQL management, enabling customers without deep engineering resources to consume the database reliably. The goal is to provide self‑service, automated provisioning, and standardized operations without requiring customers to manage the underlying infrastructure.

3. Architecture Evolution

First generation (2011) : A simple two‑plane design with a manager handling API calls and agents on each MySQL node. The manager and agents were written in Java, and the manager stored metadata in MySQL.

Second generation : Introduced a separate management layer (manage) and an additional component Haserver to handle master‑slave failover, though it only supported single‑master failover.

Third generation : Re‑architected using Go for scalability, micro‑service decomposition, and layered guard mechanisms. Key components include: ucore: Distributed configuration store with leader election for high availability. UMC: Global management entry for DBAs. URDS: Self‑service portal for developers. Urman‑mgr: Backup scheduling and execution. umonitor / ustat: Monitoring and performance data collection. Uguard‑mag / uguard‑agent: Automated failover decision and execution. uproxy: Transparent read/write splitting middleware written in C++. ushard: Horizontal sharding and routing.

4. Service Availability Design

Availability is addressed at multiple layers: ensuring master‑slave switch‑over, protecting read‑only slaves, monitoring replication health, and guarding the control plane (ucore) with leader‑follower election. SLA metrics (RPO/RTO) quantify data loss tolerance and recovery time objectives, with configurable levels (P/PE for RPO, T/TE for RTO).

5. Data Availability Design

Backup is orchestrated by the manager, dispatched to agents, and stored locally or off‑loaded. Regular disaster‑recovery drills are scheduled within time windows to avoid resource contention, and backup duration is recorded for future optimization.

6. Monitoring Design

The platform adopts Prometheus for metric collection and Grafana for visualization. A unified exporter aggregates metrics from all MySQL instances, enabling automatic service discovery, high‑performance parallel scraping, and eventual sharding of metric storage.

7. DTS (Data Transfer Service) Design

DTS provides distributed, fault‑tolerant data migration with support for full and incremental transfers, GTIB parallel replay, and integration with Kafka for downstream big‑data pipelines. The manager uses leader‑follower election for HA, while agents extract binlogs from MySQL and replay them in parallel.

8. Future Planning

Upcoming goals include extending the platform to manage other open‑source databases (Redis, Elasticsearch, PostgreSQL), containerizing services for seamless version upgrades, and supporting hybrid private‑plus‑public cloud deployments.