MySQL中redo log与binlog两阶段提交如何实现？

## 作用 MySQL 中 redo log 和 binlog 是两个相互独立的日志： - redo log 属于 InnoDB 引擎层的物理日志，用于崩溃恢复，保证事务的持久性。 - binlog 属于 Server 层的逻辑日志，用于主从复制和基于日志的数据恢复。 两阶段提交的核心作用是保证 redo log 与 binlog 在逻辑上的一致性，避免数据库崩溃后，原库恢复结果与使用 binlog 恢复出的临时库结果不一致。 如果不使用两阶段提交，可能出现： - **先写 redo log，后写 binlog**：redo log 写完后崩溃，原库恢复出更新；但 binlog 中缺少该事务，使用 binlog 恢复时会少一次更新。 - **先写 binlog，后写 redo log**：binlog 写完后崩溃，由于 redo log 中没有该事务，原库恢复后事务无效；但 binlog 中已有更新，使用 binlog 恢复时会多出一次更新。 ## 原理 两阶段提交分为准备阶段和提交阶段。 ### 1. 准备阶段（prepare） 事务执行更新后： 1. InnoDB 将数据修改写入 redo log。 2. 将 redo log 中该事务标记为 `prepare` 状态，表示事务尚未正式提交。 3. Server 层将事务对应的逻辑变更写入 binlog。 ### 2. 提交阶段（commit） binlog 写入完成后： 1. InnoDB 将 redo log 中该事务的状态从 `prepare` 改为 `commit`。 2. 根据 `sync_binlog` 参数决定 binlog 是否立即刷盘；当 `sync_binlog=1` 时，每次提交都会将 binlog 刷入磁盘。 ### 崩溃恢复规则 MySQL 在崩溃恢复时根据 redo log 和 binlog 的状态判断事务应该提交还是回滚： - 如果 redo log 中事务已经是 `commit` 状态，说明事务已完成提交，直接提交并恢复。 - 如果 redo log 中事务处于 `prepare` 状态，则继续检查对应的 binlog： - 如果 binlog 中存在该事务，并且日志完整，则提交该事务。 - 如果 binlog 不存在或日志不完整，则回滚该事务。 因此，如果在 binlog 已完整写入、redo log 尚未标记为 `commit` 时发生崩溃，恢复时会检查到 binlog 完整，从而继续提交事务，保证两份日志恢复结果一致。