ApsaraDB RDS transmits binary logs between the primary and read-only instances in real time. Under normal conditions, reads from a read-only instance have no latency. However, MySQL's replication mechanism has a fundamental constraint: if binary logs take a long time to apply, data synchronization latency occurs. This constraint cannot be removed. To minimize synchronization latency, use a read-only instance whose specifications are equal to or higher than those of the primary instance.
How the latency threshold works
ApsaraDB RDS lets you set a latency threshold to protect read quality when replication falls behind:
-
If a read-only instance's latency exceeds the threshold, ApsaraDB RDS stops forwarding requests to that instance.
-
If all read-only instances exceed the threshold, ApsaraDB RDS routes all requests to the primary instance — even if the primary instance has a non-zero read weight configured.
For more information, see Overview of read-only ApsaraDB RDS for MySQL instances.
Force real-time reads to the primary instance
When read/write splitting is enabled, use the /*FORCE_MASTER*/ hint to route a specific SQL statement directly to the primary instance:
/*FORCE_MASTER*/ SELECT * FROM table_name;Use this hint for queries that must read the latest committed data immediately after a write — for example, reading a record right after inserting or updating it.