Master‑Slave Replication in MySQL is a one‑way replication setup where a primary database (master) copies its data changes to one or more secondary databases (slaves). All write operations happen on the master, while slaves maintain read‑only copies of the data and usually handle read queries only.

This pattern is widely used to scale read traffic, simplify backups, and support disaster‑recovery scenarios in MySQL‑based applications.

How Master‑Slave Replication Works

  • Write operations on the master:

    • Every change (INSERT, UPDATE, DELETE) is recorded in the binary log (binlog) on the master in the order it occurs.

  • Replication on the slave:

    • On the slave, an I/O thread connects to the master, reads the binary log, and stores the events in a relay log on the slave.

    • A SQL thread on the slave reads the relay log and applies the changes to its own tables, keeping the data in the same logical order as on the master.

  • One‑way flow:

    • Data flows strictly from master to slave; slaves are usually configured as read‑only for application traffic to avoid accidental writes.

With this setup, the slave becomes eventually consistent with the master, with a small replication lag that depends on system load and network conditions.

Why Use Master‑Slave Replication?

  • Read scaling:

    • Read‑heavy workloads can be directed to one or more slaves, reducing the load on the master and improving overall performance.

  • Backups without downtime:

    • You can perform backups on a slave instead of the master, so the live application is not slowed down by backup operations.

  • Disaster recovery and failover:

    • If the master fails, a healthy slave can be promoted to become the new master, helping maintain service continuity.

  • Separate reporting and analytics:

    • Heavy analytical or reporting queries can run on a slave without interfering with the transactional load on the master.

Common Setup Considerations

  • Binary log on the master:

    • The master must be configured to enable the binary log and to write events in an appropriate format (ROW, STATEMENT, or MIXED).

  • Replication user:

    • A dedicated MySQL user with the REPLICATION SLAVE privilege is created on the master so that the slave can connect and read the binary log.

  • Initial data synchronization:

    • The slave usually starts with a consistent snapshot of the master’s data (for example, using mysqldump or physical file copy) before replication is started.

  • Monitoring replication status:

    • Commands such as SHOW SLAVE STATUS are used to check if the slave is connected, catching up, and processing events without errors.

For beginners, master‑slave replication is like a main printer and several backup printers: all changes are sent to the main printer (master), and the backup printers (slaves) copy its output. If the main printer fails, one of the backups can take over and keep the system running.

Summary

Master‑Slave Replication in MySQL lets a primary database (the master) replicate data changes to one or more secondary databases (the slaves) using binary logs and relay logs. It is a simple, widely used pattern for improving read performance, simplifying backups, and enabling high‑availability and failover setups, while keeping all write operations centralized on a single master node.