mysql的崩溃是怎么保证安全的

我们都直到mysql通过redolog来保证崩溃时的恢复的，并且是通过二阶段提交来实现的，即：

1.先写redolog，然后redolog进入prepare状态
2.写binlog，然后redolog做commit，同时事物也返回结果
如图：

mysql就crash怎么办？

1.如果在时刻A，mysql就crash了，事物因为还处于未提交的状态，就会进行回滚。

2.如果在时刻B，mysql就crash了，那么就要判断redolog中的事物是否有commit标识，有就提交。

如果没有commit标识，那么就要判断binlog中是否与redolog一致，并且完整，如果是就commit，否则就rollback

如何判断binlog内容完整呢？

如果是statement 格式的 binlog，最后会有 COMMIT；

如果是row 格式的 binlog，最后会有一个 XID event。

redolog和binglog是如何关联的呢？

通过XID去关联，redolog和binlog中都有这个XID，崩溃重启时，会扫redolog，如果自己有prepare和commit就直接提交，如果有prepare，没commit，那么就通过XID去binglog中找，有就commit，没就rollback

为什么要这样设计恢复逻辑呢？
因为保证了，redolog和binlog的一致性，就是保证了主库和从库数据的一致性，因为从库是通过binlog去做同步的