我们需要先了解下redo log、bin log的区别:
Binlog是server层的日志，主要做mysql功能层面的事情
redolog：
- redo是innodb独有的，binlog是所有引擎都可以使用的
- redo是物理日志，记录的是在某个数据页上做了什么修改，binlog是逻
辑日志，记录的是这个语句的原始逻辑 - redo是循环写的，空间会用完，binlog是可以追加写的，不会覆盖之前
的日志信息
binlog：
Binlog中会记录所有的逻辑，并且采用追加写的方式
一般在企业中数据库会有备份系统，可以定期执行备份，备份的
周期可以自己设置。
恢复数据的过程：
- 找到最近一次的全量备份数据
- 从备份的时间点开始，将备份的binlog取出来，重放到要恢复的那个时
刻
数据更新流程：
执行流程：
3. 执行器先从引擎中找到数据，如果在内存中直接返回，如果不在内存中，查询后返回
4. 执行器拿到数据之后会先修改数据，然后调用引擎接口重新吸入数据
5. 引擎将数据更新到内存，同时写数据到redo中，此时处于prepare阶段，并通知执行器执行完成，随时可以操作
6. 执行器生成这个操作的binlog
7. 执行器调用引擎的事务提交接口，引擎把刚刚写完的redo改成commit状态，更新完成
redo log为什么需要两阶段提交?
- 先写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，与原库的值不同。