MySQL日志系统深入解析：Redo Log, Undo Log与Binlog

2024-07-05资讯

今天给大家分享MySQL中的三种核心日志——Redo Log、Undo Log和Binlog，涵盖它们的介绍、作用、存储位置、写入机制、记录格式、特点以及如何管理这些日志。

1. Redo Log（重做日志）

Redo Log记录了对InnoDB存储引擎中数据页修改的物理操作。它的主要目的是确保事务的持久性，即使在系统崩溃时也能保证数据不丢失。当事务提交时，其相关更改首先被记录到Redo Log中，随后才会标记事务状态为已提交。

Redo Log存储在MySQL的数据目录下的`ib_logfile*`文件中，如`/var/lib/mysql/ib_logfile0`和`ib_logfile1`。

Redo Log采用循环写的方式，当一个日志文件写满后会切换到下一个日志文件继续写入。事务提交时，相关日志会立即写入磁盘（即使事务尚未完成），这称为「预写式日志」（Write-Ahead Logging, WAL）策略。

Redo Log记录的是物理日志，即实际对数据页做的修改操作。

● 确保事务的持久性。

● 支持崩溃恢复，通过重做已记录的操作来恢复数据。

Redo Log是循环使用的，不需要手动删除。MySQL会自动管理这些日志文件，旧的日志在新的日志被写满并确认不再需要时会被覆盖。

Undo Log主要用于事务的回滚操作，记录了如何撤销对数据库的修改，以实现事务的原子性。当事务需要回滚时，Undo Log能帮助恢复到事务开始前的状态。

Undo Log存储于InnoDB表空间内，具体位置依赖于表空间配置，一般位于ibdata文件或自定义的表空间文件中。

Undo Log同样采用预写日志方式，事务开始时写入Undo Log，事务提交或回滚后可能会被清理。

Undo Log记录的是逻辑日志，描述了如何反向操作以撤销更改。

● 支持事务的原子性，允许回滚操作。

● 在MVCC（多版本并发控制）中，用于提供历史版本数据。

Undo Log在事务提交且不再需要时会被自动清理，或者在表空间不足时按照一定的策略进行回收。

Binlog记录了MySQL服务器上执行的所有更改数据的SQL语句（除了数据查询语句）。它主要用于数据恢复、主从复制以及数据审计。

Binlog文件默认存储在MySQL的数据目录下（/var/lib/mysql），文件名格式为`mysql-bin.*`。

Binlog采用追加写的方式，新事件不断被添加到日志文件末尾。MySQL支持多种写入模式，包括ROW（记录每一行的变化）、STATEMENT（记录执行的SQL语句）和MIXED（根据情况自动选择ROW或STATEMENT）。

说明：需要开启Binlog日志，才会写入，开启方法一般修改mysql.ini(Windows)和my.cnf配置文件。

Binlog记录的是逻辑日志，根据设置的不同，可以是SQL语句的文本或是行级别的变化。

日志格式	记录内容
Statement	记录进行数据修改 SQL 语句。
Row	记录每一行的数据变更，占用较多空间。（默认）
Mixed	前两者混合，判断是否可能引起数据不一致：可能则用 Row 否则用 Statement

● 支持数据恢复和复制。

● 对于主从复制，是同步数据的关键。

● 可用于审计和数据变更跟踪。

可以通过`PURGE BINARY LOGS`命令手动删除指定的或过期的Binlog文件,或者使用reset 删除全部日志（慎用）

指令	含义
reset master	删除全部日志
purge master logs to 'binlog.xxx'	删除xxx编号之前的日志
purge master logs before 'yyyy-mm-dd hh:mm:ss'	删除引号时间之前产生的日志
show variables like '%binlog_expire_logs_seconds%';	配置日志过期时间，到期自动删除