This topic introduces the read/write splitting feature of ApsaraDB RDS for SQL Server. This feature allows ApsaraDB RDS to distribute read requests to read-only RDS instances based on the read weights of these instances. This is implemented by using a read-only routing endpoint.

If your database system receives a large number of read requests but a small number of write requests, a single primary RDS instance may not be able to efficiently process the read requests. This may even interrupt your workloads. In this case, you can create one or more read-only RDS instances to offload read requests from the primary RDS instance. This allows you to scale the read capability of your database system. For more information, see Overview of read-only ApsaraDB RDS for SQL Server instances.

After read-only RDS instances are created, you can enable the read/write splitting feature. You must add the endpoint of the primary RDS instance and the read-only routing endpoint to your application. Then, ApsaraDB RDS routes write requests to the primary RDS instance and read requests to the read-only routing endpoint. The read-only routing endpoint distributes the read requests to read-only RDS instances based on the read weights of these instances. For more information about how to enable the read/write splitting feature, see Enable the read-only routing endpoint of an ApsaraDB RDS for SQL Server instance.

Note The read/write splitting feature works differently between ApsaraDB RDS for SQL Server and ApsaraDB RDS for MySQL.
  • ApsaraDB RDS for SQL Server: You must add the endpoint of the primary RDS instance and the read-only routing endpoint to your application to achieve read/write splitting.
  • ApsaraDB RDS for MySQL: You must add the read/write splitting endpoint to your application to achieve read/write splitting.

Differences between the read-only routing endpoint and the internal and public endpoints

After you enable the read/write splitting feature, a read-only routing endpoint is generated. You must add the read-only routing endpoint to your application. The read requests from your application are routed to the read-only routing endpoint and then are distributed to the read-only RDS instances based on the read weights of these instances.

If only the internal or public endpoint of the primary RDS instance is added to your application, all requests are routed to the primary RDS instance. To implement read/write splitting, you must add the endpoint of the primary RDS instance, the read-only routing endpoint, and the read weights of read-only RDS instances to your application.

Benefits

  • Easier maintenance by using a unified read-only routing endpoint

    You are provided with a unified read-only routing endpoint that can distribute read requests to read-only RDS instances. The read-only routing endpoint reduces maintenance costs.

    In addition, you can scale the read capability of your database system by creating read-only RDS instances. This way, you do not need to modify the configuration data on your application.

  • Higher performance by using a native RDS link

    If you build a proxy layer on the cloud, data must be parsed and forwarded by a number of components before the data reaches your database system. This increases the response latency. The read/write splitting feature that is provided by ApsaraDB RDS precludes the additional components, shortens the response latency, and increases the processing speed.

  • Ideal in various scenarios based on configurable read weights

    You can specify the read weights of read-only RDS instances.

  • Highly available with instance-level health checks

    The cluster management feature actively performs health checks on read-only RDS instances. If a read-only RDS instance unexpectedly exits or its data replication latency exceeds the specified threshold, ApsaraDB RDS stops routing read requests to the instance and redirects these read requests to other healthy instances. Instance-level health checks allow you to ensure service availability in the event of faults on a single read-only RDS instance. After the faulty read-only RDS instance is recovered, ApsaraDB RDS resumes routing read requests to the instance.

    Note We recommend that you create at least two read-only RDS instances to avoid single points of failure (SPOFs).
  • Free of charge

    The read-only routing endpoint is free of charge.

    Note You must pay for the read-only RDS instances that you use. The pay-as-you-go billing method is used. For more information, see Overview of read-only ApsaraDB RDS for SQL Server instances.