Replication basics

MySQL replication copies changes from a primary to one or more replicas via the binary log (binlog). Replicas apply events asynchronously by default — reads from replicas can be stale.

					-- On replica: lag signals
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source (or Seconds_Behind_Master on older versions)

-- Read/write split caveat
-- Write to primary; read from replica only when stale data is acceptable
				

Common topologies: single primary with read replicas; manual failover; managed failover with Orchestrator or cloud HA. GTID simplifies failover positioning. Row-based binlog reduces ambiguity versus statement-based replication for non-deterministic SQL.

On interviews: explain replication lag, why read-your-writes may fail on replicas, binlog role, and failover consistency risks (split brain, promoted replica lag).

Common pitfalls: routing critical reads to replicas without lag monitoring; assuming synchronous replication by default; failover without checking replication gap; long transactions ballooning binlog size.

The trade-off is read scale and availability versus eventual consistency and operational complexity during failover.

Checklist:

• Monitor replication lag and binlog growth.
• Route only stale-tolerant reads to replicas.
• Use GTID-aware failover procedures.
• Test promote/failover and app reconnect behavior.