RDS Cluster Edition is supported for ApsaraDB RDS for MySQL and ApsaraDB RDS for SQL Server. This topic describes the architectures, benefits, and scenarios of RDS Cluster Edition for ApsaraDB RDS for MySQL and ApsaraDB RDS for SQL Server.
RDS Cluster Edition for ApsaraDB RDS for MySQL
RDS Cluster Edition for ApsaraDB RDS for MySQL uses a high availability (HA) architecture that contains one primary node and multiple secondary nodes and supports compute-storage separation. RDS Cluster Edition provides the following features: automated failover, primary/secondary switchover, readable secondary nodes, node addition and deletion, multi-zone disaster recovery, node-level monitoring, and cluster topology management. RDS Cluster Edition also allows you to use the MySQL group replication (MGR) mode to ensure a recovery point objective (RPO) of 0. An RDS cluster is more cost-effective, flexible, and reliable than a self-managed database.
The following table compares RDS Basic Edition, RDS High-availability Edition, and RDS Cluster Edition for ApsaraDB RDS for MySQL.
RDS Basic Edition
RDS High-availability Edition
RDS Cluster Edition
Number of nodes or instances
In RDS High-availability Edition, one primary instance and one secondary instance are provisioned by default. If you require more instances, you can create read-only instances.
2 to 9
In RDS Cluster Edition, one primary node and two secondary nodes are provisioned by default. You can also create an RDS cluster that consists of one primary node and one secondary node. An RDS cluster is referred to as an RDS instance that runs RDS Cluster Edition. After an RDS cluster is created, you can add nodes to the RDS cluster. The RDS cluster can contain a maximum of nine nodes, including one primary node and eight secondary nodes.
Readable secondary instances or nodes
Asynchronous replication and semi-synchronous replication
Asynchronous replication, semi-synchronous replication, and MGR
Maximum number of unavailable instances or nodes
n - 1. n indicates the number of nodes in an RDS cluster.
Number of zones
Less than or equal to 2
Less than or equal to the number of nodes in an RDS cluster
RDS Cluster Edition is supported for ApsaraDB RDS for MySQL instances that run MySQL 5.7 and MySQL 8.0. An RDS cluster uses the HA architecture of one primary node and multiple secondary nodes. The following figure shows the architecture.
Secondary nodes in an RDS cluster are readable. You do not need to create read-only RDS clusters. This linearly increases the read capability of the RDS cluster and reduces resource overheads and costs. If you use RDS High-availability Edition and you want to increase the read capability of your RDS instance, you must create read-only RDS instances. Compared with RDS High-availability Edition, RDS Cluster Edition reduces the costs by 40%.
You can use one of the following methods to access the secondary nodes in an RDS cluster:
Read-only routing endpoint: You can create a read-only routing endpoint for an RDS cluster free of charge and add multiple secondary nodes to the read-only routing endpoint. Then, you can specify read weights for the secondary nodes to balance loads. For more information, see View and manage instance endpoints and ports.
Database proxy: You can enable the database proxy feature for an RDS cluster to implement read/write splitting on the primary and secondary nodes in the RDS cluster. Compared with the read-only routing endpoint, the database proxy feature supports advanced capabilities, including automatic read/write splitting, persistent connections, connection pooling, latency threshold, and transaction splitting. For more information, see Enable and configure the dedicated proxy feature and What are database proxies?Note
Starting October 17, 2023, if you create a primary RDS instance that runs RDS Cluster Edition, the dedicated proxy feature is enabled and a proxy that has 2 CPU cores is provided for the RDS instance by default. You are not charged for the dedicated proxy feature. For more information, see [Special offers/Price changes] One proxy is provided free of charge for ApsaraDB RDS for MySQL instances on RDS Cluster Edition and Billing rules for the dedicated proxy feature of ApsaraDB RDS for MySQL.
If you have higher requirements on the stability of database proxies, you can change the proxy type from general-purpose to dedicated. For more information, see Change the database proxy type and number of database proxies and What are database proxies?
You can disable the dedicated proxy feature at any time. For more information, see Disable the dedicated proxy feature.
Flexible node deployment
Compared with RDS Basic Edition and RDS High-availability Edition, RDS Cluster Edition supports node topology management. After you create an RDS cluster, you can add or delete nodes based on your business requirements in a more cost-effective manner. For more information, see Add a node to an ApsaraDB RDS for MySQL cluster and Delete a node from an ApsaraDB RDS for MySQL cluster.
RDS Cluster Edition supports node-level monitoring. You can view the status of each node in an RDS cluster.
Cross-zone disaster recovery
In RDS High-availability Edition, one primary instance and one secondary instance are provisioned to ensure HA. In RDS Cluster Edition, all secondary nodes in an RDS cluster can be used for disaster recovery. We recommend that you deploy secondary nodes in different zones to achieve cross-zone disaster recovery.
Strong data consistency
If more than three nodes are deployed in an RDS cluster, the MGR mode can be used for the RDS cluster. MGR is developed based on Paxos, a distributed consensus protocol. Before a transaction is committed on the primary node, the system sends the data of the transaction to secondary nodes and ensures that a majority of secondary nodes receive the data. Compared with semi-synchronous replication and asynchronous replication, MGR ensures strong data consistency and higher data security.
More reliable secondary nodes
The Alibaba Cloud technical team uses cloud native technologies to perform in-depth optimizations on ApsaraDB RDS. This improves the reliability of the secondary nodes in RDS clusters.
The RDS high-availability system is reconstructed. This reduces the time that is required to detect faults on the secondary nodes from minute-granularity to second-granularity.
The single-digit second backup feature that is provided by Elastic Block Storage (EBS) is used. This reduces the time that is required to restore data from dozens of minutes to 1 minute and allows a secondary node to recover from faults within 10 minutes in 99% of use cases.
RDS Cluster Edition is suitable for large and medium-sized enterprises whose production databases need to process a large number of read requests during peak hours or need to perform intelligent data analysis. These enterprises include online retailers, automobile enterprises, education enterprises, and Enterprise Resource Planning (ERP) service providers.
Scenarios of RDS Cluster Edition for ApsaraDB RDS for MySQL
Configuration of an RDS cluster
Upgrade of an RDS instance to RDS Cluster Edition
Data migration to an RDS instance that runs RDS Cluster Edition
RDS Cluster Edition for ApsaraDB RDS for SQL Server
In RDS Cluster Edition, your database system consists of a primary RDS instance and a secondary RDS instance. These instances work in high availability (HA) mode. RDS Cluster Edition uses the Always On architecture of native SQL Server to implement compute-storage separation and allows you to create up to seven read-only RDS instances to implement read/write splitting and increase the read capability.
After you create read-only RDS instances for your RDS instance that runs RDS Cluster Edition, you can apply for a read-only routing endpoint to implement read/write splitting. By default, each read-only RDS instance is assigned an independent internal endpoint to isolate queries.
After you enable read/write splitting for a primary RDS instance that runs RDS Cluster Edition, you can specify read weights for the primary RDS instance, secondary RDS instance, and read-only RDS instances. After you enable the read-only routing endpoint, you must add the read-only routing endpoint and the endpoint of the primary RDS instance to your application. This way, your database system can forward write requests to the primary RDS instance and read requests to the read-only routing endpoint.
In RDS Cluster Edition, a primary RDS instance and a secondary RDS instance work in HA mode. If the primary RDS instance fails, your workloads are automatically switched over to the secondary RDS instance. This improves service stability.
Read-only RDS instances cannot ensure HA. If the primary RDS instance fails, your workloads cannot be automatically switched over to the read-only RDS instances. No disaster recovery RDS instances are provided for a read-only RDS instance. To ensure business availability and continuity, we recommend that you create at least two read-only RDS instances. If a read-only RDS instance fails, the other read-only RDS instance can continue to provide services.
When you purchase an RDS instance that runs RDS Cluster Edition, we recommend that you select multi-zone deployment to implement cross-zone disaster recovery.
RDS Cluster Edition is supported by RDS instances that run SQL Server 2022, SQL Server 2019, and SQL Server 2017. The following figure shows the architecture of RDS Cluster Edition.
Scalable read capabilities
You can create read-only RDS instances to linearly increase the read capability of your database system. The specifications of read-only RDS instances can be different from the specifications of the primary RDS instance. You can create read-only RDS instances that have higher specifications than the primary RDS instance to attain a strong read capability.
Read-only RDS instances can use general-purpose and dedicated instance types, which are cost-effective. You can create read-only RDS instances to offload read requests from the primary RDS instance. This helps optimize system configurations. Read-only RDS instances can have lower specifications than the primary RDS instance. You can create read-only RDS instances with low specifications to process read requests from background applications, such as intelligent analytics applications. This way, you can also reduce costs.
Read attribute configuration for a secondary instance
If you purchase an RDS instance that runs Cluster Edition, a primary RDS instance and a secondary RDS instance are provisioned. You can configure the read attribute for the secondary RDS instance. After you enable read/write splitting for the primary RDS instance that runs RDS Cluster Edition, the secondary RDS instance becomes readable and serves as a read-only RDS instance by default. This helps reduce the costs of a read-only RDS instance and cloud migration. For more information, see Configure the read attribute for a secondary RDS instance of a primary ApsaraDB RDS for SQL Server instance.
Use read-only RDS instances to offload read requests during peak hours.
For example, you can create read-only RDS instances that have high specifications to help new retail enterprises implement read/write splitting and traffic throttling and process read requests that grow several times during large-scale online promotional events, such as Double 11. This helps improve the system performance and response speed.
Confine analytics tasks to read-only RDS instances.
An enterprise can create an independent read-only RDS instance that uses intelligent technologies to analyze data. This reduces the probability of blocking on the primary RDS instance, increases concurrency, and mitigates interruptions to crucial workloads to ensure business stability.
Scenarios of RDS Cluster Edition for ApsaraDB RDS for SQL Server
Configuration of an RDS cluster
Upgrade of an RDS instance to RDS Cluster Edition