本文分析了MySQL 8.0与5.7在故障恢复上的区别，特别是InnoDB在事务gtid持久化中的作用。在8.0中，事务gtid写入InnoDB的undo日志，导致恢复时gtid_executed表的更新策略改变。随着版本发展，InnoDB的重要性和Binlog的角色调整引发对未来MySQL复制和存储引擎功能的思考。
最近在调试MySQL新功能发现MySQL 8.0相比5.7版本在mysqld crash recovery上有较大不同点，有必要记录下。主要包括事务gtid持久化到mysql.gtid_executed方式和InnoDB在其中发挥的作用。并延伸分析未来MySQL版本对InnoDB的定位。
MySQL 5.7故障恢复逻辑
关于这块实现，网上有很多文章，这里不再展开，结合下图直接说主逻辑：
1. MySQL扫描最后一个Binlog文件file3，搜集其中的每个事务xid集合，集合中的事务均已提交； 2. InnoDB存储引擎通过redo和undo进行recovery，基于上一步传入的xid集合来决定处于prepare状态的事务应该commit还是rollback，r1中的事务commit，r2中的事务rollback； 3. 若开启gtid模式，file1和file2中的事务gtid均已写入gtid_executed表，MySQL层会扫描file3事务gtid信息，将gtid 201~280插入表中；
这里补充说明下两点： - 在步骤1中，除了收集xid集合，还会检查binlog event的完整性，如果有损坏的event，那么 会将Binlog文件大小截取/truncate到第一个有损坏的binlog event前； - 针对步骤3，有同学可能会问，为什么不在步骤1就收集gtid加入mysql.gtid_executed？因为那是InnoDB还没有完成数据恢复，对应的InnoDB表是不可用的；而且相比Binlog和InnoDB故障恢复，gtid系统的初始化并不是非常紧迫，因此放后执行。
<
最低0.47元/天 解锁文章
429
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
