binlog是Mysql Service层记录的日志，undolog、relog 是InnoDB引擎记录的日志，用以来支持事务。
binlog 中记录的是数据库所有增删改操作（sql语句），逻辑日志，relog记录的是数据库事务操作中产生的变化，记录修改后的值，undolog记录事务操作前的数据值。
例如某一事务的事务序号为T1，其对数据X进行修改，设X的原值是5，修改后的值为15，那么Undo日志为，Redo日志为。
3. 对于事务的修改，binlog只会在事务提交后进行记录。
binlog日志不会循环使用，当binlog 写满时，会另写一个binlog文件， relog 文件是循环使用的。
binlog 适合用来备份， 主从复制就是根据binlog 来实现数据同步的。
undolog 日志是Mysql用来实现事务原子性的，在InnoDB引擎中，undolog还可以用来实现多版本并发控制。
事务的持久化： relog , relog在事务执行的过程中不断记录事务操作的变化，relog日志有prepare和commit两种状态（来保证binlog与relog 的一致性），事务操作完成并且binlog写入完成时，relog会从prepare状态转变为commit 状态，若在事务过程中发生系统故障时，数据库会根据relog日志状态（prepare状态）恢复到事务前的状态；若事务已成功提交但数据未更新，数据库会根据relog日志（此时为commited状态）更新到事务完成后的状态。
事务的原子性： undolog，事务在执行的过程中，操作任何数据之前先将数据备份到undolog中，事务失败时可根据undolog进行回滚。
相关疑问
是先写redo log还是先写binlog，哪个又先commit
对于一条写语句，写入的时候是先写redo日志还是先写binlog日志呢？以innodb为例
实际顺序如下：
- 会话发起COMMIT动作
- 存储引擎层开启[Prepare]状态：在对应的Redo日志记录上打上Prepare标记
- 写入binlog并执行fsync(刷盘)
- 在redo日志记录上打上COMMIT标记表示记录提交完成
先写redo，后写binlog,为什么？
可以看到先写了redo日志，但是最后才提交了redo日志，这是为什么呢？
这个是由于MySQL是通过binlog进行复制传输的，若先提交了redo日志，还没写入binlog时候掉电了，MySQL实例恢复时根据redo日志来进行恢复，会出现这边有而从库复制端没有这个记录的问题，数据不一致了。
MySQL的复制恢复步骤
说道恢复，简单聊下MySQL的复制恢复的步骤。
对于活跃的事务，直接回滚
对于redo中是Prepare状态的事务，如果binlog中已记录完成则提交，否则回滚事务