并行复制的提交顺序保护是什么
开启并行复制后，多个 applier 线程会并发重放事务。replica_preserve_commit_order 保证从库的提交顺序与源端一致：这是「从库随时可以被提升为新主」的前提，因为顺序一旦错乱，故障切换后新主上的数据状态就不可信。MySQL 8.0 中该参数默认即为 ON，同时也依赖 LOGICAL_CLOCK 与并行 worker 才能发挥作用。
基本信息
| 适用版本 | MySQL 5.7（slave_preserve_commit_order）/ 8.0（replica_preserve_commit_order） |
|---|---|
| 默认值 | MySQL 8.0 默认 ON；并行复制需先开启 |
| 依赖项 | replica_parallel_type = LOGICAL_CLOCK、replica_parallel_workers > 0 |
| ON 的效果 | 按源端顺序提交，从库状态可随时提升为主 |
| OFF 的风险 | 吞吐略升，但故障时可能出现部分事务可见的乱序状态 |
| 查看命令 | SHOW VARIABLES LIKE 'replica_preserve_commit_order' |
典型使用场景
- 开启并行复制以缩短延迟时，确认顺序保护仍为 ON
- 切换演练前的状态核查项，保证从库数据可信
- 升级 5.7 到 8.0 后核对参数默认值变化
- 排查切换后数据异常：先确认从库是否曾关闭顺序保护
- 压测评估并行度：在保证顺序的前提下逐步调大 worker 数
查看与权衡
查看与权衡
-- 确认顺序保护与并行度配置
SHOW VARIABLES LIKE 'replica_preserve_commit_order';
SHOW VARIABLES LIKE 'replica_parallel_workers';
SHOW VARIABLES LIKE 'replica_parallel_type';
-- 观察并行复制实际效果
SHOW REPLICA STATUS\G
-- 关注：Replica_SQL_Running_State、Seconds_Behind_Source、Exec_Source_Log_Pos取值与影响
| 取值 | 提交行为 | 适用判断 |
|---|---|---|
| ON（8.0 默认） | 提交顺序与源端一致，并行度受组提交窗口影响 | 生产默认保持，切换可信 |
| OFF | 吞吐略高，可能出现乱序可见 | 仅在有专项评估与备份兜底时使用 |
| 部分节点 OFF | 新旧主行为不一致 | 故障处理更复杂，应统一配置 |
顺序保护会带来一定并行度损失：并行 worker 必须等前任事务提交才能提交，因此并行度取决于源端组提交的并发窗口。提升并行度更有效的做法是让源端产生更多可并发的事务，而不是关掉顺序保护。
为压低延迟关闭顺序保护属于用正确性换性能：平时看不出问题，只有在故障切换时才会暴露数据状态不一致，此时既没有时间比对，也没有可信基准，处理成本极高。