关键词主从延迟；并行复制，WRITESET；LOGICAL_CLOCK；从库调整，RPO

大家好，我是小耶。写这篇文章，是想把我踩过的坑整理出来帮你们一次性解决主从延迟问题。别再自己翻遍慢查询日志，改参数，重启大法了。其实，

一、回放慢的根源：瓶颈在SQL线程

你是否发现。在主库写入高峰时从库总是跟不上？这就是“主库拼命写，从库拼命回放”两条线跑速差的问题。说起来，主库 → binlog → IO线程拉取 → relay log → SQL线程重放 → 数据写入。大多数情况下瓶颈卡在最终一步——SQL线程重放。

痛点：即使硬件升级了也可能因为只有一个SQL线程导致延迟持续攀升。

解决思路：开启并行复制，让多条SQL线程同时处理 binlog 事务。

二、并行复制的四代演进：选对模式比调对参数更关键

第一代：基于Schema

• If 两个事务操作的是不同数据库，可以并行执行。
• slave_parallel_type = DATABASE slave_parallel_workers = N


第二代：LOGICAL_CLOCK

• The idea is “看同一组提交”，记录逻辑时钟。按理说，
• slave_parallel_type = LOGICAL_CLOCK slave_parallel_workers = N slave_preserve_commit_order = ON

• 痛点：若主库组提交效率低。逻辑时钟也有限制，

第三代：WRITESET

• 决定可否并行。按理说，
• slave_parallel_type = WRITESET slave_parallel_workers = N
• 痛点：需要足够多的事务才能真正利用写集。

第四代：WRITESET_SESSION

• Adds session-order constraint to avoid intra-session inconsistencies.
• slave_parallel_type = WRITESET_SESSION slave_parallel_workers = N
• 痛点：If session contains dependent statements。parallelism is limited.

关键选择的观点是，写集合还是逻辑时钟？

• 如果业务是单库多表且事务量大，推荐 WRITESET 或 WRITESET_SESSION。
• 如果业务分布在多数据库中。或者事务小且不易冲突，可以先试 LOGICAL_CLOCK。
• 别只调 worker 数量，一定要先选对 parallel_type！否则无论怎么大 worker 都无法突破瓶颈。 其实，

三、并行度调优：worker 数不是越大越好

CPU 核数	推荐 worker 数	说明
4 核	4‑8 保守起步	保证 CPU 余量
8 核	8‑16 通常最优区间	可利用 CPU 同步复用
16 核	16‑32 高配场景	注意锁竞争与上下文切换开销
32 核以上	不超过32 超过收益递减	过多 worker 会引入同步成本下降吞吐量

1. 先设 slave_parallel_workers=…​，,观察一周。* 若 CPU 使用率低于60% 而且 延迟还在上升 → 再加一点 worker。* 若 CPU 超过80% 或出现明显锁争用 → 减少 worker。说起来，

副作用： 开启 slave_preserve_commit_order=ON; 会略微降低并发度，但能防止数据不一致风险。说起来，生产环境建议保持 ON。

四、精细化参数调优 – 不仅仅是 worker 调整

参数名 & 推荐值/说明  )
binlogformat = ROW  — 支持高效写集和冲突检测 避免数据不一致 占用硬盘空间稍大 适合 OLTP 场景\'>详细原因 …​，
binloggroupcommitsync_delay = 100000  — 详细原因 …​，不过，

The table above shows just two key parameters as examples – you can add more rows as needed. If you need more details on each setting。feel free to ask!怎么说呢，

In addition to se parameters,ensure that your from‑server hardware is no weaker than your master. Many teams unknowingly use outdated machines for replicas。which introduces delays from day one.

五、业务侧与架构侧配套调整 – 治本之道！

- 拆分大事务：* 一个事务里更新了几十万行，即使 worker 再多也得等它跑完。将业务拆成小批次或使用批处理方式，可显著降低单个事务所带来的延迟。

- 精准读写分离路由：* 对实时性要求高的查询直接走主库。容忍秒级延迟的报表或历史查询则走从库。不过，

- 多维监控。不止 SecondsBehindMaster：*

• SLA 延迟阈值之外还要监控 binlog 应用差距。
• SLA 与 CPU 使用率和 IO 性能相结合，以便快速定位硬件瓶颈。- 从库 worker 活跃状态与错误日志。\t\t \t\t \t\t\t \t —\t \t\t}\t\t}\t\t}\t}\t}\t{\t}\t}
<\/ul>\r

- RPO 与 RTO 的平衡：* 在设计复制方案时要明确恢复点目标和恢复时间目标，以防灾难恢复期间产生不可接受的损失。

六、小结 – 把“追不上”变成“可预期”!说起来，

\r \r \r

\r
\r # 复制模式升级到 WRITESET 或 WRITESET_SESSION 最大化并行度\r

---

---

\r © 小耶技术团队 | All rights reserved <\/footer>

---

---