这是《MySQL 8.0 源码与内核实战》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 MySQL 复制基于 Binlog 传播和重放。主库记录逻辑变更，从库接收 relay log 并由 applier 执行。
23.1 链路
Primary
commit + write binlog
-> dump thread
-> network
-> replica io thread
-> relay log
-> sql/applier thread
-> apply transactions
23.2 Binlog 格式
| 格式 | 特点 |
|---|---|
| STATEMENT | 记录 SQL，依赖上下文 |
| ROW | 记录行变更，一致性较好 |
| MIXED | 按语句选择 |
8.0 默认 ROW。生产通常优先 ROW，可减少不确定性函数和顺序差异带来的数据漂移。
23.3 GTID
GTID = server_uuid:transaction_id
价值：
- 事务全局标识；
- 自动定位位点；
- failover 更简单；
- 重放可判断已执行；
- 多源复制更清晰。
查看：
SHOW MASTER STATUS;
SHOW REPLICA STATUS\G
SELECT @@gtid_executed;
23.4 线程模型
| 线程 | 职责 |
|---|---|
| Binlog dump | 主库发送事件 |
| Replica IO | 接收 relay log |
| SQL thread | 协调重放 |
| worker | 并行重放事务 |
并行复制参数：
| 参数 | 说明 |
|---|---|
replica_parallel_workers |
worker 数 |
replica_parallel_type |
并行粒度 |
binlog_transaction_dependency_tracking |
依赖来源 |
replica_preserve_commit_order |
提交顺序 |
23.5 一致性
异步复制可能丢失最新事务；半同步复制至少等待从库确认收到 binlog 或事务已提交，具体取决于配置和应答模式。
SHOW VARIABLES LIKE 'rpl_semi_sync_master%';
不同发行版参数名可能变化，需按当前版本确认。
23.6 延迟排查
SHOW REPLICA STATUS\G
SELECT * FROM performance_schema.replication_applier_status_by_worker;
| 延迟 | 排查 |
|---|---|
| IO 延迟 | 网络、binlog 发送、磁盘 |
| SQL 延迟 | 大事务、单线程、锁 |
| 应用侧 | 冲突、索引缺失 |
| 主库写入尖刺 | batch、DDL |
处理方向是拆小事务、优化重放 SQL、合理并行、控制大 DDL 并持续监控延迟。
23.7 源码入口
| 文件 | 职责 |
|---|---|
sql/rpl_binlog_sender.cc |
主库发送 |
sql/rpl_replica.cc |
从库线程 |
sql/rpl_handler.cc |
复制钩子 |
libbinlogevents/ |
事件定义 |
sql/log_event.cc |
事件解析 |
本章小结
复制核心是 binlog 产生、传输和重放。ROW 与 GTID 是现代生产的基础，延迟治理要区分 IO、SQL 和事务依赖，重点处理大事务、锁和并行度。
思考题
- ROW 和 STATEMENT 各有什么风险？
- GTID 如何帮助 failover？
- 大事务为什么造成复制延迟？
- 并行复制的依赖如何产生？
- 异步复制和半同步复制的差异是什么？