Set a floor on how many read-only nodes the database proxy keeps available for read traffic, even when the primary node fails or replication falls behind.
How it works
In a cluster connected through a database proxy endpoint, a faulty or overloaded primary node normally blocks all read and write requests through that endpoint. The read-only nodes, however, can still serve reads independently. (In this context, nodes refer to the provisioned instances in your database system or nodes in your RDS cluster.) By setting a minimum number of reserved nodes, the database proxy keeps at least that many read-only nodes in the read traffic rotation during a failure—improving cluster availability without manual intervention.
The actual number of nodes reserved follows this formula:
min{Minimum number of reserved nodes, Number of normal read-only nodes whose read weights are not set to 0}
A normal read-only node is any read-only node in the Running state, regardless of its replication status.
Use cases
Primary node failure interrupts replication
When the primary node goes down, data replication to read-only nodes is interrupted. Without reserved nodes, the database proxy endpoint stops serving reads entirely. With a minimum reserved count configured, the proxy continues routing read requests to the reserved nodes.
Heavy writes push replication latency above the threshold
When a large volume of writes hits the primary node, replication latency on read-only nodes can exceed the configured threshold. At that point, load balancing stops and all reads are redirected to the primary node—risking an overload or suspension. With reserved nodes configured, those nodes absorb read traffic and prevent the primary from being overwhelmed.
Node retention policy
When the number of eligible read-only nodes drops below the configured minimum, the database proxy selects which nodes to retain using the following two-level priority.
Priority 1: By replication status
Nodes already receiving read requests are kept. Among the remaining nodes, those with replication latency above the threshold—but with replication still running—are preferred over nodes where replication has been interrupted. If the count still falls short after retaining those nodes, interrupted-replication nodes are added until the minimum is reached.
Priority 2: By read weight
When nodes share the same replication status, those with higher read weights are retained first.
After configuring the minimum number of reserved nodes, read requests may be routed to nodes whose replication latency exceeds the latency threshold. Nodes with a read weight of 0 are never included, regardless of their replication status.
Scenario reference tables
The following tables show how the retention policy applies in specific scenarios.
Nodes with different replication status
| Scenario | Min reserved nodes | Max latency threshold | RO1 (Replication latency) | RO2 (Replication latency) | RO3 (Replication latency) | Readable proxy | Readable node |
|---|---|---|---|---|---|---|---|
| 1 | 1 | -1 | -1 | -1 | -1 | Yes | RO1 |
| 2 | -1 | 50 | 60 | Yes | RO2 | ||
| 3 | 1 | 30 | 0 | 40 | 40 | Yes | RO1 |
| 4 | 40 | 50 | 60 | Yes | RO1 | ||
| 5 | -1 | -1 | -1 | Yes | RO1 | ||
| 6 | -1 | 50 | 60 | Yes | RO2 | ||
| 7 | 2 | 30 | 20 | 60 | 40 | Yes | RO1 and RO2 |
| 8 | 20 | -1 | 60 | Yes | RO1 and RO3 | ||
| 9 | 20 | -1 | -1 | Yes | RO1 and RO2 |
-1 indicates that replication is interrupted. 0 indicates no replication latency. A value greater than 0 indicates replication is delayed but not interrupted. RO refers to a read-only node.
Nodes with the same replication status but different read weights
| Scenario | Min reserved nodes | RO1 (Read weight) | RO2 (Read weight) | RO3 (Read weight) | Readable | Readable node |
|---|---|---|---|---|---|---|
| 10 | 2 | 0 | 20 | 0 | Yes | RO2 |
| 11 | 0 | 0 | 0 | No | None | |
| 12 | 0 | 20 | 20 | Yes | RO2 and RO3 |
0 indicates that read requests are not forwarded to the node. A value greater than 0 indicates that read requests are forwarded to the node.
Prerequisites
Before you begin, make sure that:
The database proxy feature is enabled. For details, see Enable the database proxy feature
The database proxy version is 2.9.5 or later
Configure the minimum number of reserved nodes
This feature is available in both read/write mode and read-only mode.
Log on to the ApsaraDB RDS console. In the top navigation bar, select the region where your RDS instance resides. Find the instance and click its ID.
In the left-side navigation pane, click Database Proxy.
In the Connection Information section, find the database proxy endpoint and click Modify Configuration in the Actions column.
In the dialog box, set the Minimum Instances parameter and click OK.
API reference
| Operation | Description |
|---|---|
| DescribeDBProxy | Queries the detailed database proxy settings of an RDS instance. |
| DescribeDBProxyEndpoint | Queries information about a database proxy endpoint. |
| ModifyDBProxyEndpoint | Modifies the connection settings for a database proxy endpoint. |