MySQL undolog、redolog、binglog

在 MySQL 中，`undolog`、`redolog` 和 `binlog` 是三种重要的日志类型，它们在数据一致性、事务管理和数据恢复中扮演着重要角色。以下是它们的作用以及写入和刷盘的时机： --- ### 1. **Undo Log** #### **作用**： - **回滚事务**：当事务失败或显式回滚时，`Undo Log` 用于撤销已执行的更改，恢复到事务开始前的状态。 - **MVCC（多版本并发控制）**：在 InnoDB 中，`Undo Log` 还用于支持 MVCC，提供一致性读（快照读）。 #### **写入时机**： - 在事务执行过程中，修改数据之前会生成对应的 `Undo Log`，并将其记录到内存中。 #### **刷盘时机**： - `Undo Log` 通常存储在表空间中，随着事务提交或数据页刷盘时，`Undo Log` 也会被刷到磁盘。 --- ### 2. **Redo Log** #### **作用**： - **崩溃恢复**：`Redo Log` 用于记录数据的物理更改（如页的修改），即使数据库崩溃，也可以通过 `Redo Log` 恢复到最近一次提交的状态。 - **提高性能**：通过先写 `Redo Log` 再写数据页的方式，减少频繁的磁盘 I/O。 #### **写入时机**： - 当事务对数据进行修改时，`Redo Log` 会先写入到内存中的 `Redo Log Buffer`。 #### **刷盘时机**： - `Redo Log` 刷盘的时机由 `innodb_flush_log_at_trx_commit` 参数控制： - `0`：事务提交时不刷盘，定期由后台线程刷盘。 - `1`（默认）：事务提交时立即刷盘，保证事务的持久性。 - `2`：事务提交时写入操作系统缓存，定期刷盘。 --- ### 3. **Binlog** #### **作用**： - **数据恢复**：`Binlog` 是逻辑日志，记录了所有的 DML 和 DDL 操作（以事件形式），可以用于基于时间点的恢复。 - **主从复制**：`Binlog` 是 MySQL 主从复制的核心，主库通过 `Binlog` 将数据变更同步到从库。 #### **写入时机**： - 在事务提交时，`Binlog` 会先写入到内存中的 `Binlog Buffer`。 #### **刷盘时机**： - `Binlog` 刷盘的时机由 `sync_binlog` 参数控制： - `0`：事务提交时不刷盘，定期由后台线程刷盘。 - `1`：事务提交时立即刷盘，保证 `Binlog` 的持久性。 - `>1`：事务提交时写入操作系统缓存，定期刷盘。 --- ### **三者的关系** 1. **事务提交顺序**： - 先写 `Redo Log`，标记为 "prepare" 状态。 - 再写 `Binlog`。 - 最后将 `Redo Log` 标记为 "commit" 状态。 2. **崩溃恢复**： - 如果 `Redo Log` 中有 "prepare" 状态但没有 "commit" 状态，说明事务未提交，需要回滚。 - 如果 `Binlog` 和 `Redo Log` 都完整，事务可以恢复。 --- ### **总结** | 日志类型 | 作用 | 写入时机 | 刷盘时机（可配置） | |------------|--------------------------|---------------------------|---------------------------| | Undo Log | 回滚事务，支持 MVCC | 数据修改前 | 事务提交或数据页刷盘时 | | Redo Log | 崩溃恢复，提升性能 | 数据修改时 | 事务提交时（`innodb_flush_log_at_trx_commit`） | | Binlog | 数据恢复，主从复制 | 事务提交时 | 事务提交时（`sync_binlog`） | 通过合理配置这些日志的刷盘策略，可以在性能和数据安全性之间找到平衡。