Replication streams changes from a source (master) to one or more replicas. The source records every committed change in its binary log (binlog); each replica's I/O thread copies that log and an SQL/applier thread replays it, so replicas converge to the same data.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (logs actual row images, safe default), STATEMENT, or MIXED.Point writes at the source and spread SELECTs across replicas. Read-heavy apps (most web apps) scale reads almost linearly by adding replicas, while the single source still handles all writes.
-- On a replica, watch how far behind it is:
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 2 <- replication lag
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
Because async replicas trail the source, a user who writes then immediately reads from a replica may not see their own change ("read-your-writes" violation). Route latency-sensitive or just-written reads to the source, or use semi-sync.
Replication is the standard first step to scale reads and to gain a warm standby for failover/backups. Its defining limitation — lag, and the single write bottleneck — shapes real designs: it explains why you sometimes read stale data and why write scaling eventually needs sharding, not just more replicas.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate