MySQL数据库——日志

MySQL数据库——日志

日志

bin log

同redis的AOF类似，记录sql语句的原始提交指令，是追加写入的。
事务提交时，会将其中的sql命令追加写入。
所以这可以用于数据主从复制，和数据恢复。
由Mysql的Server层实现,是逻辑日志。

redo log

重做日志文件是记录数据修改之后的值，用于持久化到磁盘中。
Innodb实现的，物理日志,记录的是物理数据页修改的信息。

undo log

undo log是逻辑日志,记录数据被修改前的值（用于回滚）,比如"把id=‘B’ 修改为id = ‘B2’ ，那么undo日志就会用来存放id ='B’的记录”。
Innodb实现
它保存了事务发生之前的数据的一个版本

日志记录顺序

https://www.jianshu.com/p/4bcfffb27ed5
https://www.jianshu.com/p/99f6be6767c0
总结一点，先写redo log和undo log ，再写bin log，若成功，最后将redo log 改为commit状态。

为什么要分这几个日志

首先redo log 和 undo log是Innodb自己实现的，和本机物理磁盘有关，数据恢复更快。而bin log是mysql服务层生成的逻辑记录日志，和本机物理磁盘无关，还需要重新计算磁盘位置这些，恢复更慢。
一是redo log 和 undo log都具有时效性，只会保存最新几版的记录，无法做到更久远的历史数据记录。所以需要bin log。
其次bin log相当于是暴露给外层的一个日志记录接口，因为mysql不只Innodb这个引擎，可能还有其他地，所以相当于再其之上进一步进行了封装，主要用于主备服务器数据复制。

redo log 和 bin log的一致性

https://blog.csdn.net/huangjw_806/article/details/100927097?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task

简单而言，就是两阶段提交

	mysql处理事务流程
1. prepare,生成xid事务，然后将redo log 和undo log持久化到磁盘
2. 如果prapare成功，那么在继续将事务日志持久化到binlog
3. 如果前面成功，那么在redo log里面写上一个commit记录

redo log里凡是prepare成功，但commit失败的事务都会先去binlog查找判断其是否存在（通过XID进行判断，是不是经常在binlog里面看到Xid=xxxx？这就是xa事务id），如果有则将这个事务commit，否则rollback。