日志系统主要有redo log(重作日志)和binlog(归档日志)。redo log是InnoDB存储引擎层的日志,binlog是MySQL Server层记录的日志, 二者都是记录了某些操做的日志(不是全部)天然有些重复(但二者记录的格式不一样)。mysql
图来自极客时间的mysql实践,该图是描述的是MySQL的逻辑架构。sql
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
。3d
redo log日志的大小是固定的,即记录满了之后就从头循环写。日志
图片来自极客时间,该图展现了一组4个文件的redo log日志,checkpoint以前表示擦除完了的,便可以进行写的,擦除以前会更新到磁盘中,write pos是指写的位置,当write pos和checkpoint相遇的时候代表redo log已经满了,这个时候数据库中止进行数据库更新语句的执行,转而进行redo log日志同步到磁盘中。code
binlog是属于MySQL Server层面的,又称为归档日志,属于逻辑日志,是以二进制的形式记录的是这个语句的原始逻辑,依靠binlog是没有crash-safe
能力的blog
redo log是属于innoDB层面,binlog属于MySQL Server层面的,这样在数据库用别的存储引擎时能够达到一致性的要求。接口
redo log是物理日志,记录该数据页更新的内容;binlog是逻辑日志,记录的是这个更新语句的原始逻辑图片
redo log是循环写,日志空间大小固定;binlog是追加写,是指一份写到必定大小的时候会更换下一个文件,不会覆盖。
binlog能够做为恢复数据使用,主从复制搭建,redo log做为异常宕机或者介质故障后的数据恢复使用。
update T set c=c+1 where ID=2;
执行器先找引擎取 ID=2 这一行。ID 是主键,引擎直接用树搜索找到这一行。若是 ID=2 这一行所在的数据页原本就在内存中,就直接返回给执行器;不然,须要先从磁盘读入内存,而后再返回。
执行器拿到引擎给的行数据,把这个值加上 1,好比原来是 N,如今就是 N+1,获得新的一行数据,再调用引擎接口写入这行新数据。
引擎将这行新数据更新到内存中,同时将这个更新操做记录到 redo log 里面,此时 redo log 处于 prepare 状态。而后告知执行器执行完成了,随时能够提交事务。
执行器生成这个操做的 binlog,并把 binlog 写入磁盘。
执行器调用引擎的提交事务接口,引擎把刚刚写入的 redo log 改为提交(commit)状态,更新完成。
这个update语句的执行流程图,图中浅色框表示是在 InnoDB 内部执行的,深色框表示是在执行器中执行的。
图片来自极客时间.