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。