当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

最新文章

  1. [Asp.net 5] Logging-日志系统的基本架构(上)
  2. 4. 什么是AJAX
  3. iOS 中的字体预览
  4. 程序员书单_J2EE专题
  5. ASP.NET知识集
  6. 如何在windows系统自带命令查看硬件信息?
  7. 【HDOJ】2217 Visit
  8. CentOS(Linux) - SVN使用笔记(一) - 安装SVN过程及开启和关闭svn服务指令
  9. Go成功的项目
  10. UML 之 序列图和协作图
  11. 事务之使用JDBC进行事务的操作
  12. 40. leetcode 202. Happy Number
  13. android 调用 screenrecord 实现录屏
  14. IDEA升级版本后界面出现变小,字体变细的问题解决
  15. 用Vue.js搭建一个小说阅读网站
  16. Steeltoe之Service Discovery篇
  17. python low版线程池
  18. Hibernate学习笔记2.2(Hibernate基础Annotation配置)
  19. php,判断ajax,get,post
  20. showplan_text查询计划查询 sql执行顺序 时间 IO

热门文章

  1. CodeUp Problem D: More is better
  2. CF1487G String Counting (容斥计数)
  3. C#XmlHelper帮助类操作Xml文档的通用方法汇总
  4. 使用docker配置laravel5.5环境
  5. Bigdecimal 比较问题
  6. MyBatis in
  7. Filter是什么?有什么作用?
  8. Kafka创建Topic时如何将分区放置到不同的Broker中?
  9. selenium 模块使用
  10. BootstrapBlazor 智能生成神器(一)AutoGenerateColumnAttribute 特性介绍