https://segmentfault.com/a/1190000017888478
redo log(重做日志):redo log是InnoDB存储引擎层的日志,用于记录事务操作的变化,记录的是数据修改之后的值,不管事务是否提交都会记录下来。在实例和介质失败(media failure)时,redo log文件就能派上用场,如数据库掉电,InnoDB存储引擎会使用redo log恢复到掉电前的时刻,以此来保证数据的完整性。
在一条更新语句进行执行的时候,InnoDB引擎会把更新记录写到redo log日志中,然后更新内存,此时算是语句执行完了,然后在空闲的时候或者是按照设定的更新策略将redo log中的内容更新到磁盘中,这里涉及到WAL即Write Ahead logging技术,他的关键点是先写日志,再写磁盘。
有了redo log日志,那么在数据库进行异常重启的时候,可以根据redo log日志进行恢复,也就达到了crash-safe。
redo log日志的大小是固定的,即记录满了以后就从头循环写。
简单描述作用:确保事务的持久性。防止在发生故障的时间点,尚有脏页未写入磁盘,在重启mysql服务的时候,根据redo log进行重做,从而达到事务的持久性这一特性。
binlog(归档日志):是MySQL Server层记录的日志,是以二进制的形式记录的是这个语句的原始逻辑,依靠binlog是没有crash-safe能力的
两者都是记录了某些操作的日志(不是所有)自然有些重复(但两者记录的格式不同)。
作用:用于复制,在主从复制中,从库利用主库上的binlog进行重播,实现主从同步。 用于数据库的基于时间点的还原。
作用:保存了事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制下的读(MVCC),也即非锁定读。
undo log
提供两种功能:
undo log主要分为两种:
insert undo log
:代表事务在insert
新记录时产生的undo log
, 只在事务回滚时需要,并且在事务提交后可以被立即丢弃update undo log
:事务在进行update
或delete
时产生的undo log
; 不仅在事务回滚时需要,在快照读时也需要;所以不能随便删除,只有在快照读或事务回滚不涉及该日志时,对应的日志才会被purge
线程统一清除purge
1、从前面的分析可以看出,为了实现InnoDB的MVCC机制,更新或者删除操作都只是设置一下老记录的deleted_bit,并不真正将过时的记录删除。
2、为了节省磁盘空间,InnoDB有专门的purge线程来清理deleted_bit为true的记录。为了不影响MVCC的正常工作,purge线程自己也维护了一个read view(这个read view相当于系统中最老活跃事务的read view);如果某个记录的deleted_bit为true,并且DB_TRX_ID相对于purge线程的read view可见,那么这条记录一定是可以被安全清除的。
MVCC,全称Multi-Version Concurrency Control,即多版本并发控制。MVCC是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问,在编程语言中实现事务内存。
在学习MVCC多版本并发控制之前,我们必须先了解一下,什么是MySQL InnoDB下的当前读和快照读?
1、当前读
2、快照读
数据库并发场景有三种,分别为:
MVCC
作用:解决读-写冲突的无锁并发控制,这里的读是快照读
MVCC组合:
MVCC
的目的就是多版本并发控制,在数据库中的实现,就是为了解决读写冲突,它的实现原理主要是依赖记录中的 3个隐式字段,undo日志 ,Read View 来实现的
每行记录除了我们自定义的字段外,还有数据库隐式定义的DB_ROW_ID
,DB_TRX_ID
,DB_ROLL_PTR
等字段
DB_ROW_ID
:6byte
,隐含的自增ID
(隐藏主键),如果数据表没有主键,InnoDB
会自动以DB_ROW_ID
产生一个聚簇索引DB_TRX_ID
:6byte
,最近修改(修改/插入)事务ID
:记录创建这条记录/最后一次修改该记录的事务ID
DB_ROLL_PTR
:7byte
,回滚指针,指向这条记录的上一个版本(存储于rollback segment【回滚段】里)
如上图,DB_ROW_ID
是数据库默认为该行记录生成的唯一隐式主键,DB_TRX_ID
是当前操作该记录的事务ID
,而DB_ROLL_PTR
是一个回滚指针,用于配合undo
日志,指向上一个旧版本
对MVCC有帮助的实质是update undo log,它的执行流程如下:
一、 比如一个有个事务插入persion表插入了一条新记录,记录如下,name为Jerry, age为24岁,隐式主键是1,事务ID和回滚指针,我们假设为NULL
二、 现在来了一个事务1对该记录的name做出了修改,改为Tom
undo log
中,作为旧记录,既在undo log
中有当前行的拷贝副本name
为Tom
,并且修改隐藏字段的事务ID
为当前事务1的ID
,我们默认从1开始,之后递增,回滚指针指向拷贝到undo log
的副本记录,既表示我的上一个版本就是它Read View就是事务进行快照读操作的时候生产的读视图(Read View),在该事务执行的快照读的那一刻,会生成数据库系统当前的一个快照,记录并维护系统当前活跃事务的ID(当每个事务开启时,都会被分配一个ID, 这个ID是递增的,所以最新的事务,ID值越大)
Read View
的组成:所有未提交事务id数组【活跃事务】和已创建的最大事务id组成
作用:用来做可见性判断的, 即当我们某个事务执行快照读的时候,对该记录创建一个Read View读视图,把它比作条件用来判断当前事务能够看到哪个版本的数据,既可能是当前最新的数据,也有可能是该行记录的undo log里面的某个版本的数据。
怎么判断当前事务能看到哪个版本的数据?
1、将当前事务的事务id取出来
2、假设readview:[100,200],300 表示当前系统有两个活跃事务id分别为100,200以及已创建的最大事务300
活跃事务中id最小的和已创建的最大事务,可以划分为3部分:
小于100的是已经提交过的事务
100-300的是活跃事务或者已提交事务
300以上的是未开始的事务
3、版本链对比规则
整体的流程是怎么样的呢?我们可以模拟一下
1、当事务2对某行数据执行了快照读,数据库为该行数据生成一个Read View
读视图,假设当前事务ID为2,此时还有事务1和事务3在活跃中,事务4在事务2快照读前一刻提交更新了,所以Read View记录了系统当前活跃事务1,3的ID,维护在一个数组上。
此时的readview:[1,3],4
,Read View
如下图:
2、只有事务4修改过该行记录,并在事务2执行快照读前,就提交了事务,所以该行当前数据的undo log
如下图所示;
我们的事务2在快照读该行记录的时候,就会拿该行记录的DB_TRX_ID【该行记录的事务id】 4
去跟min_id
,max_id
和活跃事务ID列表进行比较,判断当前事务2能看到该记录的版本是哪个。
所以事务4修改后提交的最新结果对事务2快照读时是可见的,所以事务2能读到的最新数据记录是事务4所提交的版本,而事务4提交的版本也是全局角度上最新的版本。
读已提交(RC):RC隔离级别下,每个快照读都会生成并获取最新的Read View,每次都读取undo log中最近的版本,因此两次对同一字段的读可能读到不同的数据(幻读),但能保证每次都读到最新的数据。
可重复读(RR):在RR隔离级别下,则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。每次都读取undo log指定的版本,这样保证不会产生幻读,但可能读不到最新的数据。
https://blog.csdn.net/silyvin/article/details/79320634
参考来源:
https://blog.csdn.net/chen77716/article/details/6742128
https://blog.csdn.net/SnailMann/article/details/94724197?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.edu_weight&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.edu_weight
https://www.bilibili.com/video/BV1YJ411J7vb?from=search&seid=8863410608868353100