当前位置：首页 > news >正文

MySQL 的binlog 、undolog 、redolog

news 2025/9/9 18:22:18

Binlog (二进制日志)

bin Log 作用

用于记录所有修改数据库数据的 SQL 语句或行级别的变化，主要用于主从复制和数据恢复。

binlog格式

STATEMENT模式：binlog里面记录的就是SQL语句的原文。优点是并不需要记录每一行的数据变化，减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致
ROW模式：不记录每条SQL语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了，解决了STATEMENT模式下出现master-slave中的数据不一致。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨
MIXED模式：以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式

示例 1：使用不确定函数
某些情况下，使用不确定函数（如 UUID()、NOW() 等）会导致 STATEMENT 模式无法复制，因为每次执行时返回的结果可能不同。此时，ROW 模式可以准确记录每行数据的变化。

INSERT INTO my_table (id, value) VALUES (UUID(), NOW());

在 STATEMENT 模式下，这条语句可能在主库和从库中插入不同的 UUID 和 NOW 值。而在 ROW 模式下，每行数据的具体值会被记录并复制到从库。

示例 2：复杂事务
复杂事务中可能包含多个步骤，每一步骤都会影响数据的一致性。在这种情况下，使用 ROW 模式可以确保每个步骤的结果都被准确记录和复制。

BEGIN;
UPDATE my_table SET value = value + 1 WHERE id = 1;
DELETE FROM my_table WHERE id = 2;
INSERT INTO my_table (id, value) VALUES (3, 'test');
COMMIT;

在 STATEMENT 模式下，每个语句会被记录并在从库执行，但如果有依赖顺序或其他条件的语句，可能导致复制不一致。而在 ROW 模式下，每行数据的变化都会被准确记录。

bin Log记录顺序

在事务提交之前，MySQL 会将事务的所有修改记录到 binlog cache（binlog 缓冲区）。
当事务提交时，MySQL 会将 binlog cache 中的内容写入磁盘上的 binlog 文件。
MySQL 保证 binlog 写入后，事务才会真正提交。

Redo Log(重做日志)

MySQL里常说的WAL技术，全称是Write Ahead Log，即当事务提交时，先写redo log，再修改页。

也就是说，当有一条记录需要更新的时候，InnoDB会先把记录写到redo log里面，并更新Buffer Pool的page，这个时候更新操作就算完成了

Buffer Pool是物理页的缓存，对InnoDB的任何修改操作都会首先在Buffer Pool的page上进行，然后这样的页将被标记为脏页并被放到专门的Flush List上，后续将由专门的刷脏线程阶段性的将这些页面写入磁盘。

Redo Log 作用

用于保证事务的持久性（即使数据库崩溃后，也能恢复到最新的提交状态）。

Redo Log 结构

InnoDB的redo log是固定大小的，比如可以配置为一组4个文件，每个文件的大小是1GB，循环使用，从头开始写，写到末尾就又回到开头循环写（顺序写，节省了随机写磁盘的IO消耗）
在这里插入图片描述
Write Pos是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。

Check Point是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件

Write Pos和Check Point之间空着的部分，可以用来记录新的操作。如果Write Pos追上Check Point，这时候不能再执行新的更新，需要停下来擦掉一些记录，把Check Point推进一下

当数据库发生宕机时，数据库不需要重做所有的日志，因为Check Point之前的页都已经刷新回磁盘，只需对Check Point后的redo log进行恢复，从而缩短了恢复的时间

当缓冲池不够用时，根据LRU算法会溢出最近最少使用的页，若此页为脏页，那么需要强制执行Check Point，将脏页刷新回磁盘。

Redo log buffer刷盘

InnoDB首先将redo log放入到redo log buffer，然后按一定频率将其刷新到redo log file

下列三种情况下会将redo log buffer刷新到redo log file：

Master Thread每一秒将redo log buffer刷新到redo log file
每个事务提交时会将redo log buffer刷新到redo log file
当redo log缓冲池剩余空间小于1/2时，会将redo log buffer刷新到redo log file

Redo Log 记录顺序

当事务开始时，MySQL 会将对数据的修改先写入内存中的缓冲区。
在事务进行过程中，对数据的修改会先写入 redo log buffer（重做日志缓冲区）。
当事务提交时，MySQL 会将 redo log buffer 中的数据刷新（fsync）到磁盘上的 redo log 文件。
一旦 redo log 写入成功，事务才算真正提交。

Undo Log (回滚日志)

Undo Log 作用

用于支持事务的回滚操作，保证数据的一致性和隔离性。

Undo Log记录顺序

当一个事务对数据进行修改前，会先记录一份旧的数据快照到 undo log。
如果事务需要回滚，MySQL 会使用 undo log 将数据恢复到修改前的状态。
undo log 在事务提交后，会被标记为可删除状态，并在后台逐步清理。

Binlog 、Undolog 、Redolog整体执行顺序

在一个事务的生命周期内，这些日志的记录顺序通常如下：

开始事务

对数据进行修改：

写入 undo log。
写入 redo log buffer。
写入 binlog cache。

事务提交：

刷新 redo log buffer 到磁盘。
写入 binlog cache 到 binlog 文件。
事务提交完成，数据对外可见。

Mysql 异常恢复机制

Undo Log

作用：Undo log 用于回滚未提交的事务，并支持多版本并发控制（MVCC）。
恢复：当 MySQL 重启时，会使用 undo log 回滚所有未提交的事务，以确保数据库处于一致的状态。

MySQL 会扫描 undo log，找到所有未提交的事务，并逐一回滚这些事务的操作。

Redo Log

作用：Redo log 记录已提交事务的修改，用于崩溃恢复。
恢复：当 MySQL 重启时，会使用 redo log 重做所有已提交但尚未刷入数据文件的事务。

MySQL 会扫描 redo log，将所有已提交的事务重新应用到数据文件中，确保数据持久化。

Binlog

作用：Binlog 用于记录所有修改数据的 SQL 语句或行级别的变化，主要用于主从复制和数据恢复。
恢复：在 MySQL 异常后，binlog 保证事务提交的持久性。

事务在提交之前，binlog cache 的内容会刷新到 binlog 文件。
如果 MySQL 在事务提交前崩溃，binlog 中不会有该事务的记录，确保了数据的一致性。

综上

Undo Log：在修改数据前记录旧数据快照，支持事务回滚，保证数据一致性和隔离性。

Redo Log：事务修改的数据先写入 redo log buffer，事务提交时刷新到磁盘，保证事务持久性。

Binlog：在事务提交之前记录所有修改到 binlog cache，事务提交时写入 binlog 文件，支持主从复制和数据恢复。

通过这种日志记录机制，MySQL 能够在发生故障时恢复数据，并保证数据的一致性和持久性。