MySQL中的几类日志

先简单对三大日志进行总结：

• mysql innodb引擎使用redo log(重做日志)保证事务的持久性，使用undo log(回滚日志)保证事务的原子性
• mysql的数据备份，主备，主主，主从都离不开binlog，需要依靠binlog来同步数据，保证数据的一致性

除三大日志外，还有relay log(中继日志)，slow query log(慢查询日志)，error log(错误日志等)

redo log

• 作用：确保事务的持久性。redo日志记录事务执行后的状态，用来恢复未写入data file的已成功事务更新的数据。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。

• 内容：物理格式的日志，记录的是物理数据页面的修改信息，其redo log是顺序写入其物理文件中的。
  

  Q：什么时候产生？

  在事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中。
  

  Q：什么时候释放？

  当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用(被覆盖)。
  

  Q：对应的物理文件？

  默认情况下，对应的物理文件位于数据库的data目录下的ib_logfile1&ib_logfile2
  innodb_log_group_home_dir指定日志文件组所在的路径，默认为./
  innodb_log_files_in_group指定重做日志文件组中文件的数量，默认为2
  另外还有其他参数等innodb_log_file_size、innodb_mirrored_log_groups
  

  undo log

• 作用：保证数据的原子性，保证了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读(MVCC)，也即非锁定读。

• 内容：逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。
  

  Q：什么时候产生?

  事务开始之前，将当前的版本生成undo log，undo也会产生redo来保证undo log的可靠性。
  

  Q：什么时候释放?

  当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。
  

  Q：对应的物理文件？

  mysql5.6之前，undo表空间位于共享表空间的回滚段中，共享表空间的默认名称是ibdata，位于数据文件目录中。
  mysql5.6之后，undo表空间可以配置成独立的文件，但是提前需要在配置文件中配置，完成数据库初始化后生效且不可改变undo log文件的个数。
  如果初始化数据库之前没有进行相关配置，那么就无法配置成独立的表空间了。
  mysql5.7之后的独立undo表空间配置参数如下：
  innodb_undo_directory=/data/undospace/存放目录
  innodb_undo_logs=128回滚段为128KB
  innodb_undo_tablespaces=4指定有4个undo log文件
  若是使用共享表空间，则由innodb_data_file_path配置
  

  binlog

• 作用：用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步，保证数据的一致性。用于数据库的基于时间点的还原。

• 内容：逻辑格式的日志，可以简单认为就是执行过的事务中的sql语句。但又不完全是sql语句这么简单，而是包括了执行的sql语句反向的信息，意味着delete对应着delete本身和其反向的insert。可以使用mysqlbinlog解析binlog。
  

  Q：什么时候产生？

  事务提交的时候，一次性将事务中的sql语句(一个事务可能对应多个sql语句)按照一定的格式记录到binlog中。
  

  Q：什么时候释放？

  binlog默认保持时间由参数expire_logs_day配置，对于非活动的日志文件，在生成时间超过该配置的天数之后，会被自动删除。
  

  Q：对应的物理文件？

  配置的文件的路径为log_bin_basename，binlog日志文件按照指定大小，当日志文件达到指定大小后进行滚动更新，生成新的日志文件。对于每个binlog日志文件，通过一个统一的index文件来组织。