当前位置:Gxlcms > 数据库问题 > mysql组提交

mysql组提交

时间:2021-07-01 10:21:17 帮助过:26人阅读

当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

 

 

 

 

技术图片

 

mysql组提交

标签:事务   rap   记录   innodb   否则   其他   commit   引入   链表   

人气教程排行