Read/write splitting routes write requests to the primary instance and read requests to read-only instances through a single database proxy endpoint. Use this feature when your workload has significantly more reads than writes and the primary instance can no longer handle the read load alone.
Connect your application to one database proxy endpoint instead of managing separate endpoints for the primary and each read-only instance. The proxy handles all routing automatically.
When to use read/write splitting
Read/write splitting is a good fit if you are facing any of the following:
Read-heavy workloads: Your application runs far more SELECT queries than INSERT, UPDATE, or DELETE operations.
Primary instance bottleneck: The primary instance CPU or I/O is saturated by read traffic, even though write volume is manageable.
Read scaling without connection changes: You want to add read capacity without modifying your application's connection logic.
Benefits
Single endpoint, no routing code: Connect once to the database proxy endpoint. The proxy forwards writes to the primary instance and distributes reads across read-only instances automatically — no need to maintain separate connection strings per instance.
Lower latency than a self-built proxy: Read/write splitting is embedded in the ApsaraDB RDS ecosystem. Data does not pass through additional intermediary layers, which reduces response latency compared to building your own proxy in the cloud.
Configurable read weights and latency threshold: Specify a read weight for each instance to control how read requests are distributed. Set a replication latency threshold so that lagging read-only instances are automatically excluded from the read pool.
Automatic health check and failover: The proxy continuously monitors each instance. If a read-only instance fails or its replication latency exceeds the threshold, the proxy stops routing reads to it and redistributes those requests to healthy instances. After the instance recovers, routing resumes automatically.
Create at least two read-only instances to avoid a single point of failure (SPOF).
Prerequisites
Before you enable read/write splitting, ensure that you have:
An ApsaraDB RDS for MySQL instance running RDS High-availability Edition or RDS Cluster Edition
For RDS High-availability Edition: at least one read-only instance created (two or more recommended)
For RDS Cluster Edition: no read-only instances required — the secondary node can be accessed and processes only read requests
Read/write splitting is not supported on RDS Basic Edition.
How it works
After you enable the database proxy feature, read/write splitting is automatically active — no additional configuration is required. Navigate to Database Proxy in the left-side navigation pane of the instance details page to get the database proxy endpoint (formerly called proxy terminal), then update your application connection string to use it.
Request routing
The dedicated proxy routes each request based on its type:
Primary RDS instance
Write statements: INSERT, UPDATE, DELETE, SELECT FOR UPDATE
All DDL operations (create or drop databases/tables, schema and permission changes)
All requests inside transactions (unless the transaction splitting feature is enabled)
Non-read-only transactions at Repeatable Read (RR) isolation level and higher
User-defined functions and stored procedures
Explicitly created temporary tables
SELECT last_insert_id()User variable queries and updates
KILLstatements in SQL (these are different from KILL commands),LOCK TABLE,UNLOCK TABLEFLUSHstatements includingFLUSH TABLES WITH READ LOCK(FTWRL)SAVEPOINT
Primary RDS instance or read-only RDS instance
SELECTstatements outside transactionsSTART TRANSACTION READ ONLY
All RDS instances
System variable updates
USEstatementsSHOW PROCESSLIST— the dedicated proxy aggregates and returns processes from all instancesNAMED PREPARECOM_CHANGE_USER,COM_QUIT,COM_SET_OPTION
Read/write attribute behavior
The database proxy endpoint supports two read/write attribute modes. The table below shows how each mode behaves under normal conditions and when read-only instances become unavailable.
| Read/write attributes | Read weight method | Primary instance weight | Normal | After the last read-only instance is deleted | After all read-only instances are faulty |
|---|---|---|---|---|---|
| Read-only | Automatic or Custom | Cannot be specified | Primary: no requests. Proxy: read requests only. | Primary: no requests. Proxy: connection error. | Primary: no requests. Proxy: connection error. |
| Read and write | Automatic | 0 (see Rules of read weight allocation by the system) | Primary: write requests only. Proxy: read and write requests. | Primary: read and write requests. Proxy: read and write requests. | Primary: read and write requests. Proxy: read and write requests. |
| Read and write | Custom | Greater than 0 | Primary: read and write requests. Proxy: read and write requests. | Primary: read and write requests. Proxy: read and write requests. | Primary: read and write requests. Proxy: read and write requests. |
| Read and write | Custom | 0 | Primary: write requests only. Proxy: read and write requests. | Primary: read and write requests. Proxy: read and write requests. | Primary: read and write requests. Proxy: read and write requests. |
No requests on the primary: The primary instance is not involved in read-only request forwarding.
Connection error: A connection error is returned when the proxy endpoint has no available instances to route to.
In Read and write mode with primary weight set to 0, read requests go to read-only instances by default. Exceptions: all read-only instances are faulty, a forceful hint is specified, or transaction splitting is enabled.
For configuration details, see Configure the read/write attributes and read weights.
What's next
After enabling read/write splitting, you can:
Configure read/write attributes and read weights — adjust which instances handle reads and at what proportion.
Verify read/write splitting — confirm that traffic is being routed correctly.
Enable SQL Explorer and Audit temporarily to inspect how SQL statements are distributed across instances (note: this feature is billed separately; you can disable it when it is no longer needed).