ITPub博客

首页 > 数据库 > MySQL > mysql两阶段提交和组提交

mysql两阶段提交和组提交

原创 MySQL 作者:水逸冰 时间:2020-06-06 23:54:50 0 删除 编辑

     出于性能的考虑,事务在提交时为了保证数据安全,需要将 redo undo 数据落盘,不用等待数据落盘。但是 mysql 不仅要考虑 innodn 存储引擎层的 redo 数据,还要考虑数据库上层的 binlog 数据落盘,已经两个层面数据落盘的顺序问题。两阶段提交可以解决单个事务 redo binlog 落盘顺序的问题。

两阶段提交( 2PC )分为两个过程:

l   准备阶段( prepare phase

生成 xid 信息,回滚段设置为 prepare 状态,并将 redo 落盘。

l   提交阶段( commit phase

binlog 生成 commit XID event Binlog 落盘,释放回滚段,释放锁。

 

二阶段提交的回滚:
       只写了redo,没落盘binlog,回滚。

落盘了redo,binlog落盘成功了,也有commit XID,自然是成功。

落盘了redo,binlog落盘成功了,没有commit XID,也认为事务已提交。


现在再来思考下一个问题,如果每个事物提交的时候,都要去将 redo binlog 落盘,那么瓶颈就在落盘阶段被放大了。这个时候就要引入组提交。组提交使得 redo binlog 落盘的时候可以批量落盘,多个事务的 redo binlog 可以一次 fsync 操作完成数据落盘,减少了 fsync 函数的调用,提高了效率。同时 innodb 存储引擎层本身就支持组提交。

 

组提交之后,引入了另一个问题。数据库上层的 binlog 写入顺序和 innodb 层事务提交顺序无法保持一致。如果不保持一致,那么就会出现通过在线工具比如 xtrabackup 备份数据库搭建主从的时候,出现丢失事务的场景,比如下面:

                                             

      binlog 提交顺序( T1,T2,T3 ), innodb commit 顺序( T2,T3,T1 ),此时 innodb 检测到 T3 上下两层都已经提交,认为不再需要恢复,那么 T1 事务在备份的时候没有经历两阶段提交, T1 的事务在备份的时候数据还是事务开始前的数据,从库又不再进行恢复,导致 T1 事务被丢弃。所以后来引进了 prepare_commit_mutex, 以串行的方式来保证顺序,但是这样会使组提交失效,所以后来提出了 BLGC binary log group commit

该行为分为三个阶段

Flush 阶段

内存中生成事务的二进制日志

Sync 阶段

将内存中多个事务的二进制日志调用 1 fsync 刷盘

Commit 阶段

二进制日志在内存中会有一个队列,队列第一个事务是 leader ,其他时 follower leader 会根据顺序调用存储引擎层事务提交。 Innodb 本身就支持组提交。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31480688/viewspace-2696699/,如需转载,请注明出处,否则将追究法律责任。

全部评论
精通oracle,mysql和linux,热衷于研究数据库,擅长shell和Python自动化运维。VX:18302174682

注册时间:2017-08-05

  • 博文量
    102
  • 访问量
    107975