刚改的昵称，怎么又变回去了？

刚改完昵称，一刷新又变回旧的了。你的修改其实没丢，你只是读到了一台还没跟上的「从库」。这一期讲主从复制和读写分离。

1. 主从复制：赛场和转播

一台库（主库）的数据被复制到一台或多台库（从库）。⁴ 主库把所有改动记进二进制日志（binlog），普通的 SELECT 一般不记。⁵ 是从库自己去主库拉这些改动，然后照着重做一遍，而不是主库推过去。⁵

具体分三步，各由一个线程负责：²

1. 主库的 binlog dump 线程：从库连上来时，把 binlog 内容发过去。
2. 从库的 I/O（receiver）线程：向主库要更新，存成本地的中继日志（relay log）。
3. 从库的 SQL（applier）线程：读中继日志，把里面的事务执行一遍。开启并行复制时可以有多个 applier 同时干。

2. 为什么要复制

• 分担读：所有写入都必须在主库上，读可以分到一台或多台从库。⁴ 这种做法最适合读多写少的场景，大多数网站都是这样。⁶
• 备份：从库可以暂停复制，在从库上做备份不会影响主库。⁴
• 主库坏了能顶上：可以把一台从库切换成新的主库。⁷

注意，读写分离时从库一般设成只读（MySQL 需要开 read_only/super_read_only，复制本身不会自动禁写），不分担写的压力。⁸

3. 主从延迟

主从延迟（也叫复制延迟）：主库和从库之间总有一段可测量的延迟，同一时间在两边跑同一条查询，结果可能不同；从库的数据是「最终一致」的。³⁸ 官方文档都只说「measurable delay」，没有给出典型值，所以这里也不写具体多少秒。

在 MySQL 里可以用 SHOW REPLICA STATUS 看 Seconds_Behind_Source：它表示从库的 SQL 线程落后主库 binlog 的秒数，数字大或者一直在涨，说明从库跟不上了。⁹

4. 异步、半同步、全同步

• 异步（默认）：MySQL 复制默认是异步的。⁴ 主库不知道从库有没有、什么时候拿到了改动；主库要是崩了，它已经提交的事务可能还没传给任何从库，这时切到从库就会少数据。¹⁰ PostgreSQL 的文档也写了同样的风险：还没传出去的事务会丢。³
• 半同步：主库要等至少一台从库（数量由 rpl_semi_sync_source_wait_for_replica_count 设定，默认 1）收到改动、写进中继日志并刷盘，才告诉客户端提交成功。默认 AFTER_SYNC 模式是先等确认、再在存储引擎里提交；AFTER_COMMIT 是先提交、再等确认。这样确认成功时，数据至少在两个地方。代价是要等确认，比异步慢。注意：等确认超时（rpl_semi_sync_source_timeout）后，主库会自动退回异步复制，直到有从库跟上。¹⁰ 另外，MySQL 8.0.26 之前，半同步的插件和参数叫 rpl_semi_sync_master_* / rpl_semi_sync_slave_*；从 8.0.26 起提供改用 source / replica 新名字的版本（如 rpl_semi_sync_source_*）。¹¹
• 全同步：所有从库都提交了才算完成，可能会有很大延迟。¹⁰

半同步只要求从库「收到」，不要求从库「执行完」。¹⁰ 所以半同步下，刚写完马上去从库读，还是可能读到旧数据。

5. 刚写完就读：怎么不读到旧的

问题出在：用户写进主库，紧接着从一台还没跟上的从库读。¹² 常见几种办法：

1. 写完读主库：刚写完、或者关键数据，直接去主库读；没有足够新的从库时，也退回主库。代价是主库压力变大。¹²
2. 按会话粘滞：记下这个会话最后一次写入的时间，接下来一段时间的读都走主库或足够新的从库。¹²
3. 等事务执行到：写完记下这次事务的 GTID，去从库读之前先用 WAIT_FOR_EXECUTED_GTID_SET() 等从库执行到它。¹³ ProxySQL 也能自动做这件事。¹⁴
4. 中间件自带：新版 MySQL Router 有 wait_for_my_writes 选项，开启后只读查询会先等本会话最后一次写入，等不到就回主库读。¹⁵

6. 读写分离：谁来分

写都去主库，读可以去从库。⁴ 分流可以放在不同的地方：

• 中间件：MySQL Router 支持读写分离，会判断每条查询是读还是写，再发到对应的库。¹⁶ ProxySQL 用 hostgroup 区分主库组和从库组，按端口或规则路由。
• 云厂商：比如 Azure Database for MySQL 的 reader endpoint，把读连接分到多台从库（预览功能）。⁸
• 应用自己分：代码里开两个连接，写走主库，读走从库。¹²