bin log、redo log、undo log | Mikez Namespace

binlog、redo log 和 undo log 是数据库系统（特别是 MySQL）中的三种重要日志，用于实现数据持久性、恢复和一致性。它们各自有不同的作用和用途，以下是对这三种日志的详细解释：

1. `binlog`（Binary Log）

定义：binlog 是 MySQL 中的二进制日志，记录了所有对数据库进行更改的操作，包括 INSERT、UPDATE、DELETE 等语句，但不包括查询语句（SELECT）。
用途：
- 数据恢复：当数据库崩溃时，可以通过 binlog 进行数据恢复，从备份后的某个时间点恢复到崩溃前的状态。
- 主从复制：在主从复制环境中，binlog 是实现数据同步的核心机制。主服务器将写操作记录到 binlog，从服务器读取并重放这些日志以保持同步。
存储格式：binlog 以二进制格式存储，并且按顺序记录每个事务的所有更改，支持 ROW、STATEMENT 和 MIXED 三种日志格式。

2. `redo log`

定义：redo log 是 MySQL InnoDB 存储引擎中的重做日志，用于保证事务的持久性（即 D in ACID）。它记录了已经提交的事务对数据页的物理更改。
用途：
- 崩溃恢复：在系统崩溃后，InnoDB 使用 redo log 恢复尚未持久化到磁盘的数据页，以确保已经提交的事务不丢失。
- 写入策略：事务提交后，MySQL 并不会立即将数据写入磁盘，而是将更改先写入 redo log，然后通过后台进程将数据异步刷新到磁盘中，这种机制称为“预写式日志”。
日志格式：redo log 记录了数据页的物理更改，并以固定大小的循环缓冲区存储。当日志写满时，会覆盖最早的日志内容。

3. `undo log`

定义：undo log 是 MySQL InnoDB 存储引擎中的回滚日志，记录了事务在执行过程中产生的对数据库的逻辑更改，主要用于实现事务的回滚和多版本并发控制（MVCC）。
用途：
- 事务回滚：当事务被撤销时，InnoDB 使用 undo log 将数据恢复到事务开始前的状态，确保事务的原子性（即 A in ACID）。
- MVCC：undo log 支持 MVCC 机制，允许并发的事务以一致的视图访问数据。例如，在一个事务执行 UPDATE 操作时，undo log 记录了被修改前的旧值，从而其他事务可以读取到事务开始时的数据快照。
存储方式：undo log 记录的是逻辑操作，例如删除一条记录会记录下被删除的行数据。undo log 通常存储在特殊的回滚段中。

三者关系与工作流程

当事务开始时，数据的旧版本会被记录到 undo log 中，便于回滚和 MVCC 机制的实现。
当事务提交时，MySQL 会将修改写入 redo log，这时事务被视为持久化，但修改的数据页可能尚未写入磁盘。
redo log 和 binlog 会被分别写入，用于恢复和复制操作。redo log 确保系统崩溃后数据的持久性，而 binlog 记录所有变更，支持数据恢复和主从复制。
在事务提交的过程中，MySQL 会首先将事务的操作记录到 redo log，然后再更新 binlog。如果系统崩溃，可以通过 redo log 恢复已提交但未写入磁盘的数据；而 binlog 则用于数据恢复和主从复制。

总结

binlog：主要用于数据恢复和主从复制，记录所有修改操作。
redo log：用于崩溃恢复，记录数据页的物理更改，确保事务的持久性。
undo log：用于事务回滚和 MVCC，记录事务开始前的数据状态。

理解这三种日志的区别和用途对于掌握数据库的持久性和一致性机制至关重要。