This topic provides answers to commonly asked questions about read/write splitting.

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

The new read weights take effect only on new connections because the existing connections are not re-established.

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

This issue may occur in the following scenarios:

  • Requests contain transactions. All of the requests that contain transactions are routed to the primary instance. These transactions include those that are executed to read data.
  • Your database system is connected by using the endpoints of the primary or read-only instances. In these 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 are a large number of read requests routed to my primary instance even if the read weight of the primary instance is 0?

This issue may occur in the following scenarios:

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

How does read/write splitting ensure data reading in a timely manner?

For more information, see How does read/write splitting ensure the timeliness of data reading?.

How do I set read weights by calling API operations?

For more information, see ModifyReadWriteSplittingConnection.

How do I select the network type for a read/write splitting endpoint?

If your application is deployed in the same VPC as the RDS instance, we recommend that you use the internal endpoint to ensure data security and communication efficiency. If your application is deployed on an on-premises client or in a different network from the RDS instance, we recommend that you use the public endpoint to establish connections. For more information about how to switch between network types, see Change the network type of the read/write splitting address for an RDS MySQL instance.

What is the difference between the read/write splitting endpoint and the internal and public endpoints of a primary instance?

After you enable read/write splitting, a read/write splitting endpoint is generated. If you add the endpoint to your application, all requests are routed to this endpoint, and then to the primary and read-only instances based on the request types and the read weights of these instances.

If the internal or public endpoint of the primary instance is added to your application, all requests are routed to the primary instance. In this case, you must add the endpoints and read weights of the primary and read-only instances to your application to implement read/write splitting.

Can I change a read/write splitting endpoint?

The read/write splitting endpoint cannot be manually changed. If you enable or disable read/write splitting multiple times, the endpoint remains unchanged, and you do not need to update the endpoint configurations for your application. This reduces overall maintenance costs.

If I create a read-only instance, will my primary instance be affected?

When you create a read-only instance, the system replicates data from a secondary instance. The primary instance is not affected.

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. You can set the read weight of a read-only instance to 0 if you want to use it for a specific service.