重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
本篇文章为大家展示了什么是两阶段提交和组提交,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。
创新互联建站是一家专业提供阳城企业网站建设,专注与网站建设、网站设计、H5技术、小程序制作等业务。10年已为阳城众多企业、政府机构等服务。创新互联专业的建站公司优惠进行中。
出于性能的考虑,事务在提交时为了保证数据安全,需要将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本身就支持组提交。
上述内容就是什么是两阶段提交和组提交,你们学到知识或技能了吗?如果还想学到更多技能或者丰富自己的知识储备,欢迎关注创新互联行业资讯频道。