mysql redo log与bin log

最新推荐文章于 2024-05-28 17:10:36 发布

像个人丶

最新推荐文章于 2024-05-28 17:10:36 发布

阅读量321

点赞数

分类专栏： mysql 文章标签： mysql

本文链接：https://blog.csdn.net/qq_43706325/article/details/127491576

版权

mysql 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

mysql redo log与bin log

前言
日志
两阶段提交

前言

在学习redo log与bin log日志之前，先了解一下一条更新语句在mysql中是如何执行的。

先创建一张表，这个表有一个主键ID和一个整型字段c：

mysql> create table T(ID int primary key, c int);

查询ID=2这一行的值
将ID=2这一行的值加1，SQL语句就会这么写：

mysql>select * from T where Id=2;
mysql> update T set c=c+1 where ID=2;

一条mysq语句执行如图1所示
mysql执行流程

图1 mysql执行语句执行过程首先通过连接器连接到mysql，若为一条查询语句，则在查询缓存中查询是否有相关数据（mysql8之后已经弃用查询缓存）。然后通过语法器进行语法分析，判断是否有语法错误，在经过优化器选择最优的执行sql，交给执行器执行。
与查询流程不一样的是，更新流程还涉及两个重要的日志模块，它们正是我们今天要讨论的主角：redo log（重做日志）和 binlog（归档日志）

日志

redo log日志

当mysql每执行一次更新操作，若每次更新都去磁盘中查找出数据，在将数据修改，这个过程中会产生大量的磁盘IO，会让mysql的性能大大降低，并且持久化到redo log是连续写入，而在磁盘是随机的，因此采用redo log 效率较高。为了解决这个问题，mysql采用了WAL技术。即先将修改写入到redo log日志中，空闲下来之后，再将日志中的修改同步到磁盘中。

但是，redo log日志并不是无限大的。，InnoDB的redo log是固定大小的，比如可以配置为一组4个文件，每个文件的大小是1GB。并且，redo log日志是循环写，如图2所示。
redo log循环写入

图2 redo log循环写入 write pos是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。

write pos和checkpoint之间还空着的部分，可以用来记录新的操作。如果write pos追上checkpoint，表示已经用完，这时候不能再执行新的更新，得停下来先将一部分修改同步到磁盘中，把checkpoint推进一下。

有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。

bin log日志

redo log日志是属于InnoDB的日志，而在mysql的Server层中，也有自己的日志：bin log日志。

因为最开始MySQL里并没有InnoDB引擎。MySQL自带的引擎是MyISAM，但是MyISAM没有crash-safe的能力，binlog日志只能用于归档。而InnoDB是另一个公司以插件形式引入MySQL的，既然只依靠binlog是没有crash-safe能力的，所以InnoDB使用另外一套日志系统——也就是redo log来实现crash-safe能力。

几个区别

redo log日志是属于InnoDB引擎的，而bin log日志是在mysql的Server层实现的。
redo log是物理日志，记录的是“在某个数据页上做了什么修改”；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1 ”。
redo log是循环写的，空间固定会用完；binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

两阶段提交

回到开头的update语句，一条update语句的具体执行流程如下
两阶段提交

图3 两阶段提交将redo log的写入拆成了两个步骤：prepare和commit，这就是"两阶段提交"。为什么要两阶段提交？

如果不采用两阶段提交会出现什么问题？用前面的update语句来做例子。假设当前ID=2的行，字段c的值是0，再假设执行update语句过程中在写完第一个日志后，第二个日志还没有写完期间发生了crash，会出现什么情况呢

redo log后写binlog假设在redo log写完，binlog还没有写完的时候，MySQL进程异常重启。redo log写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行c的值是1。
但是由于binlog没写完就crash了，这时候binlog里面就没有记录这个语句。因此，之后备份日志的时候，存起来的binlog里面就没有这条语句。
若用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，这个临时库就会少了这一次更新，恢复出来的这一行c的值就是0，与原库的值不同。
先写binlog后写redo log如果在binlog写完之后crash，由于redo log还没写，崩溃恢复以后这个事务无效，所以这一行c的值是0。但是binlog里面已经记录了“把c从0改成1”这个日志。所以，在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的这一行c的值就是1，与原库的值不同。