MySQL的三大日志

MySQL的三大日志

MySQL 有三个比较重要的日志

• bin log 归档日志
• redo log 重做日志(事务日志)
• undo log 回滚日志

redo log 日志

redo log日志是InnoDB引擎独有的，使数据库拥有了崩溃恢复能力，它能在数据库发生宕机后，重启进行数据的恢复。
mysql中的数据是以数据页为单位的，每次查询的时候，都会先从buffer pool中看有没有想要的数据页，没有再去数据库找，然后把查询到的数据存放到buffer pool中，对于更新操作也是如此，先去buffer pool中看有没有自己想要的数据，有就直接使用进行更新，然后会把对这些数据页做了什么操作记录到redo log buffer中，然后等待合适的时机进行刷盘，也就是刷到redo log日志中。
刷盘时机
InnoDB为redo log提供了三种刷盘策略，通过 innodb_flush_log_at_trx_commit 参数设置。

• 0：每次在事务提交前将操作记录在redo log buffer 中，等待后台线程将其写入文件系统 page cache 中，然后刷到 redo log 日志；这种情况下，mysql宕机或者挂了都会损失1秒的数据。
• 1：每次事务提交就将记录刷到 redo log 日志；这种情况下不会损失数据。
• 2：每次事务提交前将记录存放在 redo log buffer 中，然后再写入page cache 中，最后等待刷到 redo log 中；这种情况下mysql挂了不会损失数据，但是宕机就会损失1秒的数据。

bin log 日志

不管是什么引擎，都有bin log 日志，它记录了数据库的执行语句，可以用在数据库数据的备份、主从等情况下使用，通过 bin log 日志来同步数据。
bin log 日志有三种存储格式，通过binlog_format参数设置。

• statement
• row
• mixed
  statement格式会记录原生的sql语句，这种情况下，如果更新值是now()的话，记录的语句就会是：update a=now() t where id=1;这个时候就会存在数据不一致的问题。
  row格式就是将原生语句转换为具体数值的语句记录，这种方式就不会产生上面说的那种问题，但是相应的，需要的空间就会相对增大。
  mixed格式就是，当判断到语句会产生数据问题时，就采用row的格式存储，不会产生数据问题时就采用statement格式，算是一种折中的方式。
  bin log 日志的记录是在事务提交前，先记录到binlog cache中，然后在写入page cache中，然后刷到bin log 中。
  写入机制
  mysql使用sync_binlog参数来设置写入机制
• 0：事务提交将记录存放到binlog cache中，然后写入 page cache，等待刷到binlog中
• 1：事务提交就会一直刷到binlog日志中，跟redolog的刷盘一样
• N：自己设置N，当在 page cache的数量到达N后就刷到binlog日志中

两阶段提交

redolog和binlog两种日志的写入时机不一样，redolog是在事务的执行过程不断的写入，而binlog只在事务提交时写入。
在事务执行过程中，如果发生了错误状况，binlog日志没有写入成功，那么在数据库重新恢复的时候，因为有了redolog日志而去恢复数据，但是binlog并没有，这样岂不是数据不对了！针对这种情况，提出了两阶段提交，在事务执行过程中redolog日志是prepare状态，等到事务提交了，才是commit状态，所以就可以避免上面的情况发生，即使在commit状态没有成功，在数据库进行恢复时，会发现redolog日志有对应的binlog日志，这时也可以将数据恢复成功的。

undo log 日志

这个日志主要是进行回滚时使用的，主要用在MVCC多版本并发控制，在事务需要进行回滚恢复数据时使用。
MVCC的实现是通过 隐藏字段、回滚日志、Read View 来实现的。
针对于RC和RR两种隔离级别下的Read View的获取又是不一样的，RC在每次进行快照读时都会生成一个新的Read View，而RR级别下只在事务开始的时候生成一个Read View。所以RR级别下支持了可重复读的情况。
InnoDB存储引擎在 RR 级别下通过 MVCC和 Next-key Lock 来解决幻读问题。
比如当前有三个事务a,b,c，a和b都修改了数据，但是都未提交，而事务c此时是无法读取到它们修改的数据的，因为事务a和b都在活跃事务中，只有记录版本号小于事务c的或者不在活跃事务中，才对事务c可见。