Redo Log断电恢复逻辑

在MySQL InnoDB中，当Redo Log处于PREPARE状态但尚未标记为COMMIT时，若发生断电，数据是否丢失取决于Binlog是否成功持久化。以下是详细分析：

1. 两阶段提交（2PC）的核心逻辑

InnoDB通过两阶段提交确保事务的持久性和一致性：

1. Prepare阶段：

   • Redo Log写入磁盘，状态标记为PREPARE。

   • 保证事务的物理修改已持久化到Redo Log。

2. Commit阶段：

   • Binlog写入磁盘（若开启）。

   • Redo Log状态更新为COMMIT，事务正式提交。

2. 断电场景的恢复机制

若在PREPARE阶段断电，崩溃恢复时MySQL会执行以下操作：

1. 扫描Redo Log：

   • 找到所有状态为PREPARE的事务。

2. 检查Binlog的完整性：

   • 若对应事务的Binlog已完整写入且刷盘，则认为事务应提交，执行Redo Log重放（COMMIT）。

   • 若Binlog未写入或写入不完整，则认为事务未提交，执行回滚（ROLLBACK）。

3. 数据是否丢失？

• 情况1：Binlog已持久化

  • 即使Redo Log未标记为COMMIT，事务仍会被提交，数据不丢失。

  • 恢复时，通过Redo Log重放修改，保证数据一致性。

• 情况2：Binlog未持久化

  • 事务会被回滚，数据丢失。

  • 此时事务视为未提交，Undo Log用于撤销内存中的修改。

4. 关键配置参数的影响

• innodb_flush_log_at_trx_commit

  • =1：每次事务提交时Redo Log刷盘（确保PREPARE阶段持久化）。

  • =0/2：可能延迟刷盘，增加数据丢失风险。

• sync_binlog

  • =1：每次事务提交时Binlog刷盘（确保Binlog持久化）。

  • =0/N：延迟刷盘，可能丢失最近N个事务的Binlog。

5. 总结

建议

• 高可靠性配置：

  innodb_flush_log_at_trx_commit = 1  # 每次提交刷Redo Log
  sync_binlog = 1                     # 每次提交刷Binlog
  

  此配置以牺牲部分性能为代价，确保数据零丢失。

• 权衡性能与安全：

  • 若允许极小概率的数据丢失（如秒级异步复制），可适当降低参数值。

  • 金融级场景必须采用1配置，并结合全同步复制（Group Replication）或半同步复制。

流程图：崩溃恢复逻辑

崩溃恢复
  │
  ↓
扫描所有Redo Log的PREPARE事务
  │
  ↓
对每个PREPARE事务：
  ├─ 检查Binlog是否存在且完整？  
  │    ├─ 是 → 提交事务（重放Redo Log）  
  │    └─ 否 → 回滚事务（使用Undo Log）  
  ↓
完成恢复，数据库进入一致状态

通过合理配置和两阶段提交机制，即使Redo Log未标记为COMMIT，MySQL仍能保证数据不丢失（前提是Binlog已持久化）。