mysql redo log与bin log
- 前言
- 日志
- 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所示
图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所示。
图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,与原库的值不同。