综述
binlog二进制日志是server层的，主要是左主从复制，时间点恢复使用
redo log重做日志是InnoDB存储引擎层的，用来保证事务安全
undo log回滚日志保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读
主备数据一致性
为了保证master和slave的数据一致性，则binlog和redo log保持一致
否则当binlog写完未fsync，主库crash了，备库却执行了，数据会不一致
binlog是mysql内部实现二阶段提交的协调者
为每个事务分配一个XID
一阶段：
事务状态为prepare，redo log和undo log已经记录了对应的日志
二阶段：
-
binlog完成write和fsync后，成功，事务一定提交了，否则回滚 - 发送commit，清除undo信息，刷redo，设置事务状态为completed
故障恢复是如何做的
当出现crash等问题，通过扫描binlog中所有的xid，告知innodb，innodb回滚其它事务
需要保证binlog写入和redo log事务提交顺序一致性
如果不一致，会导致数据不一致
BLGC(Binary Log Group Commit) 解决串行prepare_commit_mutex的问题
引入队列解决，
BLGC.png
区别
redo log在事务没有提交前，每一个修改操作都会记录变更后的数据，保存的是物理日志->数据
防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性
redo log只是先写入Innodb_log_buffer，定时fsync到磁盘
binlog只会在日志提交后，一次性记录执行过的事务中的sql语句以及其反向sql(作为回滚用)，保存的是逻辑日志->执行的sql语句
undo log事务开始之前，将当前版本生成undo log，undo 也会产生 redo 来保证undo log的可靠性，保存的是逻辑日志->数据前一个版本
- 基于
redo log直接恢复数据的效率 高于 基于binglog sql语句恢复 - binlog不是循环使用，在写满或者重启之后，会生成新的binlog文件，redo log是循环使用。
- binlog可以作为恢复数据使用，主从复制搭建，redo log作为异常宕机或者介质故障后的数据恢复使用。
