Understanding MySQL Master‑Slave Replication: Principles, Modes, and Benefits
This article explains how MySQL master‑slave replication works, covering the binlog mechanism, the three replication steps, and the three reliability modes—asynchronous, semi‑synchronous, and fully synchronous—while highlighting its impact on read throughput, backup, and disaster recovery.
MySQL Master‑Slave Replication
MySQL master‑slave (Master–Slave) replication is an essential method for achieving high availability and read/write separation in database architectures.
It works by copying the transactions executed on the primary (master) server to one or more secondary (slave) servers, thereby increasing read throughput and providing backup and disaster‑recovery capabilities.
Replication Principle
The core of replication relies on the binary log (binlog) mechanism. The master records all data‑changing operations to binlog files. Slave servers connect to the master, read these binlog entries, and replay them so that their data state matches the master.
The process can be divided into three steps:
Master records the log : After a write operation, the master writes the change to the binlog.
Slave fetches the log : The slave’s I/O thread connects to the master, reads the binlog content, and writes it to a relay log.
Slave replays the log : The slave’s SQL thread reads the relay log and executes the same SQL statements locally, achieving synchronization.
MySQL Replication Modes
MySQL offers three reliability modes to suit different business needs.
Asynchronous replication : The master returns immediately after committing a transaction without waiting for the slave. This is the default mode, offering high performance but risking data loss if the master crashes.
Semi‑synchronous replication : After committing, the master waits for acknowledgment from at least one slave that it has received the binlog, reducing the risk of data loss and suitable for systems that require higher consistency.
Fully synchronous replication : The master must wait for acknowledgments from all slaves before completing a transaction, providing the highest data consistency at the cost of significant performance overhead, and is rarely used in production.
Understanding these mechanisms helps architects design robust, scalable MySQL deployments that balance performance, consistency, and fault tolerance.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Mike Chen's Internet Architecture
Over ten years of BAT architecture experience, shared generously!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.