All Products
Search
Document Center

ApsaraDB RDS:Overview of read/write splitting

Last Updated:Jan 12, 2024

If your database system receives a small number of write requests but a large number of read requests, a single primary RDS instance may be overwhelmed by the read requests, and your workloads may be interrupted. To increase the read capability of your database system, you can create one or more read-only ApsaraDB RDS for SQL Server instances. This way, a large number of database read requests can be processed and the application throughput is increased.

Description

ApsaraDB RDS for SQL Server uses the Always On architecture of native SQL Server. In ApsaraDB RDS for SQL Server, physical replication is implemented to replicate a primary RDS instance and generate a read-only RDS instance. The data on the read-only RDS instance is the same as the data on the primary RDS instance. If the data on the primary RDS instance is updated, the updates are automatically synchronized to the read-only RDS instance.

You can enable the read-only routing endpoint and add the endpoint of the primary RDS instance and the read-only routing endpoint to your application to implement read/write splitting. This way, your database system forwards 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 the secondary nodes or read-only RDS instances based on the read weights of these nodes and instances. For more information, see Enable the read-only routing endpoint to implement read/write splitting.

Note
  • Read/write splitting is implemented in different ways in 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 implement read/write splitting.

    • ApsaraDB RDS for MySQL: You must add the read-only routing endpoint to your application to implement read/write splitting.

image

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

After you enable the read-only routing endpoint, you can add the read-only routing endpoint to your application. The read requests from your application are forwarded to the read-only routing endpoint and then are distributed to the involved secondary nodes or read-only RDS instances based on the read weights of these nodes and instances.

If only the internal or public endpoint of the primary RDS instance is added to your application, all requests are forwarded to the primary RDS instance.

To implement read/write splitting, you must add the endpoint of the primary RDS instance and the read-only routing endpoint to your application, and configure read weights for the read-only RDS instances that belong to the primary RDS instance.

Benefits

  • The read-only routing endpoint to simplify maintenance

    The read-only routing endpoint is provided and used to distribute read requests to read-only RDS instances, which reduces maintenance costs. You can create read-only RDS instances to increase the read capability of your database system without the need to modify the application configuration.

  • High-security link to improve performance

    If you build a proxy layer in the cloud to implement read/write splitting, data is parsed and forwarded by a number of components before the data reaches your database system. This increases the response latency. Read/write splitting is built on the existing high-security link and does not require any additional components. This greatly reduces the latency and improves the processing efficiency.

  • Configurable read weights to meet various requirements

    You can specify read weights for read-only RDS instances to meet the business requirements in different scenarios.

  • Instance-level health checks to improve service availability

    Read/write splitting proactively checks the health status of read-only RDS instances. If a read-only RDS instance fails or its data replication latency exceeds the specified threshold, the system stops forwarding read requests to the read-only RDS instance and redirects these read requests to other healthy read-only RDS instances. Instance-level health checks ensure service availability in the event of faults on a single read-only RDS instance. After the faulty read-only RDS instance recovers, the system resumes forwarding read requests to the read-only RDS instance.

    Note

    To mitigate the impacts of single points of failure (SPOFs), we recommend that you create at least two read-only RDS instances.

  • Free-of-charge read-only routing endpoint to reduce resource and maintenance costs

    The read-only routing endpoint is provided free of charge. You must pay for the read-only RDS instances based on the pay-as-you-go billing method.

Usage notes

For more information, see the Usage notes section in Create a read-only ApsaraDB RDS for SQL Server instance and Enable read/write splitting by enabling the read-only routing endpoint.

Billing rules

You are charged for the read-only RDS instances that you create based on the subscription or pay-as-you-go billing method. For more information about the fee for a subscription read-only RDS instance, visit the ApsaraDB RDS buy page. For more information about the fee for a pay-as-you-go read-only RDS instance, see Read-only ApsaraDB RDS instance types.

References