Databases 6 min read

MySQL Master‑Slave Replication: Modes, Principles, and Implementation

This article explains MySQL master‑slave replication, covering its three modes (asynchronous, semi‑synchronous, and fully synchronous), the underlying binary‑log mechanism, key replication threads, configuration steps, and includes a promotional notice for an upcoming live career‑development session.

Mike Chen's Internet Architecture
Mike Chen's Internet Architecture
Mike Chen's Internet Architecture
MySQL Master‑Slave Replication: Modes, Principles, and Implementation

Mike Chen, an experienced internet architect, announces a live video session on career development scheduled for March 5 at 8 pm, urging readers to reserve a spot.

MySQL Master‑Slave Replication

MySQL master‑slave replication is a database replication technique where one server acts as the master (primary) and one or more servers act as slaves (replicas), keeping data consistent across nodes.

The master’s data changes are synchronized to the slaves.

MySQL Replication Modes

MySQL supports three replication modes: asynchronous, semi‑synchronous, and fully synchronous.

1. Asynchronous Replication

In the default asynchronous mode, the master does not wait for any slave acknowledgment before returning to the client, so data on slaves may lag behind the master.

2. Semi‑Synchronous Replication

In semi‑synchronous replication, the master waits for at least one slave to confirm receipt of the transaction before responding to the client, improving data safety while retaining better performance than full sync.

3. Fully Synchronous Replication

Fully synchronous replication waits for all slaves to acknowledge the transaction before the master returns, providing the highest consistency at the cost of performance.

Replication Principles

Replication relies on the master’s binary log (binlog) and the slave’s replication threads.

First, enable binary logging on the master:

[mysqld]
log-bin = /var/log/mysql/mysql-bin.log

Write operations on the master are recorded to the binlog, then slaves connect to the master, fetch the binlog, and apply the changes via three replication threads:

I/O Thread : Connects to the master, reads the binlog, and writes it to the relay log on the slave.

Log Dump Thread : Runs on the master to send binlog events to the slave.

SQL Thread : Reads the relay log on the slave, parses the events, and executes the corresponding SQL statements.

These threads work together to keep the slave synchronized with the master, achieving data consistency.

Finally, the author offers a free collection of over 300,000 words of original architecture material and a comprehensive Java interview question set, inviting readers to add him on WeChat to receive the resources.

asynchronousMySQLReplicationdatabasesbinary logSemi‑Synchronoussynchronous
Mike Chen's Internet Architecture
Written by

Mike Chen's Internet Architecture

Over ten years of BAT architecture experience, shared generously!

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.