ApsaraDB RDS ensures real-time transmission of binary logs between the primary instance and read-only instances. Under normal conditions, reads from read-only instances return current data. However, MySQL replication has an inherent limit: if binary logs take too long to apply, replication lag accumulates and the read-only instance falls behind. This limit cannot be eliminated at the database engine level.
To minimize synchronization latency when you apply the binary logs, use read-only instances with specifications equal to or higher than the primary instance.
How the latency threshold works
ApsaraDB RDS lets you configure a latency threshold for read/write splitting. When a read-only instance exceeds this threshold:
ApsaraDB RDS stops routing read requests to that instance.
If all read-only instances exceed the threshold, ApsaraDB RDS routes all requests to the primary instance — regardless of whether a non-zero read weight is set for the primary instance.
This behavior protects your application from reading stale data when replication falls behind.
When to force reads to the primary instance
For queries that require real-time data, add the /*FORCE_MASTER*/ hint to route them directly to the primary instance, bypassing the read/write splitting proxy:
/*FORCE_MASTER*/ SELECT * FROM table_name;What's next
Modify the latency threshold and weights of read requests
Enable the proxy terminal feature for an ApsaraDB RDS for MySQL instance