什么是两阶段提交和组提交

发布时间:2021-09-14 18:07 来源:亿速云 阅读:0 作者:柒染 栏目: Mysql

本篇文章为大家展示了什么是两阶段提交和组提交,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。

出于性能的考虑,事务在提交时为了保证数据安全,需要将redo和undo数据落盘,不用等待数据落盘。但是不仅要考虑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本身就支持组提交。

免责声明:本站发布的内容(图片、视频和文字)以原创、来自互联网转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:ts@56dr.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。