Mysql整理记录Day3
接上篇，mysql更新语句执行流程，我们了解了更新语句的执行流程，涉及到两部分日志：redo log和binlog，下面我们再深入聊聊这部分东东。
下面我们来分析以下，在两阶段提交的不同时刻，Mysql发生异常重启会发生什么？
时刻A:
此时由于 binlog 还没写，redo log 也没提交，所以崩溃恢复的时候，这个事务会回滚。因为还没写bin log
，所以也不会传到备库里（备库需要消费bin log来与主库保持一致）。
时刻B
此刻，binlog 写完，redo log还没有commit，发生了 crash，mysql 崩溃恢复是如何处理的呢？
mysql是这么处理的
- 如果redo log的事务是完整的，也就是有了commit标识，则直接提交
- 如果redo log的事务只有完整的prepare，则需要根据binlog的完整性，决定回滚还是提交;
1. 如果binlog完整，则提交事务
2. 否则，回滚事务
因为 mysql 有一项崩溃恢复逻辑，prepare的redo log + 完整的binlog，则提交事务。这里有小伙伴就要问了，为什么需要提交事务？因为binlog里有这条记录，在传到备库里会被执行，所以主库也需要提交事务，来保证数据的一致性。
崩溃恢复的时候，mysql是怎么知道binlog是否完整的？
上篇文章我们知道了，binlog 有两种格式，statement 和 row 。
- statement 格式的 binglog，最后会有 COMMIT；
- row 格式的 binlog，最后会有一个 XID event。
另外，在 mysql5.6.2 版本之后，还引入了 binlog-checksum 参数，用来验证 binlog 内容的正确性。
笔记参考于极客时间《MySQL实战45讲》
