This topic describes how to modify the latency threshold and read weights of a primary ApsaraDB RDS for MySQL instance and its read-only instances after you enable read/write splitting.
For more information, see the "Read/write splitting parameters" section.
- Log on to the ApsaraDB for RDS console.
- In the top navigation bar, select the region where the target RDS instance resides.
- Find the target RDS instance and click its ID.
- In the left-side navigation pane, click Database Connection or Database Proxy.
- Click the Read/Write Splitting tab.
- 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.
- 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 a replication delay for an RDS MySQL read-only instance.
- Click OK.
(Optional) What to do next
- 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.
|ModifyReadWriteSplittingConnection||Modifies the latency threshold and read weights of a primary ApsaraDB for RDS instance and its read-only instances.|