Exploring RadonDB: A Distributed MySQL Solution for Modern DBA Challenges

Background Introduction

Before diving into RadonDB, the article outlines common pain points for DBAs using traditional MySQL master‑slave or master‑slave + proxy setups, including fast failover with third‑party plugins (e.g., MHA), handling massive sharded data for GROUP/SORT/LIMIT/JOIN queries, uneven data distribution after sharding and subsequent re‑sharding, and guaranteeing distributed transactions across shards.

RadonDB Architecture

RadonDB addresses these issues with a layered architecture that adds Compute Nodes to the typical sharding middleware + MySQL stack.

SQL Node

The SQL Node handles distributed execution plans and transaction coordination, providing distributed transaction guarantees for DML operations (DDL lacks such guarantees). It offers a single writable endpoint to ensure snapshot isolation, stores table metadata for easy data migration, and exchanges metadata changes with peers using a gossip protocol similar to Redis Cluster.

Storage Nodes

Storage Nodes are built on MySQL 5.7 (compatible with 5.6 + GTID) forming N ≥ 1 groups of master‑slave clusters. Raft‑style consensus, based on GTID logs, enables automatic high‑availability failover. RadonDB requires GTID mode, strong semi‑sync replication, and a never‑timeout mechanism, though configurations can be tuned per scenario.

Compute Nodes

Compute Nodes parse incoming SQL, identify complex statements, and route them for execution. They store a full copy of all data from Storage Nodes and stay up‑to‑date via a binlog subscription‑consumption model. Implemented as plugins, Compute Nodes can use databases other than MySQL, but they incur significant storage overhead despite compression.

Data Balancing

RadonDB’s table‑storage strategy automatically splits a table (e.g., using id as the shard key) into 32 small tables distributed evenly across Storage Nodes. Each small table owns a hash slot range, mirroring Redis Cluster’s slot allocation, which simplifies maintenance and data migration even for tables exceeding 100 GB.

When scaling out, RadonDB uses a Go‑based “shifter” tool to perform concurrent full‑plus‑incremental synchronization of the small tables. Migration prefers moving the smallest tables first, and the original table briefly enters a read‑only state during the final routing switch, causing a minimal service jitter.

Summary

RadonDB can be viewed as a middleware that combines modern distributed consensus (Raft), gossip‑based communication, and MySQL to deliver a comprehensive distributed solution. It resolves long‑standing DBA challenges such as distributed transactions, data balancing, high‑availability failover, consistency, and complex query performance.

Practical suggestions include exploring more elegant data migration methods (e.g., direct shard‑to‑shard sync), adopting VIP or service‑discovery mechanisms (Consul, QConf) for transparent access, and considering RadonDB as a migration path for private‑cloud environments stuck on older MySQL versions.

RadonDB is expected to open source in mid‑May, promising a fresh experience for MySQL operations.