在Mysql中,引擎InnoDB支持事务机制,对数据表进行insert、update及delete操作,可用来维护数据结构及数据的完整性,
确保批量的操作要么全部执行,要么全部不执行。
mysql默认repeatble read
确保批量的操作要么全部执行,要么全部不执行。
mysql默认repeatble read
在一个特定的物理位置保存关于事务的相关信息,称事务系统段(仅有一个页)
回滚段的segment header信息
MySQL二进制日志位置信息
doublewrite段信息
BEGIN
回滚段的segment header信息
MySQL二进制日志位置信息
doublewrite段信息
BEGIN
undo 日志文件
undo记录了数据在事务开始之前的值,当事务执行失败或者ROLLBACK时可以通过undo记录的值来恢复数据。
还用Undo Log来实现多版本并发控制
例如 AA和BB的初始值分别为3,5。
A 事务开始
B 记录AA=3到undo_buf
C 修改AA=1
D 记录BB=5到undo_buf
E 修改BB=7
F 将undo_buf写到undo(磁盘)
G 将data_buf写到datafile(磁盘)
H 事务提交
undo记录了数据在事务开始之前的值,当事务执行失败或者ROLLBACK时可以通过undo记录的值来恢复数据。
还用Undo Log来实现多版本并发控制
例如 AA和BB的初始值分别为3,5。
A 事务开始
B 记录AA=3到undo_buf
C 修改AA=1
D 记录BB=5到undo_buf
E 修改BB=7
F 将undo_buf写到undo(磁盘)
G 将data_buf写到datafile(磁盘)
H 事务提交
通过undo可以保证原子性、稳定性和持久性
如果事务在F之前崩溃由于数据还没写入磁盘,所以数据不会被破坏。
如果事务在G之前崩溃或者回滚则可以根据undo恢复到初始状态。
数据在任务提交之前写到磁盘保证了持久性。
但是单纯使用undo保证原子性和持久性需要在事务提交之前将数据写到磁盘,浪费大量I/O。
redo/undo 日志文件
引入redo日志记录数据修改后的值,可以避免数据在事务提交之前必须写入到磁盘的需求,减少I/O。
A 事务开始
B 记录AA=3到undo_buf
C 修改AA=1 记录redo_buf
D 记录BB=5到undo_buf
E 修改BB=7 记录redo_buf
F 将redo_buf写到redo(磁盘)
G 事务提交
通过undo保证事务的原子性,redo保证持久性。
F之前崩溃由于所有数据都在内存,恢复后重新冲磁盘载入之前的数据,数据没有被破坏。
FG之间的崩溃可以使用redo来恢复。
G之前的回滚都可以使用undo来完成
如果事务在F之前崩溃由于数据还没写入磁盘,所以数据不会被破坏。
如果事务在G之前崩溃或者回滚则可以根据undo恢复到初始状态。
数据在任务提交之前写到磁盘保证了持久性。
但是单纯使用undo保证原子性和持久性需要在事务提交之前将数据写到磁盘,浪费大量I/O。
redo/undo 日志文件
引入redo日志记录数据修改后的值,可以避免数据在事务提交之前必须写入到磁盘的需求,减少I/O。
A 事务开始
B 记录AA=3到undo_buf
C 修改AA=1 记录redo_buf
D 记录BB=5到undo_buf
E 修改BB=7 记录redo_buf
F 将redo_buf写到redo(磁盘)
G 事务提交
通过undo保证事务的原子性,redo保证持久性。
F之前崩溃由于所有数据都在内存,恢复后重新冲磁盘载入之前的数据,数据没有被破坏。
FG之间的崩溃可以使用redo来恢复。
G之前的回滚都可以使用undo来完成