Mysql undo和redo的产生时机 mysql undo redo binlog

Mysql简介

开源数据库，简单免费易上手，安装容易使用容易等等，这大概是所有新手程序员对这个数据库的大概印象，而mysql也确实一直在这些方面做得越来越好,当然我指的是社区版.而对于开发人员来讲，数据库编程能力在当下越来越重要，日志是mysql数据库的重要组成内容，它记录并且维护着数据库运行期间的数据状态和操作痕迹。日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志等，今天我们来学习一下mysql中的二进制日志和事务日志。

bin log

bin log的作用主要是记录数据库的写入操作(INSERT/UPDATE/DELETE),俗称DML语句,但是bin log不记录查询操作。bin log是mysql的逻辑日志，所谓逻辑日志就是指的是保存的是执行的sql语句，不管你是何种数据库引擎，mysql都会在执行DML的时候记录bin log。

• bin log通过追加的方式进行写入，并且可以通过指定max_bin_size参数来设置bin log文件大小，因为当文件大小超过阈值之后就会生成新文件来保存日志。
• bin log有三种格式，可以通过指定binlog_format方式指定。
• bin log有过期时间，可以通过指定expire_logs_days的方式指定.
  如下图是我远程数据库的bin log日志：

使用场景

实际开发过程中，常常会碰到数据量巨大、高并发情况，一般的做法是查询优化、分表分库、读写分离等等，而读写分离正是采用主从复制的方式，mysql的主从复制正是利用了bin log的特性；另一个重要用途就是使用bin log完成数据恢复。

bin log刷盘时机

mysql中主要的也是用的最多是InnoDB存储引擎，但是bin log在记录增删改操作的时候只有当事物提交时才会去记录日志,但是问题是当记录还在内存中时什么时候才会刷到磁盘中呢？mysql通过sync_binlog参数控制bin log的输盘时机,取值范围是0-N:

• 0: 不做强制要求,由系统自行决定何时写入;
• 1:每次提交事务的时候都会写入bin log到磁盘中;
• N：每N个事务,才会将bin log写入磁盘。

由上可知，sync_log最安全的值是1，这自然也是MYSQL5.7.7版本后的默认值。 但是磁盘写入操作越频繁对于数据库性能自然会有一定的影响,所以笔者这边建议实际生产时将该参数适当调高，用牺牲一定的一致性来换取更好的性能也是可以的。

bin log日志格式

bin log有三种格式,分别为STATMENT、ROW、和MIXED。

值得注意的是,MYSQL5.7.7之前，bin log格式默认为STATMENT，在那之后默认是RIW。

STATMENT

基于SQL语句的复制(statement-based-replication,SBR),所有涉及到数据修改的sql语句都会记录到bin log中

• 优点 ：不需要记录每一行的变化，减少bin log日质量，节约IO，所以性能最好.
• 缺点:可能会在某些情况下导致主从数据不一致，例如执行sysdate()、sleep;

ROW
基于行变化的复制(row-based replication,RBR),不需要记录每一条sql语句信息,仅需要记录哪一条数据被修改了.

• 优点：不会出现某些情况下的存储过程、函数、触发器调用无法被正确复制和回复的情况.
• 缺点：日志数量会增多,尤其是是在执行alter table的时候日志会暴涨

MIXED
顾名思义就是以上两种的混合使用模式(mixed-based replication,MBR),一般的复制使用STATEMENT，而对于STATEMENT无法复制的则使用ROW模式。

redo log

什么是redo log?

提及数据库事务，大多数同学都能脱口而出它的四大特性-ACID,而其中D(durability)持久性保证了我们的事务一旦提交，将会永久保留在数据库当中而不会因为除了人为因素的任何情况而回退到之前的状态，这也是任何一款数据库系统所必须要保证的最低要求，那么mysql是如何保证一致性的呢?在这边我们不得不提及mysql和磁盘交互的最小单位为页，也就是说当我们输入DML语句提交事务后，mysql会将涉及修改的数据页刷新到磁盘当中，但是这样子做会有性能上的问题，主要体现在以下两方面:

• 若每次提交事务便刷新数据页到磁盘中，在改动量很小的情况下将完整的数据页全部刷新过去对于资源来说是绝大的浪费
• 一个事务修改的数据页可能并不是连续的，当使用随机IO写入时对性能也是一种消耗

所以，mysql在这种情况下设计了 redo log，在事务提交时只记录修改的数据页，就可以完美的解决性能问题(因为日志文件相对更小并且在物理上是连续的)

基本概念

redo log分为两个部分:内存当中的日志缓冲(redo log buffer)和磁盘中的日志文件(redo log file),mysql每执行一条事务操作语句会先将记录写到redo log buffer中，等到后续某一个时间点再将多条记录刷新到redo log file，这种先写日志，再写磁盘的技术就是MySQL里经常说到的WAL(Write-Ahead Logging) 技术。

在计算机操作系统中，用户空间(user space)下的缓冲区数据一般情况下是无法直接写入磁盘的，中间必须经过操作系统内核空间(kernel space)缓冲区(OS Buffer)。因此，redo log buffer写入redo log file实际上是先写入OS Buffer，然后再通过系统调用fsync()将其刷到redo log file中，过程如下：

mysql支持三种将redo log buffer写入redo log file的时机，可以通过innodb_flush_log_at_trx_commit参数配置，各参数值含义如下：

记录形式

前面说过，redo log实际上记录数据页的变更，而这种变更记录是没必要全部保存，因此redo log实现上采用了大小固定，循环写入的方式，当写到结尾时，会回到开头循环写日志。如下图：

同时我们很容易得知，在innodb中，既有redo log需要刷盘，还有数据页也需要刷盘，redo log存在的意义主要就是降低对数据页刷盘的要求。在上图中，write pos表示redo log当前记录的LSN(逻辑序列号)位置，check point表示数据页更改记录刷盘后对应redo log所处的LSN(逻辑序列号)位置。

write pos到check point之间的部分是redo log空着的部分，用于记录新的记录；check point到write pos之间是redo log待落盘的数据页更改记录。当write pos追上check point时，会先推动check point向前移动，空出位置再记录新的日志。

启动innodb的时候，不管上次是正常关闭还是异常关闭，总是会进行恢复操作。因为redo log记录的是数据页的物理变化，因此恢复的时候速度比逻辑日志(如binlog)要快很多。

重启innodb时，首先会检查磁盘中数据页的LSN，如果数据页的LSN小于日志中的LSN，则会从checkpoint开始恢复。

还有一种情况，在宕机前正处于checkpoint的刷盘过程，且数据页的刷盘进度超过了日志页的刷盘进度，此时会出现数据页中记录的LSN大于日志中的LSN，这时超出日志进度的部分将不会重做，因为这本身就表示已经做过的事情，无需再重做。

redo log和bin log的区别

由binlog和redo log的区别可知：binlog日志只用于归档，只依靠binlog是没有crash-safe能力的。但只有redo log也不行，因为redo log是InnoDB特有的，且日志上的记录落盘后会被覆盖掉。因此需要binlog和redo log二者同时记录，才能保证当数据库发生宕机重启时，数据不会丢失。

undo log

数据库事务四大特性中有一个是原子性，具体来说就是 原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。

实际上，原子性底层就是通过undo log实现的。undo log主要记录了数据的逻辑变化，比如一条INSERT语句，对应一条DELETE的undo log，对于每个UPDATE语句，对应一条相反的UPDATE的undo log，这样在发生错误时，就能回滚到事务之前的数据状态。推荐阅读：Java面试题拆解

同时，undo log也是MVCC(多版本并发控制)实现的关键！

感谢阅读，欢迎一起学习。

thanks for ：

bin log详解

Mysql-事务与Redo Log、Undo Log