MySQL 主从复制（master–replica replication）是如何工作的？它如何帮助读扩展？

Question

IT Interview Practice · Accepted Answer

复制把更改从一个**源库（source / master）**流式传输到一个或多个**副本（replica）**。源库把每一次已提交的更改记录到它的**二进制日志（binlog）**；每个副本的 I/O 线程复制这份日志，SQL/回放线程再重放它，于是副本收敛到相同的数据。 ## 流程 ``` 写入 app ---------> [ 源库 ] --- binlog ---> [ 副本 1 ] <-- 读取 | [ 副本 2 ] <-- 读取 +---------- binlog ---> [ 副本 3 ] <-- 读取 ``` - **格式** — `ROW`（记录实际的行镜像，安全的默认值）、`STATEMENT` 或 `MIXED`。 - **异步（默认）** — 源库无需等待副本即可提交：快，但副本可能滞后。 - **半同步（Semi-sync）** — 源库至少等待一个副本确认，用一点延迟换取持久性。 ## 读扩展把写入指向源库，把 `SELECT` 分散到各副本上。读密集的应用（大多数 Web 应用）通过增加副本几乎能线性地扩展读取，而单一源库仍处理所有写入。 ```sql -- 在副本上查看它落后多少： SHOW REPLICA STATUS\G -- Seconds_Behind_Source: 2 <- 复制延迟 -- Replica_IO_Running: Yes -- Replica_SQL_Running: Yes ``` ## 隐患：复制延迟由于异步副本落后于源库，一个先写后立即从副本读取的用户可能看不到自己刚做的更改（违反"read-your-writes"）。把对延迟敏感或刚写入的读取路由到源库，或使用半同步。 ## 为什么这很重要复制是扩展读取、以及获得用于故障转移/备份的热备节点的标准第一步。它标志性的局限 —— 延迟，以及单一写入瓶颈 —— 塑造了真实的设计：它解释了为什么你有时会读到过期数据，以及为什么写扩展最终需要分片（sharding），而不仅仅是增加更多副本。

流程

相关问题

读扩展

隐患：复制延迟

为什么这很重要