mysql组提交

Posted 2020-12-17 卷毛狒狒

当mysql开启binlog日志时，会存在一个内部XA的问题：事务在存储引擎层redo log的写入和binlog的写入一致性问题。

 

mysql通过两阶段提交很好的解决了redo log和binlog一致性问题：

第一阶段：innodb prepare, 持有prepare_commit_mutex,redo log持久化到磁盘(flush/sync redolog)，并将回滚段设置为prepare状态。

第二阶段：分为两步。

　　a. flush/sync binlog

　　b. commit(写入commit标记，释放prepare_commit_mutex，并释放回滚段)

 

事务的崩溃恢复过程如下：

1. 事务恢复时，扫描最后一个binlog，提取出其中的xid

2. xid也会写到redo中，重做检查点后的所有事务，包括未提交的事务和已回滚的事务，读取事务的undo段信息，搜集处于prepare阶段的事务链表，将redo中prepared状态的xid与binlog中的xid做比较，如果在binlog中存在，则提交；否则回滚。

 

为什么只扫描最后一个binlog?

因为binlog rotate的binlog文件中对应的事务一定是已经提交的

 

Group Commit:

上面的整个过程，通过持有 prepare_commit_mutex来保证redolog的写入和binlog的写入完全一致，会导致group commit无法生效。

在mysql56中，同时支持了redolog 和 binlog的组提交，其提交流程如下：

 

第一阶段: innodb prepare(Redo Group Commit)

在innodb中，每条redolog都有自己的LSN，这是一个单调递增的值。每个事务的更新操作都会包含一条或者多条redo log, 各个事务在将redo log写入 log_sys_buffer(通过log_sys mutex保护)时，都会获取当前事务最大的LSN。那么假设三个事务 tx1, tx2, tx3的最大LSN分别为 LSN1 < LSN2 < LSN3时，他们同时进行提交，如果tx3获取到了 log_mutex, 那么他会将小于LSN3之前的redo log一起落盘，这样 tx1, tx2不用再次请求磁盘io。同时，如果存在tx0的LSN0 < LSN3，LSN0也会落盘，即使tx0还没有提交。

1. 获取 log mutex

2. 如果 flushed_to_disk_lsn >= lsn, 表示日志已经被刷盘，跳转 5

3. 如果 current_flush_lsn >= lsn, 表示日志正在刷盘中，跳转 5 后进入等待状态

4. 将小于 lsn 的日志刷盘 (flush and sync)

5. 退出 log_mutex

 

第二阶段: Binlog Group Commit的基本思想是引入队列机制，保证 innodb commit 的顺序与 binlog落盘的顺序一致，并将事务分组，组内的 binlog刷盘动作交给一个事务进行，实现组提交的目的。队列中的第一个事务称为 leader, 其他事务称为 follower。所有的事情交给 leader 去做。： flush stage, sync stage, commit stage

Flush Stage:

将每个事务的 binlog 写入内存

1. 持有 Lock_log mutex [leader持有，follwer等待]

2. 获取队列中的一组 binlog(队列中的所有事务)

3. 将 binlog buffer 到 I/O cache

4. 通知 dump线程 dump binlog [sync_binlog != 1]

 

Sync Stage:

将内存中的二进制日志刷新到磁盘， 若队列中有多个事务，那么仅一次 fsync 操作就完成了二进制日志的写入，这就是 BLGC。

1. 释放 Lock_log mutex, 持有 Lock_sync mutex[leader持有，follower等待]

2. 将一组 binlog 落盘(sync操作，最耗时，假设 sync_binlog 为 1)

3. 通知 dump线程 dump binlog [sync_binlog = 1]

 

Commit Stage:

leader根据顺序调用存储引擎层的提交

1. 释放 Lock_sync mutex, 持有 Lock_commit mutex[ leader持有，follower等待]

2. 遍历队列中的事务，逐一进行 innodb commit.

3. 释放 Lock_commit mutex

4. 唤醒队列中等待的线程。

 

Redo Group Commit优化

每个事务提交时，都会触发一次redo flush/sync动作，由于磁盘读写比较慢，因此很影响系统的吞吐量。

mysql57中，做了针对redo group commit的优化。将 redo log的write/sync延迟到了binlog group commit的 flush stage之后，sync binlog之前。

通过延迟写redo log的方式，显式的为redo log做了一次组写入，并减少了(redo log) log_sys->mutex的竞争。

 

第一阶段：Innodb Prepare

1. 记录当前的LSN到thd中

第二阶段：Binlog Group Commit

1. 进入Binlog Group Commit的flush阶段；同时，leader搜索队列，算出thd中最大的LSN

2. 将innodb的redo log flush/sync到指定LSN

3. sync binlog

4. commit

 

参考

https://blog.csdn.net/weixin_38597669/article/details/104096684

https://blog.csdn.net/zhang123456456/article/details/83857127