MySQL深入：binlog及事务日志总结

注意点：提问

1.二进制日志和事务日志执行顺序？谁先写？

• 推测1.事务日志 先写，redo/undo在平常修改的时候就开始一直记录，不过是写到cache中，然后数据修改完毕后进入prepare阶段，进行二阶式提交，先写事务日志，再写binlog：https://www.csdn.net/gather_2f/MtTaMgwsNzU4NC1ibG9n.html
• 推测2.二进制日志先写，：https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html

• 最终结论：见上图，上面说的redo log一直写是指在未开启binlog写时候，一般类似于单机模式下，不存在主从复制问题，这个时候在commit前的写操作就不会涉及到一致性问题，但是一旦开启了binlog等，涉及到了主从复制的问题，假如commit事务，这个时候在commit之前会先写binlog日志罗盘并同步给salve，假如此时master库宕机，再次启动会回滚事务，但是从库已经执行，就会造成主备不一致问题。还是先写事务日志，进入prepare阶段后，设置标记，写入事务日志，第二步才写入binlog日志，commit事务：二阶式提交解决一致性问题，组提交方式提高io性能瓶颈
  参照：https://www.cnblogs.com/mao3714/p/8734838.html

2.有了二进制日志为什么还要有事务日志？

• MySQL宕机后，需要根据redo日志中checkpoint找到最近一次的点，进行数据恢复，恢复策略有两种，见上方3的两种情况
• 假如没有redo，在事务提交之前，二进制日志写入后同步到了从库，假如此时突然宕机，从库可能已经应用了binlog同步的数据，而主库丢失本次更新，就会导致主从数据不一致的情况

3.二进制日志和事务日志的一致性问题？描述一下：https://www.jianshu.com/p/4bcfffb27ed5

• 二阶制提交，1.置prepare状态，write/fsync redo日志落盘；2.write/fsync binlog 落盘，2.2indoDB事务提交（内存提交）
• 下图：

4.二进制日志目的？实现了什么？有什么缺陷？会丢失数据吗？

• 主从复制
• 异常情况数据恢复依据
• 单独有binlog不行，会丢失数据，会导致数据不同步，需要配合redo一起使用才行（防止主从数据不一致）

5.redo log实现了什么？有什么缺陷，会丢失数据吗？

• 宕机异常数据恢复，MySQL重启会自动检查redo日志，假如采用每次事务提交就刷盘的方式，那么也不会丢失数据，因为即使redo pool缓存数据还没有刷盘就宕机，当时此时候数据也没有进行提交，相当于丢失了这一次操作而已，不影响数据的完整性

6.有了redo为什么还要有二进制日志？

• redo log大小固定，日志落盘后会覆盖写，无法用于数据恢复，回滚等；
• redo属于innoDB独有。

都要尽量顺序写入，顺序写入比随机写入快很多，redo cache写入算是顺序写入，再批量刷盘

参考博文
https://www.csdn.net/gather_2f/MtTaMgwsNzU4NC1ibG9n.html
https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html
https://www.cnblogs.com/mao3714/p/8734838.html
https://www.jianshu.com/p/4bcfffb27ed5
https://www.cnblogs.com/yuyue2014/p/6121114.html

参考诸多文章：感谢各位