How RadonDB Merges Raft and MySQL for Scalable Cloud‑Native Databases

Background

This article is based on Zhang Yanfeng’s presentation at the 9th China Database Technology Conference (DTCC) on May 10, 2018, where he introduced RadonDB, a new generation distributed relational database that integrates Raft consensus with MySQL.

RadonDB Overview

RadonDB is positioned as a cloud‑native distributed relational database. Its key advantage is merging the strengths of traditional MySQL with the scalability and fault‑tolerance of NewSQL, enabling DBAs to transition from single‑node MySQL to an infinitely scalable, highly available system.

Architecture Diagram

The architecture consists of two layers: an upper distributed SQL layer composed of multiple SQL nodes that parse user requests and generate distributed execution plans, and a lower storage layer where each replica is a MySQL instance. The storage layer achieves high availability through the Raft algorithm.

Distributed SQL Layer

The SQL layer parses incoming queries into distributed execution plans, performs secondary operations such as ORDER BY, LIMIT, GROUP BY, aggregation, and joins, and then dispatches the plan to the storage layer for parallel execution. Its decentralized design simplifies deployment and scaling.

Storage Nodes

Each storage replica runs a full MySQL instance, providing both compute and storage capabilities. Three‑replica MySQL groups use Raft for leader election and MySQL’s native mechanisms (GTID, parallel replication, Semi‑Sync) for fast data replay and loss‑free synchronization.

High‑Availability Challenges

Rapid leader election – solved by Raft.

Fast data replay after a new leader is elected – achieved using MySQL’s GTID and parallel replication.

Ensuring no data loss – guaranteed by MySQL’s Semi‑Sync mechanism, where writes are acknowledged only after a replica confirms receipt.

By combining Raft leader election with MySQL’s log replication, RadonDB provides a decentralized, flexible deployment model.

Scaling (Expansion)

Large tables are split into many small tables. Hot small tables are migrated first using a two‑phase process: a full copy records the current binlog position, then incremental changes are applied via GTID, allowing dynamic rebalancing with minimal impact on front‑end services.

Distributed Transactions

RadonDB leverages MySQL’s native XA protocol, abstracting the five‑step XA flow and providing Snapshot Isolation for distributed transactions.

Binlog Support

RadonDB implements a Binlog mechanism that enables rapid data export and synchronization, facilitating real‑time data flow to external systems.

OLTP + OLAP Integration

By configuring an OLAP cluster as a Binlog consumer, RadonDB streams changes in real time, allowing seamless hybrid workloads. The compute node routes queries to TP or AP nodes based on query patterns, providing resource isolation while maintaining a unified interface.

Audit Logging

Audit logs help trace slow queries and monitor business activities across distributed nodes, simplifying performance diagnostics.

Backup and Recovery

RadonDB offers a complete backup and recovery toolkit that accelerates data import/export compared with native MySQL tools.

Performance

Benchmarks show RadonDB achieving roughly three times the throughput of a single‑node MySQL with only one‑third of the latency, and performance scales linearly with added nodes.

Monitoring

RadonDB provides end‑to‑end monitoring commands such as show processlist, show txnz, and show queryz to expose connection status, transaction phases, and query routing details, turning the distributed system from a black box into an observable service.