What is read/write splitting of ApsaraDB RDS for PostgreSQL? - ApsaraDB RDS

If your database system receives a large number of read requests but a small number of write requests and the primary ApsaraDB RDS for PostgreSQL instance is overloaded due to the read requests, you can use read-only RDS instances together with read/write splitting of the database proxy feature for the database system. The database system can automatically forward the read and write requests by using database proxy endpoints. This maximizes the read performance of read-only RDS instances and reduces the loads on the primary RDS instance.

Overview

If your database system receives a large number of read requests and a small number of write requests, the primary RDS instance may fail to efficiently process read requests and your workloads may be interrupted. After you create read-only RDS instances, you can use read/write splitting of the database proxy feature to allow the system to automatically forward write requests to the primary RDS instance and read requests to the read-only RDS instances. This helps reduce the loads on the primary RDS instance. For more information, see What are database proxies?

Benefits of read/write splitting

Unified read/write splitting endpoint to facilitate maintenance
If you disable read/write splitting, you can perform read/write splitting only after you add the endpoints of the primary RDS instance and read-only RDS instances to your application.
If you enable read/write splitting, you need to only connect to a database proxy endpoint to process write requests and read requests that are automatically forwarded to the primary RDS instance and read-only RDS instances. This helps reduce maintenance costs.
You can also create read-only RDS instances to increase the read capability of your database system without the need to modify the configuration data on your application.
Native link to improve performance and reduce maintenance costs
If you build your own proxy layer in the cloud to implement read/write splitting, data must be parsed and forwarded by multiple components before the data reaches your database system. As a result, response latencies increase. Read/write splitting is embedded in the ApsaraDB RDS ecosystem to reduce response latencies, increase processing speeds, and reduce maintenance costs.
Instance-level health check to improve service availability
Read/write splitting automatically checks the health status of the primary RDS instance and its read-only RDS instances. If a read-only RDS instance unexpectedly goes down or its data replication latency exceeds the specified threshold, the system stops forwarding read requests to the read-only instance. The system redirects read requests that are destined for the faulty read-only RDS instance to healthy RDS instances in your database system. This ensures service availability in the event of faults on individual read-only RDS instances. 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.
Configurable read weights and thresholds to ensure suitability in various scenarios
You can specify the read weights of the primary RDS instance and read-only RDS instances. You can also specify the latency threshold for data replication to the read-only RDS instances.

Request forwarding types

Forwarding destination	Request type
Primary RDS instance	Requests that are used to execute INSERT, UPDATE, DELETE, and SELECT FOR UPDATE statements All requests that are used to perform DDL operations, such as the DDL operations that are performed to create databases or tables, delete databases or tables, and change schemas or permissions All requests that are encapsulated in transactions Requests that are used to call user-defined functions Requests that are used to run stored procedures Requests for multi-statements Note If you execute multi-statements or call stored procedures, all subsequent requests over the current connection are forwarded to the primary RDS instance. To perform read/write splitting again, you must close the current connection and establish a new connection. Requests that involve temporary tables Read and write requests for system tables Write operations that are stored in PreparedStatement objects
Primary RDS instance or read-only RDS instances	Requests used to execute SELECT statements that are not encapsulated in transactions Requests prior to the first write operation in the transaction after transaction splitting is enabled Read operations that are stored in PreparedStatement objects System functions, such as pg_sleep, that can be safely called on read-only RDS instances
Primary RDS instance and read-only RDS instances	All requests that are used to reconfigure system variables Parsing operations that are stored in PreparedStatement objects BEGIN, START, END, ROLLBACK, and COMMIT CANCEL

Procedure

For more information, see Enable the database proxy feature and Configure the connection settings for a database proxy endpoint.

Usage notes

For more information, see Usage notes of the database proxy feature.

FAQ

For more information, see FAQ about the database proxy feature.