ApsaraDB RDS:Cluster Edition

How it works

RDS Cluster Edition uses the native SQL Server Always On architecture with compute-storage separation. A cluster consists of the following components:

• Primary RDS instance: handles all write requests. When read/write splitting is not enabled, it also serves read requests.

• Secondary RDS instance: mirrors the primary for automatic failover. After you enable the read-only routing endpoint, the secondary becomes readable by default and participates in read load distribution.

• Read-only RDS instances (up to 7): receive read traffic routed through the read-only routing endpoint. Each read-only instance also has an independent internal endpoint for direct, isolated access.

Read/write splitting

After you create read-only instances and enable the read-only routing endpoint, add both endpoints to your application:

• Primary endpoint — route all write requests here.

• Read-only routing endpoint — route all read requests here. The endpoint distributes traffic across the secondary instance and read-only instances based on the read weights you configure for the primary RDS instance, secondary RDS instance, and read-only RDS instances.

Supported SQL Server versions: SQL Server 2017, SQL Server 2019, and SQL Server 2022.

Benefits

• Scalable read capability Add read-only instances to increase read throughput linearly. Read-only instance specifications are independent of the primary — create instances with higher specifications for demanding read workloads, or lower specifications for background tasks such as analytics.

• Cost-effective read scaling Read-only instances support general-purpose and dedicated instance types. Offloading read traffic from the primary lets you right-size the primary instance for writes, reducing overall cost.

• Reuse the secondary instance for reads When you enable the read-only routing endpoint on a Cluster Edition instance, the secondary instance becomes readable automatically. This provides a built-in read replica without provisioning an additional read-only instance, lowering the cost of both read scaling and cloud migration.

Use cases

• Handle traffic spikes with read-only instances For applications with heavy seasonal or promotional traffic, add high-specification read-only instances to absorb surges in read requests. Write traffic remains on the primary instance, keeping performance stable during peak periods.

• Isolate analytics workloads Run analytics or reporting queries on a dedicated read-only instance. This prevents analytical workloads from consuming resources on the primary instance, reduces blocking, and keeps transactional performance consistent.

Limitations

• Read-only instances do not provide HA. If the primary RDS instance fails, workloads cannot be automatically switched over to read-only instances. Create at least two read-only instances so that one can continue serving requests if the other fails.

• No disaster recovery instances for read-only instances. Read-only instances do not have standby replicas.

• Application must use two endpoints for read/write splitting. After enabling the read-only routing endpoint, configure your application to send writes to the primary endpoint and reads to the read-only routing endpoint.

Configure an RDS cluster

What's next

To create an RDS Cluster Edition instance, see Create an ApsaraDB RDS for SQL Server instance.