How to Eliminate MySQL Master‑Slave Lag: Parallel Replication, Read‑Routing, and Redis Marking

Problem Overview

Many companies deploy MySQL master‑slave architectures, but reads issued immediately after a write may not find the newly written data because the master’s binlog has not yet been applied on the slave.

The root cause is that the master handles writes while the slave reads; the slave’s single‑threaded binlog replay can lag, especially under high write concurrency, causing the delay to accumulate over time.

Solution 1: Enable Parallel Replication

MySQL uses a single thread to apply binlog events on the slave by default (see the first diagram). Starting with MySQL 5.7, parallel replication is supported but disabled out of the box. To activate it, configure the following parameter: slave_parallel_workers = 8; It is recommended to set the number of workers to twice the number of CPU cores because the replication threads spend most of their time waiting for disk I/O rather than performing CPU‑intensive work, allowing better resource utilization.

Solution 2: Business‑Level Read Routing

If the environment cannot use parallel replication (e.g., MySQL 5.6) or if long transactions, sudden TPS spikes, or hardware imbalances cause additional delay, the article suggests analyzing the business’s sensitivity to replication lag and directing reads accordingly.

For latency‑sensitive operations—such as immediate login after registration or checking order status right after payment—the application should force reads from the master. For less‑time‑critical scenarios like historical order queries or product reviews, reads can be directed to the slave.

While this approach resolves the “cannot read recent data” issue, routing a large proportion of traffic to the master can diminish the benefits of read/write separation.

Solution 3: Redis Short‑Term Marking

The article proposes a Redis‑based short‑term marker to reduce master load. When data is written to the master, a Redis key is set with a brief TTL (e.g., two seconds). Subsequent reads check Redis: if the key exists, the query goes to the master; otherwise, it goes to the slave.

This method works well for high‑real‑time requirements (e.g., login after registration) while keeping most reads on the slave. However, it adds complexity and is somewhat intrusive.

Conclusion

Redis short‑term marking can solve master‑slave lag but introduces additional system complexity. In most cases, enabling MySQL 5.7+ parallel replication is the preferred solution because it is more transparent to the business logic and offers better overall performance.