有了redo log，为啥还需要binlog呢？
1、redo log 文件是固定大小的，是循环写的，写满了会从头继续写，而 binlog 是追加写的，写满了再新建文件接着写。
2、redo log是innodb引擎层实现的，并不是所有引擎都有。
基于以上，binlog必不可少
1、binlog是server层实现的，意味着所有引擎都可以使用binlog日志
2、binlog通过追加的方式写入的，可通过配置参数max_binlog_size设置每个binlog文件的大小，当文件大小大于给定值后，日志会发生滚动，之后的日志记录到新的文件上。
3、binlog有两种记录模式，statement格式的话是记sql语句， row格式会记录行的内容，记两条，更新前和更新后都有。
4、redo log 是物理日志，记录的是在某个表做了什么修改，用于 MySQL 异常重启时数据恢复，所以恢复速度比 bin log 更快。
你有没有想过这样一件事，binlog默认都是不开启的状态！
也就是说，如果你根本不需要binlog带给你的特性（比如数据备份恢复、搭建MySQL主从集群），那你根本就用不着让MySQL写binlog，也用不着什么两阶段提交。
只用一个redolog就够了。无论你的数据库如何crash，redolog中记录的内容总能让你MySQL内存中的数据恢复成crash之前的状态。
两阶段提交!
如果 redo log 已经 commit，那毫不犹豫的，把事务提交
如果 redo log 处于 prepare，则去判断事务对应的 binlog 是不是完整的
是，则把事务提交
否，则事务回滚
两阶段提交，其实是为了保证 redo log 和 binlog 的逻辑一致性。
为什么要有两阶段提交
MySQL在修改数据时，MySQL是先从磁盘中将数据copy到内存，然后再将内存中的数据进行修改，并记录redo log buffer 然后在通过系统调用将事务日志写入磁盘redo log file 最后最后事务提交后将内存中修改后的数据在开始写入磁盘中。
1.当只有redo log，binlog失效时，会导致主库可以通过redo log来重做，而从库因为没有及时获取到binlog而不能进行回放，导致主从数据不一致。这样会出现 redo log 写入到磁盘了，但是 binlog 还没写入磁盘，于是当发生 crash recovery 时，恢复后，主库会应用redo log，恢复数据，但是由于没有 binlog，从库就不会同步这些数据，主库比从库“新”，造成主从不一致
2.跟上一种情况类似，很容易知道，这样会反过来，造成从库比主库“新”，也会造成主从不一致。
https://zhuanlan.zhihu.com/p/343449447
https://www.cnblogs.com/jelly12345/p/14446008.html
