RDS Cluster Edition for ApsaraDB RDS for MySQL is a high availability (HA) architecture with one primary node and up to eight readable secondary nodes. Unlike RDS High-availability Edition, where secondary nodes handle only failover, every secondary node in an RDS cluster can serve read traffic—eliminating the need for separate read-only instances and reducing costs by 40%.
How it works
An RDS cluster runs on a primary-plus-secondary architecture with compute-storage separation. The primary node handles all write requests. Secondary nodes replicate data from the primary and simultaneously serve read requests through a dedicated read-only routing endpoint.
Three replication modes are supported:
-
Asynchronous replication — lowest write latency; secondary nodes may briefly lag behind the primary.
-
Semi-synchronous replication — the primary waits for at least one secondary to acknowledge data before committing, balancing latency and consistency.
-
MySQL Group Replication (MGR) — based on the Paxos distributed consensus protocol, MGR guarantees a recovery point objective (RPO) of 0. Requires more than three nodes.
Edition comparison
| Item | RDS Basic Edition | RDS High-availability Edition | RDS Cluster Edition |
|---|---|---|---|
| Number of nodes | 1 | 2 (default) | 2–9 |
| Readable secondary nodes | N/A | Not supported | Supported |
| Endpoint types | Read/write endpoint | Read/write endpoint | Read/write endpoint and read-only routing endpoint |
| Replication modes | Not supported | Asynchronous and semi-synchronous | Asynchronous, semi-synchronous, and MGR |
| Maximum unavailable nodes | 0 | 1 | n − 1 (n = total nodes) |
| Number of zones | 1 | ≤ 2 | ≤ number of nodes |
RDS High-availability Edition provisions one primary instance and one secondary instance by default. Additional read capacity requires separate read-only instances. RDS Cluster Edition provisions one primary node and two secondary nodes by default. You can also create a cluster with one primary node and one secondary node, then add nodes later up to a maximum of nine.
When to use Cluster Edition
Choose RDS Cluster Edition when your workload matches one of the following scenarios:
-
Read-heavy workloads. Secondary nodes serve read traffic directly. Scale read capacity by adding nodes rather than creating separate read-only instances.
-
Zero data loss requirement. Enable MGR mode (requires more than three nodes) to guarantee RPO = 0.
-
Cross-zone disaster recovery with multiple redundancy levels. Deploy secondary nodes across different zones. An n-node cluster tolerates up to n − 1 node failures.
-
Variable read traffic. Add or remove secondary nodes on demand without recreating the cluster.
RDS Cluster Edition suits online retail, automotive, education, and Enterprise Resource Planning (ERP) workloads that process high read volumes during peak hours or run analytical queries against production data.
Key features
Readable secondary nodes
Secondary nodes handle read requests through two access methods:
-
Read-only routing endpoint — create one free of charge, add multiple secondary nodes, and assign read weights to balance load. For details, see View and manage instance endpoints and ports.
-
Database proxy — enables read/write splitting between the primary and secondary nodes, plus automatic read/write splitting, connection pooling, persistent connections, latency threshold controls, and transaction splitting. Starting June 25, 2024, if you create a primary RDS instance that runs RDS Cluster Edition, general-purpose database proxies are included at no additional cost. For details, see What are database proxies?
To upgrade from a general-purpose proxy to a dedicated proxy for higher stability, see Change the database proxy type and number of database proxies. To disable the dedicated proxy, see Disable the dedicated proxy feature.
Flexible node management
Add or remove secondary nodes after cluster creation to match your capacity needs. Each node is monitored independently through node-level monitoring, giving you visibility into the status of every node in the cluster. For details, see Add a node to an ApsaraDB RDS for MySQL cluster and Delete a node from an ApsaraDB RDS for MySQL cluster.
High reliability
RDS Cluster Edition includes cloud-native reliability improvements:
-
Second-granularity fault detection — the HA system detects secondary node failures in seconds, down from minute-granularity in earlier architectures.
-
Fast data restore — single-digit second backups powered by Elastic Block Storage (EBS) reduce restore time from tens of minutes to approximately 1 minute. Secondary nodes recover from failures within 10 minutes in 99% of cases.
-
Automatic rebuilding — if a secondary node falls more than 7,200 seconds (2 hours) behind the primary, it automatically rebuilds to resolve the lag.
-
Cross-zone disaster recovery — deploy secondary nodes across different zones. All secondary nodes participate in disaster recovery, providing more redundancy levels than a two-node HA setup.
Limitations
-
RDS Cluster Edition is supported for MySQL 5.7 and MySQL 8.0 only.
-
MGR mode requires more than three nodes in the cluster.
-
A cluster can contain a maximum of nine nodes (one primary node and eight secondary nodes).
What's next
| Task | Reference |
|---|---|
| Create an RDS cluster | Step 1: Create an ApsaraDB RDS for MySQL instance and configure databases |
| Add a node | Add a node to an ApsaraDB RDS for MySQL cluster |
| Remove a node | Delete a node from an ApsaraDB RDS for MySQL cluster |
| Upgrade from RDS High-availability Edition | Upgrade from RDS High-availability Edition to RDS Cluster Edition |
| Upgrade from RDS Basic Edition | Upgrade from RDS Basic Edition to RDS Cluster Edition |
| Migrate from RDS Enterprise Edition | Migrate data from RDS Enterprise Edition to RDS Cluster Edition |
| Learn about MGR | MGR overview |
| Enable MGR | Use the MGR mode |
| Enable the database proxy | Enable the dedicated proxy feature |
| Configure proxy access policies | Configure access policies for a database proxy endpoint |