并行复制的两条路径
从库重放慢是延迟的主要来源，并行重放就是把单线程的 SQL 线程拆成多个 worker。能否并行取决于主库给出的依赖信息：WRITESET 按行级写集合判断两个事务互不冲突，判定粒度最细；LOGICAL_CLOCK 按提交组划分，认为同组提交的事务可以并行重放。MySQL 8.0 推荐源端用 WRITESET、从库用 LOGICAL_CLOCK 的组合。
基本信息
| 适用平台 | MySQL 5.7.6+ 支持 LOGICAL_CLOCK，8.0 支持 WRITESET |
|---|---|
| 源端参数 | binlog_transaction_dependency_tracking = WRITESET |
| 从库参数 | replica_parallel_type = LOGICAL_CLOCK、replica_parallel_workers |
| 默认并行度 | MySQL 8.0 中 replica_parallel_workers 默认为 4 |
| 顺序保证 | replica_preserve_commit_order = ON |
典型使用场景
- 从库延迟持续增长且已排除查询与硬件因素
- 批量导入或批量更新后从库追赶缓慢
- 新增从库首次追赶阶段希望尽快对齐
- 多表分片写入的库：表之间无冲突，天然适合并行重放
- 切换演练前确认并行配置与顺序保证均已就绪
推荐配置
推荐配置
# 源端（主库）
binlog_transaction_dependency_tracking = WRITESET
transaction_write_set_extraction = XXHASH64
# 从库端
replica_parallel_type = LOGICAL_CLOCK
replica_parallel_workers = 8
replica_preserve_commit_order = ON验证并行是否生效
验证并行是否生效
-- 查看各 worker 的当前状态
SELECT * FROM performance_schema.replication_applier_status_by_worker\G
-- 主库侧确认依赖信息类型
SHOW VARIABLES LIKE 'binlog_transaction_dependency_tracking';
-- 从库侧确认并行度与顺序保证
SHOW VARIABLES LIKE 'replica_parallel%';参数含义
| 参数 | 取值 | 作用 |
|---|---|---|
| WRITESET | 源端依赖跟踪方式 | 按行级写集合判定冲突，冲突越少并行度越高 |
| LOGICAL_CLOCK | 从库并行策略 | 同组提交的事务并行重放 |
| replica_parallel_workers | 正整数 | worker 数量，受 CPU 与磁盘随机 IO 限制 |
| preserve_commit_order | ON | 保证提交顺序与源端一致，切换安全的前提 |
| transaction_write_set_extraction | XXHASH64 | 写集合的哈希算法，配合 WRITESET 使用 |
并行度不是越大越好：当多表或单表热点导致冲突时，worker 会互相等待，加线程只是增加上下文切换，需要观察实际吞吐后定值。
修改 binlog_transaction_dependency_tracking 属于动态参数但会影响所有下游：变更前先确认所有从库版本都支持 WRITESET 依赖，避免出现无法重放的事务。
判断并行是否真的在起作用，看 performance_schema.replication_applier_status_by_worker：多个 worker 同时处于工作状态说明并行生效；若长期只有一个 worker 忙碌，通常是单表热点或大事务把并行度限制住了，此时调大 worker 数没有意义。