【Mysql】 binlog、redo log、undo log三种日志对比

目录

 

1. 3种日志对比

​2. binlog二进制 逻辑

2.1 what

文件写入

3. redo log 重做日志 物理

what:

文件写入

4. undo log 逻辑

5. update流程(记录日志时机)


1. 3种日志对比

【Mysql】 binlog、redo log、undo log三种日志对比_第1张图片

二进制日志bin log仅在事务提交时记录,一对一,每一个事务仅包含对应事务的一个日志。

重做日志redo log记录的是物理操作日志,一对多每个事务对应多个日志条目,并且事务的重做日志写入是并发的,并非在事务提交时写入,故其在文件中记录的顺序并非是事务开始的顺序。*T1、*T2、*T3表示的是事务提交时的日志

2. binlog二进制 逻辑

2.1 what

逻辑日志,是由mysql上层产生,无论采用什么存储引擎都会有。

由两种格式,Statment格式ROW格式和Mixed格式

格式 样例
Statment

存储sql

update table set a='aa' where id=52;

ROW格式

每行数据地 修改前后地每个字段地值mysqlbinlog解析如下

【Mysql】 binlog、redo log、undo log三种日志对比_第2张图片

如图,包含一行数据的修改前后的值,达到误操作后进行恢复的目的

Mixed格式  

 

2.2 how文件写入

binlog是追加写,不会覆盖;当文件满了,就创建新的binlog文件,index递增,循环写入

3. redo log 重做日志 物理

重做日志主要用于宕机恢复,在事务提交前一定会写入到重做日志,但数据不一定持久化到了数据页。

Write-Ahead Logging先写日志,再写磁盘,更新数据时数据行可能是没有及时修改的;这么做是为了提高性能,因为数据行比较分散,写入文件可能要重新磁盘寻址影响性能;

而重做日志是顺序读写,没有了最耗时地磁盘寻址;当事务提交后如果发生宕机,此时数据是未持久化地,重启后可以根据重做日志进行恢复,保障了事务的持久性

what:

记录页的修改

日志类型有插入、删除等51种,以插入、删除为例,他们的格式如下,

插入语句记录了哪个表空间、哪一页、哪个偏移下需要存放rec body这一行。

删除语句记录表空间、哪一页、哪个偏移的行是需要删除的。

【Mysql】 binlog、redo log、undo log三种日志对比_第3张图片

文件写入

多个重做日志文件循环写,会覆盖!因为数据也会刷磁盘,当刷完磁盘,redo 日志已经没有用了!

【Mysql】 binlog、redo log、undo log三种日志对比_第4张图片

4. undo log 逻辑

主要用于事务回滚 和MVCC 多版本并发控制

undo log分为 insert和update,划分是根据插入语句的undo log提交后可以直接删除;而update类型的根据MVCC的需求不能删除,需要purge线程判断能否删除。

insert类型的undo log格式如下,记录了next下一跳日志、类型、undo no、表id和主键kv,如需回滚直接根据主键定位到数据行进行删除

update类型是针对update语句和delete语句,除了以上 还记录了修改数据的事务id、数据的回滚指针、update vector 修改的列的原始和修改值,可以根据这个写出相反的update语句和insert语句。

【Mysql】 binlog、redo log、undo log三种日志对比_第5张图片【Mysql】 binlog、redo log、undo log三种日志对比_第6张图片

5. update流程(记录日志时机)

【Mysql】 binlog、redo log、undo log三种日志对比_第7张图片

两阶段提交

将 redo log 的写入拆成了两个步骤:prepare 和 commit,这就是"两阶段提交"。

why:

由于 redo log 和 binlog 是两个独立的逻辑,如果不用两阶段提交,要么就是先写完redo log 再写 binlog,或者采用反过来的顺序。我们看看这两种方式都会存在当两者中间数据库崩溃的话,两者数据不一致

 

你可能感兴趣的:(数据库)