【MySQL】redolog、undolog和binlog日志文件详解
- 前言
- redolog
- 设计目标
- 记录内容
- 写入策略
- undolog
- 设计目标
- 记录内容
- 写入策略
- binlog
- 设计目标
- 记录内容
- 写入策略
- 小结
前言
当谈论MySQL数据库的日志文件时,通常会涉及到三种主要类型:redo log(重做日志)、undo log(回滚日志)和binlog(二进制日志)。每种日志文件都有自己的设计目标、记录内容和写入策略,下面我会逐一介绍它们。
redolog
设计目标
- 保证事务的持久性:Redo Log的主要设计目标是在数据库崩溃或发生故障时,确保已提交的事务对数据库的修改能够被恢复,以保证数据的持久性。
- 提高性能:通过将数据修改操作写入重做日志,MySQL可以延迟将这些操作同步到磁盘,从而提高数据库的写入性能。
记录内容
- Redo Log中记录了每个事务所做的修改操作,如插入、更新、删除等。这些记录通常以物理日志记录的形式存在,记录的是更新之后的值。
- 除了修改操作的内容外,Redo Log还包含了事务的一些元数据信息,如事务ID、事务状态等。
写入策略
- Redo Log的写入是顺序追加(append)的方式进行的,即将事务的修改操作追加到日志文件的末尾。
- Redo Log采用了WAL(Write-Ahead Logging)的机制,即在事务进行数据修改操作之前,先将对应的修改记录写入Redo Log,然后再将修改应用到内存中的数据页,这样可以确保事务的修改记录先于实际数据的修改被持久化到磁盘。
undolog
设计目标
- 提供事务的回滚支持:Undo Log的主要设计目标是提供事务回滚的支持,即在事务发生错误或被回滚时,能够恢复到事务开始之前的状态。因此undolog能保证事务的原子性。
- 支持MVCC(Multi-Version Concurrency Control):Undo Log也是MVCC机制的重要组成部分,用于存储事务修改前的数据版本,以支持并发读取和写入,从而提高数据库性能。
记录内容
- Undo Log记录了此次事务「开始前」的数据状态,这些记录通常以逻辑日志记录的形式存在,记录的是更新之前的值。
- Undo Log通常以逻辑日志记录的形式存在,记录了事务对数据的修改操作,如将某行数据修改为何种值、删除了哪些数据等。
写入策略
- Undo Log的写入通常也是顺序追加的方式进行的,将事务的逆操作记录追加到日志文件的末尾。
- Undo Log的写入顺序通常与事务的提交顺序相反,即先写入的事务的Undo Log记录会位于后面,这样可以确保在回滚操作时按照相反的顺序进行恢复。
binlog
设计目标
- 恢复(recovery):某些数据的恢复需要二进制日志,例如,在一个数据库全备文件恢复后,用户可以通过二进制日志进行point-in-time的恢复。
- 复制(replication):其原理与恢复类似,通过复制和执行二进制日志使一台远程的MySQL数据库(一般称为slave或standby)与一台MySQL数据库(一般称为master或primary)进行实时同步。
- 审计(audit):用户可以通过二进制文件中的信息来进行审计,判断是否有对数据库进行注入的攻击。
记录内容
- Binlog记录了数据库中的修改操作,包括对表的增删改操作以及对表结构的变更操作等。
- Binlog以一种较为简洁的格式记录了每个修改操作的元信息,如操作类型、受影响的表名、修改前后的数据等。
写入策略
- Binlog的写入通常是异步的,即MySQL会将修改操作先写入到Binlog缓冲区中,然后由后台线程将缓冲区中的内容定期写入到Binlog文件中。
- 对于复制从库,Binlog的写入通常会在事务提交后立即进行,以确保从库能够尽快获取到主库的数据变更。
小结
-
redo log(重做日志):是 Innodb 存储引擎层生成的日志(它是物理日志,记录的是数据的物理修改信息)。实现了事务中的持久性,主要用于掉电等故障恢复。redo log 记录了此次事务「完成后」的数据状态,记录的是更新之后的值;
-
undo log(回滚日志):是 Innodb 存储引擎层生成的日志(它是逻辑日志,记录的是数据的逻辑修改信息)。实现了事务中的原子性和一致性,主要用于事务回滚和 MVCC。
-
binlog(归档日志):是 Server 层生成的日志,主要用于数据备份和主从复制。