CynosDB: Cloud‑Native Distributed Database Architecture and Performance Optimizations

Introduction – With rapid growth of Tencent Cloud's database services and the MySQL ecosystem, the CDB platform has become a top‑ranked cloud database, prompting the team to collaborate on improving stability, reducing costs, and enriching DBaaS features.

Challenges of Traditional Cloud Databases – Despite performance gains, CDB faces two major issues: operational pressure from improper user usage as instance count and storage scale increase, and inefficient resource utilization leading to waste.

Backup and Recovery – CDB supports physical and logical backups. Physical backup copies redo logs and data files, acquiring a global read lock before copying; logical backup uses SQL statements, setting a global read lock, capturing binlog positions, and performing snapshot reads.

Master‑Slave Synchronization – MySQL uses binlog‑based logical replication, which suffers from latency, data inconsistency, and large‑transaction delays. Parallel replication in MySQL 5.6 mitigates but does not fully resolve these problems.

Database Upgrade and Crash Recovery – Instance migration relies on backup plus incremental binlog. Crash recovery replays redo logs from the last checkpoint and processes binlog transactions, but heavy write load can extend RTO.

Performance Bottlenecks – Traditional cloud databases encounter weak elasticity, severe resource waste, unstable RTO/RPO, and multiple I/O operations (redo log, binlog, async flush) that become bottlenecks.

CynosDB Emergence – CynosDB is a cloud‑native, distributed database built on a log‑is‑database model with a shared‑disk architecture. It separates compute and storage layers, offering up to 15 read‑only replicas, 128 TB storage, and aims to solve the aforementioned problems.

Compute Layer Features – No local data files, no binlog, only redo log for data synchronization; no checkpoint or dirty‑page flushing; crash recovery only rolls back unfinished transactions; backup nodes use redo log solely for memory sync.

Storage Layer Features – Parallel redo‑log apply, multi‑version page storage, persistent data handling, and space management via recycle commands.

How CynosDB Solves Traditional Issues – Elastic resource pooling, on‑demand charging, high availability with drastically reduced RTO/RPO, redo‑log‑based replication eliminating binlog bottlenecks, and physical‑log replication boosting write performance.

Implementation Details – Offloading local I/O to network RIO, converting metadata to remote storage, eliminating double‑write buffers and checkpoints, handling temporary tables, and adding redo‑log support for index creation.

Memory Synchronization and MVCC – Primary and replica share the same data; redo log synchronizes buffer pools; MVCC read‑view construction ensures consistency; purge operation reclaims undo‑log space based on the oldest read view across all replicas.

Performance Optimizations – Asynchronous thread‑pool submission, parallel redo‑log copying, transaction system refinements, asynchronous DDL, lock‑free queues, and async redo‑log flushing raise single‑node write throughput to ~250 k TPS and read‑only replica throughput beyond 1 M TPS.

Correctness Verification – TPCC transaction tests, custom Lua scripts for isolation‑level checks, and kernel‑level validation ensure replica query results match the primary.

Adding Read‑Only Nodes – The shared‑data design enables adding read‑only replicas within seconds.

Conclusion – CynosDB demonstrates how a cloud‑native, compute‑storage decoupled architecture can overcome elasticity, stability, and resource‑waste challenges of traditional cloud databases, offering high performance, strong consistency, and easy scalability.