MySQL三大日志—— binlog、redoLog、undoLog 详解

前言：

日志是mysql数据库的重要组成部分，记录着数据库运行期间各种状态信息，能帮助我们进行很多容错及分析工作，其中有三大日志与我们这些开发者息息相关，本文将介绍binlog、redoLog、undoLog三种日志：

1. redoLog 重做日志

在数据库系统中，重做日志（redo log）用于确保在发生故障时数据的完整性和一致性。重做日志缓冲区（redo log buffer）是内存中的一段区域，用于临时存储待写入磁盘的重做日志记录。

当数据库系统执行数据更改（如INSERT、UPDATE、DELETE）时，这些操作会先记录在重做日志缓冲区中。然后，数据库会在适当的时间将这些重做日志缓冲区的内容写入重做日志文件中，以便在系统故障时可以重放这些日志来恢复数据。

在实际的数据库实现中，例如Oracle或MySQL，写入重做日志到磁盘的操作通常是异步进行的，以提高性能。当事务提交时，重做日志缓冲区的内容可能并不立即刷新到重做日志文件，而是由后台进程定期进行。

以下是一个简化的伪代码示例，描述了重做日志缓冲区内容的写入过程：

-- 假设的数据库操作
BEGIN TRANSACTION;
-- 更新操作
UPDATE table_name SET column_name = 'new_value' WHERE condition;
-- 将重做日志缓冲区内容写入重做日志文件
WRITE_REDO_LOG_TO_FILE();
COMMIT TRANSACTION;

1.1 为什么需要redo log

我们都知道，事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。

事务在运行过程中，都是在内存的Buffer Pool修改页面，事务提交后，这些被修改后的脏页并不会立刻刷盘（立刻刷盘开销太大，一方面是一个页面可能就修改了一点点，将整个页面刷盘不值当，另一方面是一个事务会涉及不同的页面，如果将这些页面都刷盘会产生很多的随机IO）。
但如果不采取其他措施，那么在事务提交后MySQL发生故障，导致内存中数据丢失，那么这个已提交事务作出的更改也会丢失。

那么mysql是如何保证内存和磁盘的一致性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面：

因为Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了！
一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差！

所以这里就需要引入redo日志，对任意页面进行修改的操作都会生成redo日志，在事务提交时，只要保证生成的redo日志成功落盘即可，这样，即使MySQL发生故障导致内存中的数据丢失，也可以根据已落盘的redo日志恢复数据。

1.2 redo log的基本概念

redo log是InnoDB存储引擎层的日志，又称重做日志文件，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。一个事务生成的redo日志是按顺序写入磁盘的，是顺序IO，在实例和介质失败（media failure）时，redo log文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用 redo log恢复到掉电前的时刻，以此来保证数据的完整性。

redo log包括两部分：

一个是内存中的日志缓冲(redo log buffer)
另一个是磁盘上的日志文件(redo log file)

mysql每执行一条DML语句，先将记录写入redo log buffer，后续某个时间点再一次性将多个操作记录写到redo log file。这种先写日志，再写磁盘的技术就是MySQL里经常说到的WAL(Write-Ahead Logging) 技术。

1.3 redo log记录形式

redo log日志的大小是固定的，即记录满了以后就从头循环写。
redolog记录方式：

简单的redo日志 —— 记录哪个表空间中的哪个页面从哪个位置开始的多少个节点要修改成什么
复杂的redo日志 —— 记录了对哪个表空间的哪个页面进行修改，存储了对该页面进行修改操作的一些必备要素，重启时，MySQL会根据redo日志的类型，将redo日志中的必备要素作为参数，调用日志类型对应的函数，恢复数据。

在计算机操作系统中，用户空间(user space)下的缓冲区数据一般情况下是无法直接写入磁盘的，中间必须经过操作系统内核空间(kernel space)缓冲区(OS Buffer)。

因此，redo log buffer 写入redo log file实际上是先写入OS Buffer，然后再通过系统调用fsync()将其刷到redo log file中。

2.binlog

2.1 binlog基本概念

binlog是属于MySQL Server层面的，又称为归档日志，属于逻辑日志，是以二进制的形式记录的，用于记录数据库执行的写入性操作(不包括查询)信息，依靠binlog是没有crash-safe能力的

啥是逻辑日志啥是物理日志：
逻辑日志：可以简单理解为记录的就是sql语句
物理日志：因为mysql数据最终是保存在数据页中的，物理日志记录的就是数据页变更

另外，binlog是通过追加的方式进行写入的，可以通过max_binlog_size参数设置每个binlog文件的大小，当文件大小达到给定值之后，会生成新的文件来保存日志。

2.2 binlog使用场景

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

主从复制：在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。
数据恢复：通过使用mysqlbinlog工具来恢复数据。

总结：确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。

2.3 binlog日志格式

binlog日志有三种格式，分别为STATMENT、ROW 和 MIXED。

在 MySQL 5.7.7之前，默认的格式是STATEMENT，MySQL 5.7.7之后，默认值是ROW。日志格式通过binlog-format指定。

STATMENT 基于SQL语句的复制(statement-based replication, SBR)，每一条会修改数据的sql语句会记录到binlog中。 优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO, 从而提高了性能； 缺点：在某些情况下会导致主从数据不一致，比如执行sysdate()、slepp()等。
ROW 基于行的复制(row-based replication, RBR)，不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了。 优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题； 缺点：会产生大量的日志，尤其是alter table的时候会让日志暴涨
MIXED 基于STATMENT和ROW两种模式的混合复制(mixed-based replication, MBR)，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog