redo log 是 innodb生成的日志，主要为了保证数据的可靠性；bin log 是 MySQL server层面上生成的日志，主要用于 point in time 恢复和主从复制。undo log 主要用于事务的回滚和一致性快照读(MVCC 多版本并发控制)。
两者区别
MySQL中的redo log、bin log的功能很像，那么有什么区别？
区别如下：
- redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
- redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑。
- redo log 是循环写的，空间固定会用完（4个文件，每个文件1Ｇ）；binlog 是可以追加写入的。“追加写”是指 binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
- binlog 日志没有 crash-safe 的能力，只能用于归档。而 redo log 来实现 crash-safe 能力。
- redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。
- sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。
- binlog有三种模式，statement 格式是记sql语句， row格式是记录行的内容，记两条，更新前和更新后都有，还有混合的mix格式。
写入时机
如何保证InnoDB存储引擎的日志文件(redo、undo) 和二进制日志文件保持一致呢?
如果主库redolog已经提交而二进制日志没有保持一致，那么就会造成从库数据丢失，主从数据不一致的情况。
1、为什么需要两阶段提交
先看两种情况：
1.1 先写redo log后写binlog
假设在redo log写完，binlog还没有写完的时候，MySQL进程异常重启。由于我们前面说过的，redo log写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行c的值是1。 但是由于binlog没写完就crash了，这时候binlog里面就没有记录这个语句。因此，之后备份日志的时候，存起来的binlog里面就没有这条语句。 然后你会发现，如果需要用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，这个临时库就会少了这一次更新，恢复出来的这一行c的值就是0，与原库的值不同。
1.2 先写binlog后写redo log
如果在binlog写完之后crash，由于redo log还没写，崩溃恢复以后这个事务无效，所以这一行c的值是0。但是binlog里面已经记录了“把c从0改成1”这个日志。所以，在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的这一行c的值就是1，与原库的值不同。
2、两阶段提交过程
说白了就是执行完更新语句后，先将redo log状态设置为prepared，等更新内容写入binlog后，在将redo log状态设置为commited。
