主从复制：异步、半同步、GTID 与并行回放

SHOW SLAVE STATUS 里 Seconds_Behind_Master: 0 却明明落后几分钟——这不是显示 bug，而是 SBM 度量的是 SQL 线程回放相对主库 binlog 时间戳的差，主库空闲或大事务边界下会失真。主从延迟的真正来源在 单线程 SQL 回放、大事务 binlog 单条事件、从库 IO 能力 与 第 12 篇 主库组提交/fsync 节奏。

本文基于 MySQL 8.0.36 复制架构，对照 PG 流复制。

一、复制拓扑与线程模型

经典一主一从（异步）：

flowchart LR
  M[Primary mysqld] -->|binlog dump| D[Dump connection]
  D --> I[Replica IO thread]
  I --> R[relay log]
  R --> S[SQL thread]
  S --> INN[InnoDB apply]

源码线索：sql/rpl_binlog_sender.cc（发送）、sql/rpl_io_monitor.cc、sql/rpl_rli.cc（relay log info）。

二、binlog 格式与行复制

binlog_row_image：FULL（默认）、MINIMAL、NOBLOB——影响带宽与闪回粒度。大宽表 UPDATE 产生大行事件，单事务一条 event 可拖垮 SQL 线程。

三、GTID

Global Transaction Identifier：server_uuid:transaction_id。主库提交时写 Gtid_log_event；从库 gtid_executed 集合跟踪已应用事务。

-- 需本地验证
SHOW MASTER STATUS;
SHOW GLOBAL VARIABLES LIKE 'gtid_mode';
SELECT * FROM mysql.gtid_executed LIMIT 5;

GTID 自动定位：CHANGE MASTER TO MASTER_AUTO_POSITION=1 免 file+pos。Failover 时禁止随意 RESET MASTER（第 19 篇）。

源码：sql/rpl_gtid.cc、sql/rpl_gtid_state.cc。

四、并行复制（MTS）

8.0 常用 slave_parallel_workers > 0，slave_parallel_type：

transaction_write_set_extraction=XXHASH64 为主库提取写集合。外键跨表、触发器、DDL 可能迫使串行。

五、半同步复制

半同步插件（rpl_semi_sync_master）在 主库 binlog 已写入从库 relay log（或收到 ack，取决于 rpl_semi_sync_master_wait_point）后才返回客户端 commit 成功。

超时后降级为异步（rpl_semi_sync_master_timeout）——降级事件应告警：RPO 从「至少一台从库收到」退化为异步。

六、Seconds_Behind_Master 陷阱

SBM 计算（简化）：SQL 线程当前回放事件时间戳 vs 主库当前时间。失真场景：

• 主库无新写入：SBM 趋近 0 即使 relay 仍积压
• 大事务：单 event 回放久，SBM 跳变
• MTS：显示的是 coordinator 视角

更可靠：performance_schema.replication_applier_status_by_worker 的 LAST_APPLIED_TRANSACTION 与主库 COUNT_TRANSACTIONS_IN_QUEUE（8.0）对比；或 mysql.slave_relay_log_info 位点差。

七、延迟诊断清单

-- 需本地验证：从库
SHOW REPLICA STATUS\G
-- 关注 Relay_Log_Space, Retrieved_Gtid_Set, Executed_Gtid_Set

SELECT * FROM performance_schema.replication_connection_status\G
SELECT * FROM performance_schema.replication_applier_status_by_worker\G

八、与 InnoDB 的交界

SQL 线程回放 ROW 事件时仍走 完整 DML 路径：undo、redo、二级索引、gap lock（若语句级需要）。从库 额外 承担 主库已做过的 IO——只读从库并非「无写入」：relay 写入、数据页修改、二级索引维护均消耗 IO。

长事务在从库回放时持有锁的时间与主库不等价（无客户端等待），但会阻塞后续并行 worker。

九、实验（需本地验证）

9.1 构造回放延迟

-- 主库大事务
BEGIN;
-- 批量 UPDATE 百万行（测试表）
COMMIT;
-- 从库观察 Relay_Log_Space 与 applier worker 状态

9.2 半同步降级

-- 主库开启 semi-sync，从库 stop replica;
-- 主库持续写入直至 rpl_semi_sync_master_status 显示 OFF
-- 记录等待超时与错误日志（测试环境）

十、工程坑点

用 SBM=0 当 SLA。应监控 位点差 与 应用读从库的实际陈旧。

MTS 开太高超过 CPU。worker 争用 InnoDB latch 可能不如适度并行。

从库 read_only 不挡 SUPER 写入。运维误写破坏一致性。

双主（环形）无冲突检测。GTID 不能替代应用层去重。

十一、关键要点（正文）

1. 复制链路：Dump → IO → relay → SQL → InnoDB。
2. GTID 简化 failover，但 RESET MASTER 有边界。
3. 半同步 缩短 RPO 窗口，超时会 静默降级。
4. SBM 不可靠；用 PFS 与 GTID 集合对比。
5. 并行复制 依赖写集合与 schema 约束，DDL 常串行。

十一、PG 对照

PG 第 18 篇 的 Slot 溢出与 MySQL relay log 堆积 同属「下游消费慢 → 上游存储压力」类故障，排查都先看 接收端进度。

上一篇：Binlog 与两阶段提交

下一篇：Optimizer 与 Handler

参考资料

源码（MySQL 8.0.36）

• storage/innobase/ — 引擎实现
• sql/binlog.cc, sql/handler.cc — Server 层交界

官方文档

• MySQL 8.0 Reference Manual, InnoDB / Replication / Backup

相关文章

• 系列索引
• PostgreSQL 内核系列