如何处理 MySQL 的主从同步延迟？

MySQL 主从同步延迟处理方案

主从同步延迟是指从库（Slave）应用主库（Master）二进制日志（binlog）的速度落后于主库生成日志的速度，导致从库数据与主库数据存在时间差的现象。

监控与定位：必须建立完善的监控体系，通过 SHOW SLAVE STATUS 命令查看 Seconds_Behind_Master 等关键指标，并结合 pt-heartbeat 等工具获取更精确的延迟时间，准确定位延迟发生的具体环节（IO线程拉取延迟或SQL线程应用延迟）。
优化硬件与配置：确保从库硬件配置（特别是磁盘I/O性能）不低于主库，调整 sync_binlog、innodb_flush_log_at_trx_commit 等参数在安全与性能间取得平衡，并设置 slave_parallel_workers 启用并行复制以提升应用效率。
架构与业务解耦：在业务架构层面，将对实时性要求极高的读写操作强制路由至主库，对可接受延迟的查询使用从库，并通过引入消息队列异步化写操作或使用缓存层来降低数据库直接压力。

同步延迟的本质矛盾是主库的并发写入能力与从库的串行/有限并行回放能力之间的不匹配。其核心发生逻辑拆解如下：

Step 1 - 日志生成：主库并发处理事务，并行写入 binlog。
Step 2 - 日志传输：从库 I/O 线程拉取 binlog 到本地（relay log），此处可能因网络产生延迟。
Step 3 - 日志应用：从库 SQL 线程（或并行工作线程）串行或按规则重放 relay log 中的事件。这是最常见的瓶颈点，因为：
- 早期版本（MySQL 5.6前）为单线程回放，无法利用多核。
- 即使启用并行复制（基于库、组提交、WRITESET），对于单库大事务或热点表的密集更新，仍可能形成排队。
- 从库上若有长时间运行的查询，可能会阻塞回放线程。

针对性解决方案推导：

半同步复制 vs. 异步复制：半同步复制（rpl_semi_sync_master_wait_point）通过确保事务在至少一个从库落地后才向客户端返回成功，牺牲部分写入延迟以增强数据一致性，但无法解决从库应用延迟。
组复制（MGR）vs. 传统复制：MGR 基于 Paxos 协议实现多主同步，数据强一致，从根本上避免了异步复制架构的延迟问题，但引入了更高的网络和性能开销。
并行复制方案演进：从 DATABASE（库级） 并行 -> LOGICAL_CLOCK（组提交） 并行 -> WRITESET（行哈希） 并行，并行粒度越来越细，对应用透明的优化程度越来越高。

Seconds_Behind_Master 为 0 就一定没有延迟吗？ 不一定。它仅表示 SQL 线程已处理完 I/O 线程已获取的最新日志。如果 I/O 线程因网络问题获取很慢，而 SQL 线程处理很快，该值可能为0，但实际从库数据远远落后。必须使用 pt-heartbeat 注入时间戳进行物理时间差判断。
如何紧急处理一个已经产生很大延迟的从库？ 首先，业务降级：将所有读流量切至主库。然后，根据情况选择：a) 若允许中断服务，重建从库（使用 mysqldump + GTID 或 clone plugin）往往比追延迟更快；b) 若需在线恢复，可尝试逐步增加 slave_parallel_workers 并监控追赶速度，同时停止从库上所有非必要查询。
GTID 复制对处理延迟有帮助吗？ GTID 本身不直接减少延迟，但它极大地简化了复制管理和故障恢复（无需找 binlog 位点），使得重建、切换等补救操作更迅速、准确，间接有助于从延迟故障中快速恢复。

MySQL 5.6：引入基于库（DATABASE）的并行复制，但效果取决于多库负载。
MySQL 5.7：引入基于组提交（LOGICAL_CLOCK）的并行复制（slave_parallel-type=LOGICAL_CLOCK），同一组提交的事务可以并行回放，显著提升单库多线程写入场景下的同步效率。
MySQL 8.0：默认使用基于 WRITESET 的并行复制（binlog_transaction_dependency_tracking=WRITESET），通过计算事务更新的行哈希决定依赖关系，并行度更高，且对业务无侵入。同时，Clone Plugin 的引入使得重建从库更加高效。

slave_parallel_workers：设置并行工作线程数。建议设置为 CPU 核心数的 2-4 倍。并非越大越好，需观察 Worker_Thread_State 避免线程间过度争抢。
binlog_group_commit_sync_delay（微秒级）：主库组提交等待时间，适当增加（如 1000）可让更多事务打包成一组，提升从库并行复制效率，但会轻微增加主库提交延迟。
relay_log_recovery=ON：强烈建议开启。确保从库异常重启后能从正确位置恢复复制，避免数据不一致。
大事务拆分临界点：经验上，单个事务产生超过 100MB 的 binlog 或执行时间超过 10秒，就应考虑拆分，因为它会阻塞后续所有事件的回放。