Database Master‑Slave Synchronization and Consistency Solutions

In high‑concurrency environments, read traffic far exceeds write traffic, making a single database instance unsuitable; therefore, read‑write separation is adopted by using a dedicated master for writes and one or more slaves for reads.

While this reduces load on the master, it introduces consistency problems because of network and processing latency, leading to possible divergence between master and slaves.

1. Half‑synchronous replication

MySQL’s default replication is asynchronous: the master returns a response to the client immediately after committing a transaction without waiting for the slave. Half‑synchronous replication (supported as a plugin since MySQL 5.5) makes the master wait until at least one slave has written the transaction to its relay log before acknowledging the client, improving data safety at the cost of added latency.

Key points of half‑sync replication:

The transaction must be written to the master’s binlog and acknowledged by a slave before the client receives a response.

Available as a plugin from MySQL 5.5 onward; requires separate installation.

Only guarantees that the binlog reaches at least one slave, not that the slave has applied it.

May reduce throughput and can block the master if a slave is down or the network is unstable.

Advantages: simple, uses native database features.

Disadvantages: increased write latency and reduced throughput.

2. Database middleware

All read/write requests pass through a middleware layer. Writes are routed to the master, reads to slaves. The middleware records keys written during a short synchronization window (e.g., 500 ms). If a read for a recently written key arrives, it is routed to the master to ensure freshness; otherwise it goes to a slave.

Typical middleware projects:

Canal – an open‑source Java project from Alibaba that parses binlog for incremental data subscription, primarily for MySQL.

Otter – another Alibaba open‑source system for distributed database synchronization, especially across data centers, built on top of Canal.

Differences: Otter embeds Canal and runs in the same JVM, providing customizable synchronization logic without generating a relay log.

Advantages: can guarantee strong consistency.

Disadvantages: higher operational cost and complexity.

3. Cache‑key recording method

When a key is written, it is stored in a cache with a short expiration (e.g., 500 ms). The write proceeds to the master. For reads, the cache is checked: if the key is present, the request is sent to the master to obtain the latest data; if not, it is sent to a slave.

Advantages: lower cost than full middleware.

Disadvantages: introduces an extra cache layer and extra read/write operations to maintain consistency.

Overall, these three approaches—half‑sync replication, middleware, and cache‑key recording—offer different trade‑offs between consistency, latency, and operational complexity for database master‑slave synchronization.