Mastering MySQL Replication: Asynchronous, Semi‑Sync, and Full Sync Explained

MySQL Replication Overview

MySQL is a core component of large‑scale architectures, and its master‑slave replication is essential for achieving high availability, performance, and read/write separation.

The master records operations in the binary log (Binlog), and the slave replays these logs to synchronize data. This model supports read/write separation, disaster recovery, and high‑availability designs.

Asynchronous Replication

By default, MySQL uses asynchronous replication. After the master commits a transaction, it immediately returns success, while the slave asynchronously pulls and replays the Binlog.

Advantages: highest performance, no waiting on the master. Disadvantages: noticeable replication lag; master failure can cause data loss. Suitable scenarios: read‑heavy, write‑light workloads where some delay is acceptable.

Semi‑Synchronous Replication

Semi‑synchronous replication requires the master to wait until at least one slave acknowledges receipt of the Binlog before confirming the transaction.

Advantages: reduces risk of data loss. Disadvantages: slightly slower than asynchronous mode. Suitable scenarios: internet systems with moderate latency requirements.

Full Synchronous Replication

Full (write‑time) synchronous replication forces the master to wait for acknowledgments from all slaves before committing, ensuring complete data consistency.

Advantages: strong data consistency. Disadvantages: high performance cost, unsuitable for high‑concurrency scenarios. Suitable scenarios: financial‑grade applications requiring strict consistency, such as transaction systems.