一、为什么需要两阶段提交 1.1 核心问题 MySQL 需要保证两个日志的一致性: redo log (InnoDB 引擎层) binlog (MySQL Server 层) 如果不使用两阶段提交,会导致主从数据不一致。 1.2 两个日志的作用 日志 层级 作用 格式 redo log InnoDB 引擎 崩溃恢复,保证持久性 物理日志(页修改) binlog MySQL Server 主从复制,数据备份 逻辑日志(SQL语句) 为什么不能只用一个日志? redo log 是 InnoDB 特有,其他引擎(MyISAM)没有 binlog 是 Server 层,所有引擎共享 历史原因: binlog 先存在,redo log 后加入 1.3 不用两阶段提交的后果 场景1: 先写 redo log,后写 binlog 1 UPDATE users SET balance = 900 WHERE id = 1; 执行流程: 1. 写 redo log ✅ 2. 【此时崩溃】 3. binlog 未写入 ❌ 后果: ...
MySQL 内部两阶段提交（2PC）深度解析 一、背景与问题起源 MySQL 的存储架构分为两层： Server 层：负责 SQL 解析、优化、执行，以及 binlog 的写入 引擎层（InnoDB）：负责数据的实际存储，以及 redo log 的写入 这两层各自维护一套日志体系，当一个事务提交时，需要同时保证两套日志的一致性。若没有协调机制，极易造成数据不一致。 为什么两个日志会不一致？ 假设没有 2PC，先写 redo log，再写 binlog： [事务 T1 执行 UPDATE] → 写入 redo log（状态：commit） → MySQL 崩溃 💥 → binlog 未写入 恢复后： InnoDB 重放 redo log，T1 数据存在 从库通过 binlog 同步，T1 不存在 主从数据不一致！ 假设没有 2PC，先写 binlog，再写 redo log： [事务 T1 执行 UPDATE] → 写入 binlog → MySQL 崩溃 💥 → redo log 未写入 恢复后： InnoDB 没有 redo log，T1 回滚（数据不存在） 从库通过 binlog 同步，T1 被执行 主从数据不一致！ 正是因为这两种情况都会造成主从不一致，MySQL 引入了内部两阶段提交（Internal 2PC）。 ...