一 、故障描述

某客户反馈，在 2024/4/7 早上检查某 MySQL 数据库的主从复制架构数据同步时，发现同步延迟已经接近两天。在下图从库状态列表中，可以看到 Seconds_Behind_Master 指标值为 167782 秒，折合 46.6 小时，同步延迟已经非常高了，需要紧急排查处理：

二 、根因分析

1 、登录从库，通过 show slave status 查看，发现处于“ Waiting for preceding transaction to commit ”，表示当前事务无法和正在回放的事务并发回放出现的等待，且通过以下两步进一步证明了当前问题

1.1 、通过 show processlist 查看，检查从节点的 I/O 线程、 SQL 线程。由于开启并行复制， SQL 线程会派生出 coordinator 和 worker 子线程，并观察每个线程的状态。

1.2 、通过 select * from information_schema.innodb_trx; 查看，确实发现持有锁的事务一直存在，导致 SQL 重放线程 hang ，延迟不断扩大。

   2 、从库查看 slave_preserve_commit_order 参数，事务重放顺序要求跟主库保持一致特性确实已开启。

show variables like 'slave_preserve_commit_order';

或者

select @@slave_preserve_commit_order;

3 、查看 MySQL 版本号为： 8.0.27

\s

或者

status

4 、 MySQL 从库已开启多线程复制 slave_parallel_workers

show variables like 'slave_parallel_workers';

或者

select @@slave_parallel_workers;

排查至此，可能有经验的朋友，估计很快能够想到造成该问题的原因。确实，用户的这个主从复制同步场景，命中了 MySQL BUG ， Bug 号为 #103636 ，这是 多线程并发下的一个问题且和参数slave_preserve_commit_order 有关，并且无法自动解锁，因为已经无法唤醒等待的 worker 线程。

如果初次碰到的朋友想要深究，建议可以从 slave_preserve_commit_order 特性触发，找到对应的源码和函数，解读源码的逻辑，并比较该参数值 ON和OFF的逻辑差异，并尝试复现此问题。如果能成功复现该问题，那边该问题所关联的知识点就吃的比较透彻了。

三 、解决方案

基于目前从数据库已经锁死且 hang 住的情况下，单独杀 slave 线程操作也会 hang ，建议重启数据库服务以恢复主从数据同步。后续为了尽可能避免触发该 bug ，建议禁用 slave_preserve_commit_order 特性。

1 、禁用 slave_preserve_commit_order 参数

2 、或者升级到 MySQL8.0.33