本文共 1572 字，大约阅读时间需要 5 分钟。
在数据库管理中，日志系统是确保数据一致性和恢复能力的关键环节。MySQL 中最重要的两个日志模块是 redo log 和 binlog，它们分别承担不同的功能。理解这些日志模块的工作原理，可以帮助我们更好地理解 MySQL 的 crash-safe 能力以及数据恢复机制。
Redo log 是 InnoDB 引擎特有的日志系统，主要用于保证数据库的 crash-safe能力。其工作原理类似于酒店掌柜记录赊账的例子：先在“粉板”上记录操作，然后待空闲时将记录写入“账本”（数据文件）。
循环写入机制
Redo log 是固定大小的，比如可以配置为 4 个文件，每个文件大小为 1GB。操作会从第一个文件开始循环写入。当写入完最后一个文件后，下一次操作会继续写入第一个文件，形成环形结构。写入过程
当有一条更新操作（如update T set c=c+1 where ID=2）执行时，InnoDB 引擎先将修改记录到 redo log 中，并立即更新内存中的数据。redo log 的当前写入位置（write pos）会向前移动，直到所有操作记录完毕。检查点（Checkpoint）
定期检查点时，系统会将 redo log 中尚未写入数据文件的部分记录复制到数据文件中，并清空这部分 redo log。这样，数据文件就保留了所有持久化的操作记录。Crash-Safe能力
由于 redo log 记录了所有操作，且在异常重启时会将未写入数据文件的 redo log 复制到数据文件中，InnoDB 引擎可以保证即使数据库崩溃，数据也不会丢失。Binlog 是 MySQL Server 层的日志系统，主要用于记录所有的 SQL 语句和事务。它与 redo log 的区别在于：
在数据库系统中，两阶段提交是确保数据日志的一致性的重要机制。它的核心思想是：
Prepare 阶段
数据引擎首先将所有修改记录到 redo log 中，并通知执行器，可以提交事务。Commit 阶段
执行器生成 binlog 并写入磁盘，然后通知引擎将 redo log 从 prepare 状态提交到数据文件中，完成事务。两阶段提交的关键在于确保两份日志的逻辑一致。如果 binlog 或 redo log 中存在不一致的情况，可能会导致数据库状态与日志恢复的状态不符。
今天我们讨论了 MySQL 中的核心日志模块及其工作原理。Redo log 负责 crash-safe 能力，而 binlog 负责记录所有 SQL 语句。两阶段提交机制确保了两份日志的逻辑一致性，从而保证了数据库的稳定性和可恢复性。
在实际操作中，建议将以下参数配置为 1：
innodb_flush_log_at_trx_commit = 1：确保每次事务的 redo log 立即持久化到磁盘。sync_binlog = 1：确保每次事务的 binlog 立即持久化到磁盘。如果你对数据库的恢复能力感兴趣，定期全量备份的周期也会影响系统的性能和恢复时间。在高负载系统中，一天一备可能比一周一备更有优势，因为它可以更快速地恢复到最近的状态，从而减少数据丢失的风险。
转载地址：http://jzybz.baihongyu.com/