MySQL Binlog 组提交实现

发布时间：2025-11-04 12:57:31 来源：技术快报 作者：IT科技类资讯

本文代码分析基于 MySQL 8.0.29

1.背景

MySQL 提交流程有两个问题需要解决：

为了保证事务的持久性和原子性，事务提交完成前，实现其日志（WAL）必须持久化。提交对于 MySQL 来说，实现需要保证事务提交前，提交redo log 落盘。实现虽然日志顺序写的提交性能，已经高于数据文件随机写的实现性能，但是提交如果每次事务提交，都需将 redo log 刷盘，实现效率较低。提交同时 MySQL 还要写 binlog，实现相当于每次事务提交需要两次 IO，提交很容易成为性能瓶颈。实现

为了解决上述性能问题，提交经过 MySQL 5.6/5.7/8.0 的不断优化，引入组提交技术和流水线技术。

原子性比较好解决，MySQL 利用一个内部 2PC 机制实现 redo log 和 binlog 的原子提交，其中2PC 的协调者由 binlog 承担。

)) {

)

;

;

内部两阶段提交的流程简单描述为：

Prepare 阶段 ：（1）InnoDB 将回滚段上的事务状态设置为 PREPARED；（2）将 redolog 写文件并刷盘；

Commit 阶段 ：（1）Binlog 写入文件；（2）binlog 刷盘；（3）InnoDB commit；

两阶段提交的 commit point 是 binlog 刷盘成功（因为此时两个日志都持久化成功了）。免费信息发布网Recovery 流程会比较 binlog xid 和 redo xid，判断事务是否达到 commit point，以此来决定提交还是回滚：

解决完原子性的问题，还有一致性问题。事务binlog 提交的顺序应该和 redo log 保持一致，否则可能物理备份（不拷贝 binlog）丢数据的问题（可以参考该文章给出的例子 https:// blog.51cto.com/u_151276 00/3998295 ）。但是 Xtrabackup 在这次提交后 https:// jira.percona.com/browse /PXB-1770 ，通过备份 binlog 避免了这种问题。

MySQL5.6以前，为保证 binlog 和 redo log 提交顺序一致，MySQL 使用了prepare_commit_mutex 锁，事务在两阶段提交流程中持有它，这样确实可以保证两份日志顺序一致，但它也会导致事务串行执行，效率很低。后来组提交和流水线提交的引入，不仅减少了 IO 次数，还提高了事务执行的并发度，网站模板减小了加锁的粒度。

2. 提交流水线

为解决上节提到的两个问题，经过 5.6/5.7/8.0 的逐步优化，两阶段提交的逻辑优化为：

每个 stage 一个队列，第一个进入该队列的线程成为 leader，后续进入的线程会阻塞直至完成提交。leader 线程会领导队列中的所有线程执行该 stage 的任务，并带领所有 follower 进入到下一个 stage 去执行，当遇到下一个 stage 为非空队列时，leader 会变成 follower 注册到此队列中。

而 redo log 刷盘从 Prepare 阶段移动到 flush stage，这样 leader 也可以将多个事务的 redo log 合并刷盘。同样 sync stage 的云南idc服务商 leader 可以将多个事务的 binlog 合并刷盘。

每一个 stage 都是加锁的，保证 binlog 与 redo log 写入顺序是一致的。

总结下来，这套优化主要带来了两个好处：

Commit 阶段流水化作业，stage 内批处理，stage 之间可以并发，大大提升了写的并发度，进而提高吞吐与资源利用率。

redo log / binlog 合并刷盘，大幅减少 IO 次数。

3. 代码实现

协调者的 Prepare 调用存储引擎的 ha_prepare_low 即可，下面这段注释说的很清楚，此时不持久化 InnoDB redo log。

) {

;

);

;

组提交的代码主要位于 MYSQL_BIN_LOG::ordered_commit

MySQL 8.0.29 后将原来 slave 并行回放过程抽象成新的 stage0（原来这个流程也是有的，只是没有抽象为 stage0），其工作是协调多个回放线程的回放顺序，让事务提交顺序与主库一致。以下代码只有备库回放会走到。

)) {

)) {

;

}

stage 转换函数

事务提交三个 stage 之间的转换，都用的是 MYSQL_BIN_LOG::change_stage 函数，其主要逻辑是调用了 Commit_stage_manager::enroll_for。该函数在 8.0.29 版本里，加了很多WL#7846 处理逻辑，帮助备库在不开 binlog，但是并行回放的情况下，依旧可以和主库保持相同的提交序，这一部分我会从下面的核心代码里删除，感兴趣的朋友可以看下WL#7846 。

enroll_for 主要做了以下几件事：

1.判断自己是不是入队的第一个，如果是则为 leader，否则为 follower，enroll_for 的返回值为 true 则为 leader。

2.释放上个阶段持有的锁，先入队新的 stage，再释放上一个 stage 的锁，保证事务执行的顺序在每个 stage 相同，保证事务的正确性。注意：BINLOG_FLUSH_STAGE 没有上一个阶段的锁，入参 stage_mutex 为 nullptr。

3.follower 会阻塞等待在 m_stage_cond_binlog 条件变量上。

4.Leader 持有本阶段的锁（enter_mutex）。

]],

,

,

) {

(

)) {

;

}

;

}

,

,

) {

);

);

);

());

);

) {

);

) {

);

}

);

;

}

;

) {

());

)

);

);

}

;

Stage 1 -- BINLOG_FLUSH_STAGE

事务 flush 到 binlog (不 sync) ，代码中的解释：

BINLOG_FLUSH_STAGE leader 的主要工作如下（代码依旧位于MYSQL_BIN_LOG::ordered_commit）

1.change_stage，进入 BINLOG_FLUSH_STAGE 状态。

2.如果发现 binlog 被关了，直接跳到（goto）commit stage。

（3,4,5 在 process_flush_stage_queue 完成）

3.拿到 flush queue 的 head，清空 flush queue，以便新的线程进入作为 leader。调用 ha_flush_logs(true) 批量刷 redo log。

4.依次调用 MYSQL_BIN_LOG::flush_thread_caches 将每个事务缓存在 binlog_cache_mngr 里的信息 flush 到 binlog（cache）。调用路径：

5.判断是否需要 rotate。

6.将 binlog 写到 binlog 文件（不 sync），flush_cache_to_file

,

)) {

);

}

())) {

);

;

;

}

);

) {

);

process_flush_stage_queue 执行 3-5 步，事务 redo 刷盘，将事务的信息写到 binary log

,

,

) {

);

) {

);;

}

)))

;

;

Stage 2 -- SYNC_STAGE

BINLOG_FLUSH_STAGE 阶段的 leader 带着一个链表进入 SYNC_STAGE 阶段，首先依旧调用 change_state 函数，可能成为该阶段的 leader，也可能成为 follower，因为此时 LOCK_sync 可能正在被做 sync 的线程持有。多个 flush queue 会因为等待锁而合并成一个 sync queue。

Sync 的后续流程：

1.判断本次要不要 sync

一个 SYNC_STAGE 的 leader 通过参数判断，本次是否需要 sync。sync_counter 变量代表进入 SYNC_STAGE 但是没有真正 sync 的 leader 的个数。当 MySQL 配置参数 sync_binlog 设置大于 1 时，并不是每个 leader 执行到这里都会 sync。

get_sync_period() 获得的值，即是 sync_binlog 参数的值。

因此，判断 sync_counter + 1 >= get_sync_period()，表示当前的 leader 可以 sync 了，那么该线程继续等一会儿，等待更多的线程进入 sync queue 在一起提交，具体等多久，由 opt_binlog_group_commit_sync_no_delay_count 和 opt_binlog_group_commit_sync_delay 决定。如果本 leader 不 sync，则不用等待。

注意，当 sync_binlog == 0 时，每个 leader 线程都要等待。当 sync_binlog == 1 时，同样每个 leader 线程都要等待，因为每个 leader 都要 sync。当 sync_binlog > 1 时，一部分 leader 线程就不用等待，接着执行，反正也不会 sync。

2.调用 sync_binlog_file 去 sync binlog。sync_binlog_file 中实现只有当 sync_period > 0 && ++sync_counter >= sync_period 时才真正 sync。

,

)) {

);

}

()))

(

,

);

(

);

) {

);

;

Stage 3 -- COMMIT_STAGE

依次将 redolog 中已经 prepare 的事务在引擎层提交，该阶段不用刷盘，因为 flush 阶段中的 redolog 刷盘已经足够保证数据库崩溃时的数据安全了。

COMMIT_STAGE 的主要工作包括：

1.达成多数派后，调用 ha_commit_low 提交，提交完成后还需减少 prepared XID counter

2.唤醒所有等待的 follower，完成提交。

)) {

,

)) {

);

}

(

);

)

);

);

);

);

;

{

)

);

)

);

}

相关文章