1. redo log
redo log又称重做日志文件，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。在实例和介质失败时，重做日志文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用重做日志恢复到掉电前的时刻，以此来保证数据的完整性。
默认情况下至少有两个redo log文件，在磁盘上用ib_ logfile (0~N) 命名。
redo log写的方式是顺序写、循环写。第一个文件写满之后，会按顺序写第二个，第二个写满之后，会继续写第三个。当写满最后一个文件时，会重新从第一 一个文件开始写。写满日志文件会产生切换操作，并执行checkpoint, 触发脏页的刷新。
2. binlog
二进制日志的主要作用:
- 可以完成主从复制功能。在主服务器上把所有修改数据的操作记录到binlog中，通过 网路发送给从服务器，从而达到主从同步。
- 进行恢复操作。数据可以通过binlog日志，使用mysqlbinlog命令，实现基于时间点 和位置的恢复操作。
binlog以事件的形式记录了所有的DDL和DML语句(因为它记录的是操作而不是数据值，属于逻辑日志)，可以用来做主从复制和数据恢复。
跟redo log不一样，它的文件内容是可以追加的，没有固定大小限制。在开启了binlog功能的情况下，我们可以把binlog导出成SQL语句，把所有的操作重放一遍，来实现数据的恢复。
binlog的另-个功能就是用来实现主从复制，它的原理就是从服务器读取主服务器的binlog,然后执行-遍。
3. redo log和binlog的区别
第一：记录内容的不同
- binlog是逻辑日志，记录所有数据的改变信息。
- redo log是物理日志，记录所有InnoDB表数据的变化。
第二：记录内容的时间不同。
- binlog记录commit完毕之后的DML和DDL SQL语句。
- redolog记录事务发起之后的DML和DDLSQL语句。
第三:文件使用方式的不同。
- binlog不是循环使用，在写满或者实例重启之后，会生成新的binlog文件。
- redo log是循环使用，最后-个文件写满之后，会重新写第-一个文件。
第四:作用不同。
- binlog可以作为恢复数据使用，主从复制搭建。
- redo log作为异常宕机或者介质故障后的数据恢复使用。
4. 两阶段提交
了解了binlog 和redo log的区别之后，想一想它们之间有没有什么关联性呢?还有就是如何保证InnoDB存储引擎的日志文件(redo、undo) 和二进制日志文件保持一致呢? 我们都知道MySQL主从环境中，从库需要通过二进制日志来应用主库提交的事务，但如果主库redolog已经提交而二进制日志没有保持一致，那么就会造成从库数据丢失，主从数据不一致的情况。接下来我们讲一下两阶段提交的过程。
先看两种情况：
- 先写redo log后写binlog。假设在redo log写完，binlog还没有写完的时候，MySQL进程异常重启。由于我们前面说过的，redo log写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行c的值是1。 但是由于binlog没写完就crash了，这时候binlog里面就没有记录这个语句。因此，之后备份日志的时候，存起来的binlog里面就没有这条语句。 然后你会发现，如果需要用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，这个临时库就会少了这一次更新，恢复出来的这一行c的值就是0，与原库的值不同。
- 先写binlog后写redo log。如果在binlog写完之后crash，由于redo log还没写，崩溃恢复以后这个事务无效，所以这一行c的值是0。但是binlog里面已经记录了“把c从0改成1”这个日志。所以，在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的这一行c的值就是1，与原库的值不同。
那两阶段提交具体是啥个操作呢？
看图说话
- 客户端发送执行更新语句的命令
- 将语句执行
- 把修改的语句更新到内存中
- 记录redo log，并将记录状态设置为prepare
- 通知Server，已经修改好了，可以提交事务了
- 将更新的内容写入binlog
- commit，提交事务
- 将redo log里这个事务相关的记录状态设置为commited
说白了就是执行完更新语句后，先将redo log状态设置为prepared，等更新内容写入binlog后，在将redo log状态设置为commited。
