MySQL Binlog 组提交实现

1.背景

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

1.1. 提交写两份日志的性能问题

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

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

1.2. redo log/binlog 的原子性和一致性

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

// mysqld.cc, init_server_components
 if (total_ha_2pc > 1 || (1 == total_ha_2pc && opt_bin_log)) {
   if (opt_bin_log)
     // tc means transaction coordinator
     tc_log = &mysql_bin_log;
   else
     tc_log = &tc_log_mmap;
 }

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

• 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 已经刷盘，即使 InnoDB commit 还未完成，也要重新写入 commit 标志，完成提交。

解决完原子性的问题，还有一致性问题。事务binlog 提交的顺序应该和 redo log 保持一致，否则可能物理备份（不拷贝 binlog）丢数据的问题）。但是 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 的逐步优化，两阶段提交的逻辑优化为：

• Prepare 阶段基本不变，只是写 redolog 时并不刷盘。
• Commit 阶段按步骤做流水线批处理，将锁粒度进一步拆细。

Commit 阶段又拆为三个主要步骤：

• flush stage：按事务进入的顺序将 binlog 从 cache 写入文件（不刷盘），redo log 刷盘（多个事务 redo 合并刷盘）。
• sync stage：对 binlog 文件做 fsync 操作（多个事务的 binlog 合并刷盘）。
• commit stage：各个线程按顺序做 InnoDB commit 操作。

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

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

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

总结下来&#