ApsaraDB RDS:[New features/New specifications] The database proxy of ApsaraDB RDS for MySQL supports the configuration of the minimum number of reserved nodes

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}.

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:

1. 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.

2. 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.

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

  Note

  A value of -1 indicates that replication is interrupted. A value of 0 indicates that no replication latency exists. A value greater than 0 indicates that the replication is delayed but the not interrupted. RO refers 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

  Note

  A value of 0 indicates that the read requests are not forwarded to the node. A value greater than 0 indicates that read requests are forwarded to the node.