日志(Redo Log、Undo Log、Binlog）

在数据库系统（尤其是 MySQL）中，`binlog`、`redolog`、`undolog` 和 `relaylog` 是四种非常重要的日志类型，它们分别服务于不同的目的，保证了数据库的持久性、一致性、事务性和高可用性。下面逐一详细介绍这四种日志的作用、实现机制，并给出关键代码或配置示例。 --- ### 1. **Redo Log（重做日志）** #### ✅ 作用： - 用于**崩溃恢复（Crash Recovery）**，确保事务的**持久性（Durability）**。 - 记录物理级别的数据页修改，比如“在某个数据页的某个偏移量上写入了某些字节”。 - 属于 InnoDB 存储引擎特有，位于存储引擎层。 #### ✅ 工作原理： - 当事务提交时，InnoDB 会将修改先写入 `redo log buffer`，然后按一定策略刷到磁盘上的 `redo log file`。 - 即使数据库宕机，重启后可以通过重放 redo log 恢复未写入数据文件的已提交事务。 #### ✅ 配置参数（my.cnf）： ```ini [mysqld] innodb_log_file_size = 256M innodb_log_files_in_group = 2 innodb_log_buffer_size = 16M ``` #### ✅ 示例：模拟 redo log 写入流程（伪代码） ```c // 简化版逻辑，实际由 InnoDB 实现 void write_redo_log(MTR *mtr) { // 开始一个 mini-transaction mtr_start(mtr); // 修改页面前，先写 redo 日志 log_write(LOG_PAGE_MODIFY, page_id, offset, new_data); // 刷日志到磁盘（根据 innodb_flush_log_at_trx_commit） if (flush_log_at_commit) { fflush(log_file); fsync(log_file); // 确保落盘 } mtr_commit(mtr); } ``` > ⚠️ 注意：Redo log 是环形写入，写满后覆盖旧日志（但必须确认对应数据已刷盘）。 --- ### 2. **Undo Log（回滚日志）** #### ✅ 作用： - 支持事务的**原子性（Atomicity）**和**MVCC（多版本并发控制）**。 - 记录数据修改前的旧值，用于事务回滚或提供历史版本读取。 #### ✅ 类型： - `INSERT UNDO`：插入操作的反向操作是删除，insert undo 在事务提交后可立即删除。 - `UPDATE/DELETE UNDO`：用于 MVCC，不能立刻清除，直到没有事务需要访问其快照。 #### ✅ 存储位置： - 存储在 `undo tablespace` 中（共享或独立表空间）。 #### ✅ 示例：undo log 结构（伪代码） ```c struct UndoLogRec { int op_type; // INSERT / UPDATE / DELETE Table* table; Row old_row; // 修改前的数据 RollPtr roll_ptr; // 指向前一条 undo 记录，形成链表 }; // 回滚时使用 void rollback_transaction(Transaction* trx) { for (each undo log record in trx) { switch(record->op_type) { case UPDATE: restore_row(record->table, record->old_row); break; case INSERT: delete_row(record->table, record->row_id); break; } } } ``` > 🔍 Undo log + Redo log 组合使用：undo log 本身也要记录 redo，以确保崩溃恢复时能正确重建 undo 链。 --- ### 3. **Binlog（Binary Log，归档日志）** #### ✅ 作用： - 属于 MySQL Server 层，记录所有**逻辑修改语句**（如 `INSERT`, `UPDATE`, `DELETE`），支持： - 数据复制（主从同步） - 数据恢复（基于时间点恢复 PITR） - 审计 #### ✅ 格式（格式由 `binlog_format` 控制）： - `STATEMENT`：记录 SQL 语句（不推荐，可能导致主从不一致） - `ROW`：记录每一行的变化（最安全，推荐） - `MIXED`：混合模式 #### ✅ 启用 binlog（my.cnf）： ```ini [mysqld] log-bin = /var/log/mysql/mysql-bin.log server-id = 1 binlog-format = ROW expire_logs_days = 7 ``` #### ✅ 查看 binlog 内容： ```bash mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 ``` #### ✅ 示例 binlog 内容（ROW 模式）： ```sql ### UPDATE `test`.`users` ### WHERE ### @1=1 ### @2='Alice' ### SET ### @2='Bob' ``` > 🔄 Binlog 是主从复制的基础：主库写 binlog → 从库 IO Thread 拉取 → 写入 relay log → SQL Thread 回放。 --- ### 4. **Relay Log（中继日志）** #### ✅ 作用： - 仅存在于**从库（Slave）**，是主库 binlog 的副本。 - 用于解耦主库数据拉取与执行，提高复制性能和容错能力。 #### ✅ 工作流程： 1. 主库 binlog → 从库 IO Thread → 写入 relay log 2. 从库 SQL Thread 读取 relay log 并执行 #### ✅ 文件结构： - `relay-bin.000001`, `relay-bin.index` - 包含与 binlog 相同格式的内容 #### ✅ 关键参数： ```ini [mysqld] relay-log = /var/log/mysql/relay-bin relay-log-index = /var/log/mysql/relay-bin.index ``` #### ✅ 模拟 relay log 处理流程（伪代码）： ```python def apply_relay_log(): while True: event = read_next_event_from_relay_log() if event.is_query(): execute_sql(event.sql) elif event.is_rows(): for row_change in event.changes: apply_row_change(row_change) update_slave_position() # 更新 master.info 或 GTID ``` > 💡 如果 relay log 损坏，可通过 `CHANGE MASTER TO ... RELAY_LOG_FILE=...` 手动修复。 --- ### 🔄 四种日志的关系图（简化） ``` +-----------+ +------------+ +-----------+ | Binlog |<----| Relay Log |<----| Master | +-----------+ +------------+ +-----------+ ↑ ↓ | ↓ | +--------------+ +---------> | SQL Thread | --> 数据更新 +--------------+ ↑ | +------------------+ | Redo Log | <-- 物理日志，InnoDB 崩溃恢复 | Undo Log | <-- 回滚 & MVCC +------------------+ ``` --- ### ✅ 总结对比表： | 日志类型 | 所属层次 | 作用 | 是否持久化 | 能否用于复制 | |------------|--------------|--------------------------|-------------|---------------| | Redo Log | InnoDB 引擎 | 崩溃恢复，持久性 | 是 | 否 | | Undo Log | InnoDB 引擎 | 回滚、MVCC | 是 | 否 | | Binlog | Server 层 | 归档、复制、恢复 | 是 | 是（主） | | Relay Log | Server 层 | 从库接收并中转主库日志 | 是 | 是（从） | --- ### ❗两阶段提交（Two-Phase Commit, 2PC）确保一致性 为了保证 `redo log` 和 `binlog` 的一致性，MySQL 使用 **XA 两阶段提交**： ```text 1. Prepare Phase: - 写 redo log（状态为 prepare） - 写 binlog 2. Commit Phase: - 写 redo log（状态为 commit） ``` 崩溃恢复时： - 若只有 prepare 状态的 redo log，且能在 binlog 中找到对应事务 → 提交 - 若 binlog 中找不到 → 回滚 --- ###