完全掌握MySQL三大日志binlog、redo log和undo log

本篇文章给大家带来了关于mysql日志的相关知识，我们重点需要关注的是二进制日志(binlog)和事务日志(包括redo log和undo log)，希望对大家有帮助。 1、binlog binlog用于记录数据库执行的写入

    本篇文章给大家带来了关于mysql日志的相关知识，我们重点需要关注的是二进制日志(binlog)和事务日志(包括redo log和undo log)，希望对大家有帮助。

1、binlog

binlog用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。binlog是mysql的逻辑日志，并且由Server层进行记录，使用任何存储引擎的mysql数据库都会记录binlog日志。

binlog使用场景 项目 在实际应用中，binlog的主要使用场景有两个，分别是主从复制和数据恢复。

binlog的格式 binlog共有三种格式，分别是statement、row以及mixed。MySQL 5.7.7版本之前默认使用的是statement，MySQL 5.7.7之后默认使用的是row。日志的格式可以通过my.ini配置文件中的binlog-format来修改。 (1)statement：基于sql语句的复制（statement-based replication,SBR），每一条修改数据的sql语句都会记录到binlog中。

binlog刷盘时机

对于InnoDB存储引擎来说，只有在事务提交的时候才会记录binlog，此时记录还在内存中，MySQL通过sync_binlog来控制binlog的刷盘时机，取值范围为0-N：

binlog的物理文件大小

在my.ini配置文件中，可以通过max_binlog_size来配置binlog的大小。当日志量超过binlog文件的大小时，系统会重新生成一个新的文件来继续保存文件。当一个事务比较大时，或者是当日志越来越多的时候，此时占据的物理空间太大怎么办？MySQL提供了一种自动删除的机制，还是在my.ini配置文件中，可以通过配置expire_logs_days这个参数来解决，单位为天。当这个参数为0，表示永不删除；为N时，表示第N天后自动删除。

2、redo log

redolog是InnoDB引擎专有的日志系统。主要是用来实现事务的持久性以及实现crash-safe功能。redolog属于物理日志，记录的是sql语句执行之后数据页上的具体修改内容。 我们都知道，当MySQL运行的时候，会将数据从磁盘中加载到内存当中。当执行sql语句对数据进行修改时，修改后的内容其实都只是暂时保存到内存当中，如果此时断电或者出现其他情况，这些修改就会丢失。因而，当修改完数据之后，MySQL会寻找机会将这些内存中的记录刷回到磁盘当中。但这就出现一个性能问题，主要有两个方面：

InnoDB中是以页为数据单位与磁盘进行交互的，而一个事务很可能只是修改了一个页上的几个字节，如果将一个完整的数据页刷回磁盘当中，浪费资源；

一个事务可能涉及到多个数据页，这些数据页只是逻辑上连续，在物理上并不连续，使用随机IO性能太差；

因此，MySQL设计了redolog来记录事务对数据页具体做了哪些修改，之后将redolog再刷回磁盘当中。你可能会有疑惑，本来就是想减少io，这不又加上一次io么？InnoDB的设计者在设计之初就已经考虑到了这些。redolog文件一般都比较小，且在刷回磁盘的过程中是顺序io，相比于随机io来说，性能更好。

redo log基本概念 redolog由两部分组成，一个是内存中的日志缓存redo log buffer，一个是磁盘中的日志文件redo log file。当每次对数据记录进行修改的时候，都会将这些修改内容先写入redo log buffer中，后续等待合适的时机将内存中的修改刷回到redo log file中。这种先写日志，再写磁盘的技术就是WAL(Write-Ahead Logging)技术。需要注意的是redolog比数据页先刷回磁盘，聚簇索引，二级索引，undo页面的修改，均需要记录redolog。

在计算机操作系统中，用户空间(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参数配置，各参数值含义如下：

启动innodb的时候，不管上次是正常关闭还是异常关闭，总是会进行恢复操作。恢复时，会先检查数据页中的LSN，如果这个LSN小于redolog中的LSN，即write pos位置，说明在redolog上记录着数据页上尚未完成的操作，接着就会从最近的一个check point出发，开始同步数据。

那有没有可能数据页中的LSN大于redolog中的LSN呢？答案是当然可能。出现这种情况时，这时超出redolog的部分将不会重做，因为这本身就表示已经做过的事情，无需再重做。redo log与binlog区别

假设现在有一条update语句要执行，update from table_name set c=c+1 where id=2，执行流程如下：

redolog 和binlog都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。如果不使用两阶段提交，而是先写其中一个再写另外一个可能会带来一些问题。

此时还是使用update来举例。假设当前id=2，有一个字段c=0，分别分析以下情况：先写redolog再写binlog 假设先写redolog，当redolog写完，但是binlog还未写完的时候，此时MySQL突然出现异常导致重启。由于之前redolog已经写完，系统重启后，修改的记录仍然存在，所以恢复后这一行 c 的值是 1。但由于系统重启，binlog中并未有这条记录。之后备份日志的时候，存起来的binlog里面就没有这条语句。然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的binlog丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。先写binlog再写redolog 假如先写binlog，然后写redolog的时候系统重启。重启之后，redolog中没有对c进行修改的记录，此时c的值还是0。但是 binlog里面已经记录了“把 c 从 0 改成 1”这个日志。所以，在之后用 binlog来恢复的时候就多了一个事务出来，恢复出来的这一行 c 的值就是 1，与原库的值不同。

因此，综上所述，如果是先写某一个日志再写另一个日志，就会出现数据库的状态与使用binlog恢复出来的库的状态不一致的情况。

3、undo log

undolog主要用来记录某条行记录被修改之前的状态，记录的是修改前的数据。这样的话，当事务进行回滚时，就可以通过undolog将记录恢复到事务开始前的样子。事务的原子性和持久性也是依靠undolog来实现的。undo log主要记录了数据的逻辑变化，比如一条INSERT语句，对应一条DELETE的undo log，对于每个UPDATE语句，对应一条相反的UPDATE的undo log，这样在发生错误时，就能回滚到事务之前的数据状态。同时，在进行数据恢复的时候，与binlog，redolog结合使用，保证了数据恢复的正确性。

undolog的作用流程如下所示：

在一个事务当中，可能会对同一条数据进行多次修改，那么是不是每一次修改前的记录都要记录到undolog中呢？这样的话，会导致undolog日志量太大，此时redolog就要上场了。在一个事务当中，如果是对同一条记录进行修改，undolog只会记录事务开始前的原始记录，当再次对这条记录进行修改时，redolog会记录后续的变化。在数据恢复时，redolog完成前滚，undolog完成回滚，二者相互协调完成数据的恢复。过程如下所示： 还有一个功能就是MVCC多版本控制链了，这个请参考这篇文章MySQL之MVCC实现原理

binlog，redolog和undolog是MySQL中最重要的三个日志，在进行数据恢复时，三者进行协调合作，保证数据恢复的正确性。

以上就是完全掌握MySQL三大日志binlog、redo log和undo log的详细内容，更多请关注每日运维其它相关文章！