:Modify the latency threshold and read weights of ApsaraDB RDS for MySQL instances

This topic applies only to RDS instances that run in shared proxy mode. For more information about RDS instances that run in dedicated proxy mode, see What are dedicated proxies.

Procedure

1. Log on to the ApsaraDB for RDS console.
2. In the top navigation bar, select the region where the target RDS instance resides.
3. Find the target RDS instance and click its ID.
4. In the left-side navigation pane, click Database Connection or Database Proxy.
5. Click the Read/Write Splitting tab.
6. In the Basic Information of Read/Write Splitting section, click Configure Read/Write Splitting and configure parameters as prompted.

   Table 1. Read/write splitting parameters

   Parameter	Description
   Latency Threshold	The maximum latency that is allowed for data replication from the primary instance to its read-only instances. If the latency on a read-only instance exceeds the specified threshold, your database system stops routing read requests to the read-only instance. This applies even if the read-only instance has a high read weight. This mechanism prevents long-term data inconsistencies between the primary and read-only instances. Valid values: 0 to 7200. Unit: seconds. The read-only instances may replicate data from the primary instance at a certain latency due to SQL statement execution limits. We recommend that you set this parameter to a value that is greater than or equal to 30.
   Read Weight Distribution	The read weight of each instance in your database system. A higher read weight indicates more read requests to process. For example, the primary instance is attached with three read-only instances, and the read weights of the primary and read-only instances are 0, 100, 200, and 0, respectively. In this situation, the primary instance only processes write requests, the first two read-only instances process all of the read requests at the 1:2 ratio, and the third read-only instance does not process write or read requests. Automatic Distribution: Your database system assigns a read weight to each instance based on the instance specifications. After you create a read-only instance, your database system assigns a read weight to it and adds it to the read/write splitting link. For more information, see Rules of weight allocation by the system. Customized Distribution: You must manually assign a read weight to each instance. Valid values: 0 to 10000. After you create a read-only instance, its read weight defaults to 0. You must manually assign a non-zero read weight to the read-only instance. Note After you delete a read-only instance, its read weight is also removed, but the read weights of the other instances remain unchanged. You cannot assign a read weight to a read-only instance for which you have specified a replication latency. For more information, see Set the data replication latency of a read-only ApsaraDB RDS for MySQL instance.

7. Click OK.

(Optional) What to do next

• Verify the allocated read weights
• Use SQL Explorer to verify the effect of read/write splitting
• Monitor the read/write splitting performance of an RDS MySQL instance
• Verify the read/write splitting performance of an RDS MySQL instance

FAQ

• If the read weight of a read-only instance is 0, can I access the read-only instance by using the read/write splitting endpoint?

  No, you cannot access a read-only instance by using the read/write splitting endpoint if its read weight is 0. You can only access this read-only instance by using its internal or public endpoint. In most cases, this solution is used to make a read-only instance serve only a specific service.

• After I modify the read weights of my primary instance and its read-only instances, why cannot the new read weights take effect?

  The new read weights take effect only on new connections because the existing connections will not be terminated and re-established.

• The loads on my primary instance and its read-only instances do not comply with the specified read weights. Why?

  Possible reasons are as follows:

  • Requests contain transactions. All of the requests that contain transactions are routed to the primary instance. These transactions include those executed to read data.
  • Your database system is connected by using the endpoints of the primary and read-only instances. In such cases, your database system does not route requests to the primary and read-only instances based on the specified read weights. Make sure that your database system is connected only by using the read/write splitting endpoint.
• Why does a large number of read requests are routed to my primary instance even if the read weight of the primary instance is 0?

  Possible reasons are as follows:

  • The read requests contain transactions. All of the requests that contain transactions are routed to the primary instance. These transactions include those executed to read data.
  • All of the read-only instances with a non-zero read weight are unavailable, or the latencies on these instances exceed the specified threshold. In this situation, your database system stops routing read requests to these instances.

References

FAQ on read/write splitting

Related operations