从库复制又延迟了？GreatSQL 8.4.4-5 让并行回放"不再堵车" ...

备库延迟，卡在哪一步？

主从复制、MGR 组复制里，备节点靠回放 relaylog 中的 binlog 事务来追平主库。可 binlog 是逻辑日志，备节点得把事务重新执行一遍，高并发一上来，复制延迟就冒头了。

现有的并行复制基于 write-set / logical clock 模型，用 last_committed 和 sequence_number 两个字段判断哪些事务能并行跑。规则很简单：

若某事务 last_committed = M、sequence_number = N 且 M < N，就得等所有 sequence_number ≤ M 的事务先跑完。

问题就出在"等"这个动作上——传统实现里，一旦碰到有依赖关系的事务，协调线程（coordinator）会直接卡住，连带后面的 binlog 读取和调度全被堵在门口。前面一个事务没就绪，后面一整队都别想动。

GreatSQL 的解法：让 worker 自己等，别拦着后面的车

GreatSQL 8.4.4-5 解决复制延迟的思路用一句话概括：

把"等待"从协调线程下沉到 worker 线程，调度和执行彻底解耦。

具体做了三件事：

• 协调线程不再阻塞：遇到有依赖的事务，协调线程照样往下读、往下派活，不再原地干等；
• 冲突事务交给 worker 自己等：给需要等待的事务打上 need_wait 标记，由领到活的 worker 线程执行 wait_for_last_committed_trx，自己等自己的前置事务；
• SIGNAL 精准唤醒：前置事务一完成，通过信号机制唤醒在等待的 worker，无缝接着跑。

这样一来，协调线程始终保持"流水线"状态，不会因为个别事务的依赖关系而整体停摆。

怎么开启？一个参数搞定

优化由参数 replica_parallel_wait_mode 控制：

• WAIT_ON_SQL_THREAD：旧行为模式，默认值，等待逻辑在协调线程；
• WAIT_ON_WORKER_THREAD：新行为模式，推荐值，等待逻辑下沉到 worker。

想启用新机制，把它调成 WAIT_ON_WORKER_THREAD 即可。

收益：并行度更高，延迟更低

把等待逻辑挪到 worker 之后，效果直接体现在几个方面：

• 备节点并行回放并行度提升，能同时跑的事务更多；
• 调度阻塞链路缩短，协调线程不再成为瓶颈；
• 整体吞吐上升、复制延迟下降，高可用集群的稳定性更有保障。

一句话总结：GreatSQL 8.4.4-5 通过将等待逻辑从协调线程下沉至 worker，实现了并行复制中调度与执行的解耦，从根子上化解了"一个事务卡住、整条链路停摆"的老问题，让备库回放跑得更顺、追得更快。

特性详情见 GreatSQL 8.4.4-5 官方文档：https://greatsql.cn/docs/8.4.4-5/5-enhance/5-1-highperf-parallel-replica.html