How Cetus Middleware Optimizes MySQL Read Load Balancing and Performance

Background

Rapid growth of NetEase e‑commerce services has caused MySQL instances to experience high read and write pressure. Simple hardware upgrades are insufficient, so read traffic must be off‑loaded to replicas and write pressure must be reduced by sharding data across multiple nodes. Traditional DAO‑level sharding requires service restarts, complex result‑set handling, and difficult operations. To address these bottlenecks, NetEase Lede’s DBA team built the open‑source Cetus middleware on a fully patched MySQL‑Proxy.

Load‑Balancing Strategies and Optimizations

1. Master‑Replica Read Routing

By default, non‑transactional reads that are not forced to the master are sent to replicas and distributed across them. Only when all replicas are unavailable does the traffic fall back to the master.

The read-master-percentage parameter controls the proportion of reads directed to the master. Its valid range is [0, 100]: 0 – all reads go to replicas (default). 100 – all reads go to the master.

Any intermediate value – reads are split proportionally between master and replicas.

2. Replica‑to‑Replica Load Balancing

Read traffic that reaches replicas is distributed using a simple round‑robin (RR) algorithm. Weight‑based distribution is not currently supported.

3. Connection‑Aware Optimization

In long‑connection scenarios, per‑SQL load balancing can cause frequent session‑level variable changes, degrading performance. Cetus retains a MySQL connection for 256 ms after a query finishes, allowing subsequent queries on the same connection to reuse the existing session and avoid variable churn.

Performance Evaluation

A Docker‑based benchmark compared the original and optimized Cetus versions. The test used 100 concurrent threads for 60 seconds, disabled transactions and prepared statements, and limited result‑set size to avoid excessive I/O. The optimized build achieved roughly a 30 % increase in throughput, with larger gains expected in real‑world long‑connection workloads.

Read Routing Decision Factors

When at least one replica is available, the following factors determine the routing of a query (ordered by precedence):

Queries executed inside a transaction. SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE.

Setting master-preferred=true forces all traffic to the master.

Configuring read-master-percentage to control the master‑replica split.

Comment hints /*#mode=READWRITE*/ (force master) or /*#mode=READONLY*/ (prefer replicas).

Comment hints have the highest priority, followed by master-preferred, and finally read-master-percentage. By default, reads are sent to replicas using round‑robin; if all replicas fail, reads fall back to the master.

Reference

Cetus documentation:

https://github.com/Lede-Inc/cetus/blob/master/doc/cetus-quick-try.md