In most cases, if data replication on a read-only node in a cluster fails because the primary node is faulty or overloaded, the cluster that is connected by using the database proxy endpoint can no longer process read or write requests. However, the read-only nodes in the cluster can still process read requests. In this topic, nodes are referred to as the provisioned instances in your database system or nodes in your RDS cluster. You can configure the minimum number of reserved nodes in the database proxy. If the primary node is faulty or overloaded, a specific number of nodes are reserved to process read requests. This improves the availability of your cluster.
Feature description
You can configure the minimum number of reserved nodes to retain a specific number of read-only nodes to process read requests in the event of an exception. For example, the primary node is faulty or data replication on a read-only node is interrupted. After you configure the minimum number of reserved nodes, a specific number of read-only nodes are reserved to process read requests. You can use the following formula to calculate the minimum number of the reserved read-only nodes: min{Minimum number of reserved nodes, Number of normal read-only nodes whose read weights are not set to 0}.
Normal read-only nodes refer to read-only nodes that are in the Running state. No limits are imposed on the replication status of the normal read-only nodes.
Scenarios
You can configure the minimum number of reserved nodes in the following scenarios:
Data replication on a read-only node is interrupted because the primary node is faulty.
In this case, you can configure the minimum number of reserved nodes to allow the database proxy endpoint to process read requests.
If a large amount of data is written to the primary node, the replication latency of the read-only nodes exceeds the latency threshold and load balancing cannot be implemented.
If the replication latency of the read-only nodes exceeds the latency threshold because a large amount of data is written to the primary node, all read requests are forwarded to the primary node. As a result, the primary node may be overloaded or suspended. If you configure the minimum number of reserved nodes, the reserved read-only nodes offload read requests from the primary node. This prevents the primary node from being suspended due to heavy CPU loads.
Node retention policy
If the number of read-only nodes to which read requests can be forwarded is fewer than the minimum number of reserved nodes that you specify, the system retains read-only nodes based on the following policies:
The read-only nodes to which read requests have been forwarded are still retained. In addition, the read-only nodes on which the replication latency is greater than the latency threshold and data replication is not interrupted are preferentially retained. If the number of these types of read-only nodes is still fewer than the minimum number of reserved nodes that you specify, the read-only nodes on which data replication is interrupted are retained to ensure that the number of reserved read-only nodes is the same as the minimum number of reserved nodes that you specify.
If the nodes meet the preceding priority requirements and have the same replication status, read-only nodes are retained by read weight. Read-only nodes with high read weights are preferentially retained.
After you configure the minimum number of reserved nodes, read requests can be forwarded to the nodes whose replication latency exceeds the latency threshold. Read requests are not forwarded to the nodes whose read weight is set to 0.
The following table helps you understand the node retention policy.
Number of reserved nodes with different replication status
Scenario
Minimum number of reserved nodes
Maximum latency threshold
RO1 (Replication latency)
RO2 (Replication latency)
RO3 (Replication latency)
Readable database 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
NoteA value of
-1indicates that replication is interrupted. A value of0indicates that no replication latency exists. A value greater than 0 indicates that the replication is delayed but the not interrupted.ROrefers to a read-only node.Number of nodes with the same replication status but different read weights
Scenario
Minimum number of 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
NoteA value of
0indicates that the read requests are not forwarded to the node. A value greater than 0 indicates that read requests are forwarded to the node.
Prerequisites
The database proxy feature is enabled. The database proxy version is 2.9.5 or later. For more information, see Enable the database proxy feature.
Usage notes
After you configure the minimum number of reserved nodes, traffic may be routed to the read-only nodes whose replication latency exceeds the latency threshold.
You can configure the minimum number of reserved nodes in read/write mode and read-only mode.
Procedure
Log on to the ApsaraDB RDS console and go to the Instances page. In the top navigation bar, select the region in which your RDS instance resides. Then, find the RDS instance and click the instance ID.
In the left-side navigation pane, click Database Proxy.
In the Connection Information section, find the database proxy endpoint that you want to modify and click Modify Configuration in the Actions column.
In the dialog box that appears, configure the Minimum Instances parameter and click OK.
Related operations
Operation | Description |
Queries information about a database proxy endpoint. | |
Modifies the connection settings for a database proxy endpoint. |