This topic introduces the read/write splitting function of ApsaraDB RDS for SQL Server. This function enables ApsaraDB RDS for SQL Server to distribute read requests to read-only instances by using a read/write routing endpoint.
If your primary instance needs to process a large number of read requests but only a small number of write requests, you can create one or more read-only instances to offload read requests from your primary instance. This allows you to ensure service stability. For more information, see Overview of ApsaraDB RDS for MySQL read-only instances.
After read-only instances are created, you can enable the cluster management function, and then configure the endpoint of the primary instance and the read-only routing endpoint in your application. The system distributes write requests to the primary instance and read requests to the read-only routing endpoint. The read-only routing endpoint then distributes the read requests to the read-only instances based on the specified read weights.
- ApsaraDB RDS for SQL Server: You must configure the endpoint of the primary instance and the read/write routing endpoint in your application to achieve read/write splitting.
- ApsaraDB RDS for MySQL: You must configure the read/write splitting endpoint in 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 function, a read-only routing endpoint is generated. You must configure the read-only routing endpoint in your application. The read requests from your application are sent to the read-only routing endpoint and then are distributed to the read-only instances of the primary instance based on the read weights of these read-only instances.
If only the internal or public endpoint of the primary instance is configured in your application, all requests are sent to the primary instance. To implement read/write splitting, you must add the internal or public endpoint of the primary instance, the read-only routing endpoint to your application and assign read weights to the read-only instances.
- Easier maintenance with a unified read-only routing endpoint
You are provided with a unified read-only routing endpoint that can route read requests to read-only instances. The read-only routing endpoint facilitates maintenance and reduces costs.
In addition, you can scale out the read capability of your database system by creating read-only instances. This relieves you from the need to modify the configuration data on your application.
- Improved performance with support for the high-security link
If you build a separate proxy layer on the cloud to implement read/write splitting, statements need to be parsed and forwarded by a number of components before they reach your database system. This increases response latency. The read/write splitting function is built on the existing high-security link and does not require additional components. This greatly reduces response latency and improves processing efficiency.
- Ideal in various use scenarios with configurable read weights
You can customize the read weights of read-only instances.
- Highly available with instance-level health check
The cluster management function performs health checks on read-only instances. If a read-only instance fails or its latency exceeds the specified threshold, the read-only routing endpoint stops routing read requests to the read-only instance and routes all of the received read requests to the remaining healthy read-only instances. This allows you to ensure service availability in the event of faults on a single read-only instance. After the faulty read-only instance is recovered, the read-only routing endpoint resumes routing read requests to it.Note To avoid single points of failure (SPOFs), we recommend that you create at least two read-only instances.
- Free of charge
The read-only routing endpoint is free of charge.Note You only need to pay for the read-only instances that you use.