MySQL 的binlog 、undolog 、redolog

news2024/9/20 0:03:22

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号文件开头。