一、大纲
一阶段提交
二阶段提交
三阶段提交
组提交总结
二、一阶段提交
2.1 什么是一阶段提交
先了解下含义,其实官方并没有定义啥是一阶段,这里只是我为了上下文和好理解,自己定义的一阶段commit流程。
好了,这里的一阶段,其实是针对MySQL没有开启binlog为前提的,因为没有binlog,所以MySQL commit的时候就相对简单很多。
解释几个概念:
execution state做什么事情呢
在内存修改相关数据,比如:DML的修改
prepare stage做什么事情呢
1. write() redo 日志
1.1 最重要的操作,记住这个时候就开始刷新redo了(依赖操作系统sync到磁盘),很多同学在这个地方都不太清楚,以为flush redo在最后commit阶段才开始
1.2 这一步可以进行多事务的prepare,也就意味着可以多redo的flush,sync到磁盘,这里是redo的组提交. 在此说明MySQL5.6+ redo是可以进行组提交的,之后我们讨论的重点是binlog,就不在提及redo的组提交了
2. 更新undo状态
3. 等等
innodb commit stage做什么事情呢
1. 更新undo的状态
2. fsync redo & undo(强制sync到磁盘)
3. 写入最终的commit log,代表事务结束
4. 等等
由于这里面只对应到redo日志,所以我们称之为一阶段commit
2.2 为什么要有一阶段提交
一阶段提交,主要是为了crash safe。
如果在 execution stage mysql crash
当MySQL重启后,因为没有记录redo,此事务回滚
如果在 execution stage mysql crash
当MySQL重启后,因为没有记录redo,此事务回滚
如果 prepare stage
1. redo log write()了,但是还没有fsync()到磁盘前,mysqld crash了
此时:事务回滚
2. redo log write()了,fsync()也落盘了,mysqld crash了
此时:事务还是回滚
如果 commit stage
1. commit log fsync到磁盘了
此时:事务提交成功,否则事务回滚
2.3 一阶段提交的弊端
缺点也很明显:
缺点一
1. 为什么redo fsync到磁盘后,还是要回滚呢?
缺点二
1. 没有开启binlog,性能非常高,但是binlog是用来搭建slave的,否则就是单节点,不适合生产环境
三、二阶段提交
3.1 什么是二阶段提交
继续解释几个概念:
execution state做什么事情呢
在内存修改相关数据,比如:DML的修改
prepare stage做什么事情呢
1. write() redo 日志 --最重要的操作,记住这个时候就开始刷新redo了(依赖操作系统sync到磁盘),很多同学在这个地方都不太清楚,以为flush redo在最后commit阶段才开始
2. 更新undo状态
3. 等等
binlog stage做什么事情呢
1. write binlog
flush binlog 内存日志到磁盘缓存
2. fsync binlog
sync磁盘缓存的binlog日志到磁盘持久化
innodb commit stage做什么事情呢
1. 更新undo的状态
2. fsync redo & undo(强制sync到磁盘)
3. 写入最终的commit log,代表事务结束
4. 等等
由于这里的流程中包含了binlog和redo日志刷新的协调一致性,我们称之为二阶段
3.2 为什么要有二阶段提交
当binlog开启的情况下,我们需要引入另一套流程来保证redo和binlog的一致性 , 以及crash safe,所以我们用这套二阶段来实现
在prepare阶段,如果mysqld crash,由于事务未写入binlog且innodb 存储引擎未提交,所以将该事务回滚掉
当binlog阶段
1. binlog flush 到磁盘缓存,但是没有永久fsync到磁盘
如果mysqld crash,此事务回滚
2. binlog永久fsync到磁盘,但是innodb commit log还未提交
如果mysqld crash,MySQL 进行recover,从binlog的xid提取提交的事务进行重做并commit,来保证binlog和redo保持一致
当commit阶段
如果innodb commit log已经提交,事务成功结束
那为什么要保证redo和binlog的一致性呢?
物理热备的问题
多事务中,如果无法保证多事务的redo和binlog一致性,则会有如下问题
commit提交阶段包含的事情:
1. prepare
2. write binlog & fsync binlog
3. commit
T1 (---prepare-----write 100[pos1]-------fsync 100--------------------------------------online-backup[pos3:因为热备取的是最近的提交事务位置]-------commit)
T2 (------prepare------write 200[pos2]---------fsync 200------commit)
T3 (-----------prepare-------write 300[pos3]--------fsync 300--------commit)
解析:
事务的开始顺序: T1 -》T2 -》T3
事务的提交结束顺序: T2 -》T3 -》T1
binlog的写入顺序: T1 -》 T2 -》T3
结论:
T2 , T3 引擎层提交结束,T1 fsync binlog 100 也已经结束,但是T1引擎成没有提交成功,所以这时候online-backup记录的binlog位置是pos3(也就是T3提交后的位置)
如果拿着备份重新恢复slave,由于热备是不会备份binlog的,所以事务T1会回滚掉,那么change master to pos3的时候,因为T1的位置是pos1(在pos3之前),所以T1事务被slave完美的漏掉了
多事务中,可以通过三阶段提交(下面一节讲)保证redo和binlog的一致性,则备份无问题. 接下来看一个多事务中,事务日志和binlog日志一致的情况
commit提交阶段包含的事情:
1. prepare
2. write binlog & fsync binlog
3. commit
T1 (---prepare-----write 100[pos1]-------fsync 100-------------commit)
T2 (------prepare------write 200[pos2]---------fsync 200----------------online-backup[pos2:因为热备取的是最近的提交事务位置]---commit)
T3 (-----------prepare-------write 300[pos3]--------fsync 300----------------------------------------------------------------------------commit)
解析:
事务的开始顺序: T1 -》T2 -》T3
事务的提交结束顺序: T1 -》T2 -》T3
binlog的写入顺序: T1 -》 T2 -》T3
ps:以上的事务和binlog完全按照顺序一致运行
结论:
T1 引擎层提交结束,T2 fsync binlog 200 也已经结束,但是T2引擎成没有提交成功,所以这时候online-backup记录的binlog位置是pos1(也就是T1提交后的位置)
如果拿着备份重新恢复slave,由于热备是不会备份binlog的,所以事务T2会回滚掉,那么change master to pos1的时候,因为T1的位置是pos1(在pos2之前),所以T2、T3事务会被重做,最终保持一致
总结:
以上的问题,主要原因是热备份工具无法备份binlog导致的根据备份恢复的slave回滚导致的,产生这样的原因最后还是要归结于最后引擎层的日志没有提交导致
所以,xtrabackup意识到了这一点,最后多了这一步flush no_write_to_binlog engine logs,表示将innodb层的redo全部持久化到磁盘后再进行备份,在通俗的说,就是图例上的T2一定成功后,才会再继续进行拷贝备份
那么如果是这样,图例上的T2在恢复的时候,就不会被回滚了,所以就自然不会丢失事务啦
主从数据不一致问题
如果redo和binlog不是一致的,那么有可能就是master执行事务的顺序和slave执行事务顺序不一样,那么不一样会导致什么问题呢?
在一些依赖事务顺序的场景,尤其重要,比如我们看一个例子
master节点提交T1和T2事务按照以下顺序
1. State0: x= 1, y= 1 --初始值
2. T1: { x:= Read(y);
3. x:= x+1;
4. Write(x);
5. Commit; }
State1: x= 2, y= 1
7. T2: { y:= Read(x);
8. y:=y+1;
9. Write(y);
10. Commit; }
State2: x= 2, y= 3
以上两个事务顺序在master为 T1 -> T2
最终结果为
State1: x= 2, y= 1
State2: x= 2, y= 3
如果slave的事务执行顺序与master相反,会怎么样呢?
1. State0: x= 1, y= 1 --初始值
2. T2: { y:= Read(x);
3. y:= y+1;
4. Write(y);
5. Commit; }
6.
State1: x= 1, y= 2
7. T1: { x:= Read(y);
8. x:=x+1;
9. Write(x);
10. Commit; }
11.
State2: x= 3, y= 2
以上两个事务顺序在master为 T2 -> T1
最终结果为
State1: x= 1, y= 2
State2: x= 3, y= 2
结论:
为了保证主备数据一致性,slave节点必须按照同样的顺序执行,如果顺序不一致容易造成主备库数据不一致的风险。
而redo 和 binlog的一致性,在单线程复制下是master和slave数据一致性的另一个保证, 多线程复制需要依赖MTS的设置
所以,MySQL必须要保证redo 和 binlog的一致性,也就是:引擎层提交的顺序和server层binlog fsync的顺序必须一致,那么二阶段提交就是这样的机制
3.3 二阶段提交的弊端
二阶段提交能够保证同一个事务的redo和binlog的顺序一致性问题,但是无法解决多个事务提交顺序一致性的问题
四、三阶段提交
4.1 什么是三阶段提交
继续解释几个概念:
execution state做什么事情呢
在内存修改相关数据,比如:DML的修改
prepare stage做什么事情呢
1. write() redo 日志 --最重要的操作,记住这个时候就开始刷新redo了(依赖操作系统sync到磁盘),很多同学在这个地方都不太清楚,以为flush redo在最后commit阶段才开始
2. 更新undo状态
3. 等等
binlog stage做什么事情呢
1. write binlog --一组有序的binlog
flush binlog 内存日志到磁盘缓存
2. fsync binlog --一组有序的binlog
sync磁盘缓存的binlog日志到磁盘持久化
innodb commit stage做什么事情呢
1. 更新undo的状态
2. fsync redo & undo(强制sync到磁盘)
3. 写入最终的commit log,代表事务结束 --一组有序的commit日志,按序提交
4. 等等
这里将整个事务提交的过程分为了三个大阶段
InnoDB, Prepare
SQL已经成功执行并生成了相应的redo日志
Binlog, Flush Stage(group) -- 一阶段
写入binlog缓存;
Binlog, Sync Stage(group) -- 二阶段
binlog缓存将sync到磁盘
InnoDB, Commit stage(group) -- 三阶段
leader根据顺序调用存储引擎提交事务;
重要参数:
binlog_group_commit_sync_delay=N : 等待N us后,开始刷盘binlog
binlog_group_commit_sync_no_delay_count=N : 如果队列的事务数达到N个后,就开始刷盘binlog
4.2 为什么要有三阶段提交
目的就是保证多事务之间的redo和binlog顺序一致性问题, 以及加入组提交机制,让redo和binlog都可以以组的形式(有序集合)进行fsync来提高并发性能
4.3 再来聊聊MySQL组提交
队列相关
组提交举例
(一)、T1事务第一个进入第一阶段 FLUSH , 由于是第一个,所以是leader,然后再等待(按照具体算法)
(二)、T2事务第二个进行第一阶段 FLUSH , 由于是第二个,所以是follower,然后等待leader调度
(三)、FLUSH队列等待结束后,开始进入下一阶段SYNC阶段,此时T1带领T2进行一次fsync操作,之后进入commit阶段,按序提交完成,这就是一次组提交的简要过程了
(四)、prepare可以并行,说明两个事务没有任何冲突。有冲突的prepare无法进行进入同一队列
(五)、每个队列之间都是可以并行运行的
五、总结
组提交的核心思想就是:一次fsync()调用,可以刷新N个事务的redo log(redo的组提交) & binlog(binlog的组提交)
组提交的最终目的就是为了减少IO的频繁刷盘,来提高并发性能,当然也是之后多线程复制的基础
组提交中:sync_binlog=1 & innodb_trx_at_commit=1 代表的不再是1个事务,而是一组事务和一个事务组的binlog
组提交中:binlog是顺序fsync的,事务也是按照顺序进行提交的,这都是有序的,MySQL5.7 并对这些有序的事务进行打好标记(last_committed,sequence_number )
六、思考问题
如何保证slave执行的同一组binlog的事务顺序跟master的一致
如果slave上同一组事务中的后面的事务先执行,那么slave的gtid该如何表示
如何保证slave上同一组事务中的事务是按照顺序执行的
如果slave突然挂了,那么执行到一半的一组事务,是全部回滚?还是部分回滚?
如果是部分回滚,那么如何知道哪些回滚了,哪些没有回滚,mysql如何自动修复掉回滚的那部分事务